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!
