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.
_______________________________________________
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/