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. :)
Except the engineering managers only cover a minute !!! part of all the
tickets. There are like 15 teams, that collectively use about 15 planning
'project' and about 50 or so project tags of stuff they actually 'sort
of'
monitor. Yet there are hundreds of projects that tickets reside in.
Please remember that WMF doesn't even come close to managing all tickets.
Decisions should not be made from a sole WMF perspective.
Perhaps we should drop the priority field completely and instead use labels
like: WMF-Priority-1 through 5
I think that gives a much better perspective, more flexibility, allows WMF
to use their own priority definitions without conflicting with WMDE,
volunteer projects, unmaintained projects, bluespice etc and create the
required separation from the consumers filing the tickets.
WMF has a reputation for chaotic management, and this
is a small step
toward correcting this.
I don't think that has much to do with the priority field at ALL and is way
more foundational. pun intended.
DJ
On Thu, Mar 16, 2023 at 6:07 PM Brett Cornwall <bcornwall(a)wikimedia.org>
wrote:
> 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(a)lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
>
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/