mob next; takes account of driver/navigator/team roles

[alterisian]

So That: We can remember who is driver/navigator/team As A: mob member typing 'mob next' I Want To: See which of the roles the participants have, at handover.

Why we may not want to this:

• complexity. It's quite simple, and mostly works as it is, but doesn't allow for human memory.
• people may want to have an unnecessary disagreement about the labels attached to the roles.

• complexity. People join or drop into the mob. I may not have understood mob.sh handles this... yet.

  Notes: I'm switching between mobs using this and a more popular web timer: https://mobti.me and noticing what is good/great in each :)

[hollesse]

I am not sure If I understood correctly what you mean. As mob.sh has emerged out of remotemobprogramming.org and it's methodology there is just the role of the Typist and the Rest of the mob. The Typist(analogue to the driver) is always the one sharing the screen. The rest of the mob are all the navigator. To easily know who is sharing we recommend for macOS for example to show your username in the menubar. The you can easily see who is sharing. To know who is the next typist mob tries to use the last mob commits and detect who is in the mob and then take over the last order. For timer.mob.sh this could be different, maybe we should allow to set the names there and tell the timer who is present and who is not. If you would like any feature request on the web timer please open an issue here

[gregorriegler]

We do have this feature where we keep track of who is probably next. And we display it. It's not always correct, but after a full rotation it is. As soon as the mob changes it's of course off again, as it uses the commit history to derive this information.

If mob.sh only knew which roles the current mob used, it would be able to calculate and display the given names with their respective roles. On mobti.me you can easily configure the roles by providing a comma separated value. E.g. "Talking, Typing, Next". We could as well provide such a configuration property. Then mob.sh could display the names and their probable role based on that info.

I think it would be a nice feature. What do you think?

[jamesobrooks]

@hollesse @gregorriegler I'm working on adding the ability to track participants and was hoping I could get some feedback on whether this would be a candidate for merging. For now it would only be names giving users the ability to define who is to be included when determining the next typist. Here's a draft PR (it's to main in my fork, but I would re-create to point to main here when ready).

https://github.com/jamesobrooks/mob/pull/1

P.S. please keep in mind that this is the first time I've done anything with Go, so if there are any glaring problems with my implementation, I'd be happy to learn better ways to do it.

[hollesse]

Hi @jamesobrooks thanks for your ideas and implementation. When I thought about this feature I thought about holding the state of who is in the mob in our timer.mob.sh application. And not locally, as this state needs to be synchronized between the different users. We cloud use our .mob config within the project root, but i am not sure if it would be better to have it in the server then the server could also notifiy the next person in the row. What do you think about this idea?

[jamesobrooks]

@hollesse, I wondered about whether storing in the timer app would be an option, but we also haven't adopted the timer—mostly because when we do use a timer app, we use one that has goal tracking. My thinking was to use a file that only exists for the mob session which can be committed with the mob next and then would be removed with the mob done. Using the .mob file is certainly an option too, and my approach actually depends on the user using their ~/.mob to set their timer user name, so already partially leverages the timer functionality.

I think there are a lot of options for how to accomplish the goal of tracking typists, and maybe it makes sense to implement something simple first and extend later along with changes to the timer?

[hollesse]

Hi @jamesobrooks in my opinion the timer would be the best place for that. In Issue #290 the feature of goal tracking is requested and I even did something last year but did not finish it. If you like you can give me some insights in this issue how you use goals within your teams and what the goal tracking should look like.

If you want to use a local file I would recommend using the .mob file. Maybe you don't know it but we can have two .mob files. One in the user home directory and one in the root folder of the git project. This .mob file is used just for the projects it is used in and can be committed. At the moment this files are not written by mob itself. It was always written by the user. As we are having problems with anti virus on windows I would like to not write any files and therefore would prefer a solution with the timer. I think goal tracking and the rotation in the timer would also make the timer much more attractive.

But for me it would also be fine to start with a simple solution but then using the .mob file within the project. Would you like to describe how this feature should look like? I don't mean how to implement it but how to use it. And what should happen if I do a mob done for example. Do I have the ability to order the mob. Maybe describe it like a user story and let us discuss about it.

[jamesobrooks]

@hollesse that's unfortunate about anti-virus. Is the issue that if mob is capable of writing to a file, Windows anti-virus identifies it as some sort of malware?

Here's a user story:

As a mobber, I want to be able to add or remove myself to/from a mob rotation without waiting for a commit, so that there is no ambiguity as to who's turn it is to type.