Hi, Sandro Knauß (2020-05-24): > anonym wrote: >> Let me first express the change we're seeking: when leaving a comment on a >> ticket, consider it your responsibility that the right person(s) will read >> it! If you don't @mention someone, you probably are failing this >> responsibility! > > On the one side, yes doing @mention somone helps, so the person knows, that > they should answer.That's why I propose, that we also add groups/function > mentions like @ft, @sysadmin, @help desk... Than people outside the team can > make sure, the other teams know about it and the teams itself can make sure, > that there are shifts and forward issues to the correct person in their > teams. > This should reduce the informal hierarchies and give the teams to define > their > own shifts etc.
I understand that at any given time, mentioning one such @role account would notify the team member(s) who is currently on duty — as opposed to every single member of the team. Is this what you're proposing? Assuming I got it right, I it a lot. I think this idea complements nicely other tools that we either have already or that we would like to have: - @group mentions: great for raising attention of *every* *single* member of a team, which most of the time is not great IMO. I just documented this tool: https://gitlab.tails.boum.org/tails/tails/-/commit/49476de8863c91c5bf8feb2ab6056776149e8fa5 - "Core Work: $team" labels: it's rare that folks outside of a team dare adding this label, which is a bold statement that essentially means "I think X is your job"; I believe the tool you're proposing would allow expressing a range of somewhat weaker statements/questions, thus making it more likely that non-team-members will dare using it, which sounds great. - Document who is on shift on a given team: on the one hand, I think this would nicely complement your idea for matters that are not worth tracking on GitLab (e.g. sometimes a 2 minutes chat on XMPP saves lots of paperwork) https://gitlab.tails.boum.org/tails/tails/-/issues/17763 What do others think? If we agree on the basic principle, I think someone should describe the proposed workflow to every affected team, and ask their feedback. This description shall include the practical consequences, e.g. what extra steps they'll need to take when the person on shift changes. (What follows is implementation details, perhaps premature, and probably interesting only to hefee & other folks who have a particular interest in GitLab mechanisms.) In terms of implementation, I find it non-trivial to get this right, but probably doable. I've thought about 2 options: a. @role is a GitLab user For email notifications to work, when the person on shift changes, we need to either update an email alias (blocks on sysadmins, no thanks) or to edit the GitLab user account and the email to the person who's starting their shift (this cannot be their usual email address as only 1 user account can have a given email address). To track To-Do's, the person on duty would have to log into GitLab as a different user than their personal one. This sounds very inconvenient, so in practice I suppose we'll have to rely on how folks track the email notifications. I see ample opportunity for stuff to fall into the cracks, and this does not encourage team-mates to help each other deal with backlog of past shifts. b. @role is a GitLab group At any given time, the person on duty would be the sole member of that group. We need to figure out how to allow team members to edit group membership themselves. For email notifications, this works out of the box. There's no per-group To-Do's so unhandled stuff is visible only to the person who failed to handle it. So here as well, I see ample opportunity for stuff to fall into the cracks, and this does not encourage team-mates to help each other deal with backlog of past shifts. I think we should not let perfect be the enemy of good, and I would be fine with dismissing my concern about To-Do tracking for now, as long as email notifications work smoothly and team members can update the @role pointer themselves. Personally I think (b) is the way to go. Cheers! _______________________________________________ Tails-dev mailing list [email protected] https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
