On 2023-03-16 17:25, Thiemo Kreuz wrote:
Can we agree on setting up some standards […]?I wonder why? What problem are we trying to solve?
The problem this solves is the constant confusion as to the meaning of various statuses. Tickets often have more than one team tagged for a single task, so having different definitions of priority rankings inherently de-legitimizes their purpose.
I mean, it's not like I can edit the priority of a Phabricator ticket and expect some other team to act accordingly.
Not sure what you mean by "act accordingly" but the point is so that anyone can set the priority based on a shared understanding of what it means. Considering WMF employees even having clinic duty where they're expected to prioritize tickets for all teams, it makes sense to have that shared understanding. Presently, many just mark as "medium" and move on.
This is not how cross-team collaboration works, neither with nor without an agreed on standard.
This is *exactly* how cross-team collaboration works because it enables cross-functional work! This stops the supposed endless drama surrounding something so tame as ticket prioritization. This needn't be something perfect, it just needs to be predictable/understandable. The current situation is chaotic and ultimately renders that facet of work management pointless.
It's not helpful anyway. Who decides what priority a ticket should have? Based on what information? Which ticket should I pick first when I have hundreds that claim to be high?
The engineering managers at WMF; That's what they're hired to do! They develop and manage available resources to reduce meta-toil and enable minions to spend more time working on stuff. :)
Our team stopped using the priority field entirely. Well, with the obvious exceptions, namely "unbreak now" and occasionally a low(est) priority to communicate that there are currently no plans to ever assign resources to a ticket.
This sounds like a natural result of not defining the priority field.
Instead we use boards to model products, teams, and sprints within a team and order tickets in columns from top (high priority) to bottom (low priority).
Boards are useful for visualizing ongoing/planned work but are hardly a replacement for the priority/status field. Using filters and searches, reviewing your sprints, etc. are all benefited from using priority and status. Swimlanes are typically *tied* to the status field rather than existing separately.
Agile-based sprints employ story points drawn from shared definitions of work measurement so I would hope that your team would know the value of this. :)
I believe what we are really discussing here is what https://www.mediawiki.org/wiki/Developers/Maintainers stands for and partly solves.
I disagree! This is shining a light on how words have no meaning without a shared understanding.
A ticket alone doesn't do anything, no matter how we prioritize it. Ownership and responsibilities are what matters.
It's not so binary: Different facets of management all come together to matter as a whole.
I support dropping "lowest".
To reiterate, I don't care whether or not lowest is dropped; I care that someone with clout can stand up and, with authority, say "These are the statuses we'll have and this is what they mean".
WMF has a reputation for chaotic management, and this is a small step toward correcting this.
signature.asc
Description: PGP signature
_______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
