On 2023-03-13 13:12, Andre Klapper wrote:
On Fri, 2023-02-24 at 08:31 -0700, Brian Wolff wrote:
>
> I feel this is a problem with phabricator being used as both a
> project management tool for teams and as a bug tracker, when those
> are different things.
Agreed! I find using Phabricator for RFCs also odd. IMO Phab tickets
should contain actionable items that are narrow in scope. RFCs belong
somewhere else. For instance, I've seen Git used effectively [1].
> Certainly its reasonable for teams to have bugs
> they dont think is worth fixing and a way for them to ignore said
> bugs, but declining them hinders people who are trying to track what
> the known bugs are resulting in duplicated effort.
I disagree with this: Declining is a statement, not a means of
disappearing a ticket like a Gestapo target [2]. Using the priority field
just clogs up the ticket queue with in-actionable content that will rot.
> Not to mention
> external contributors may want to fix these bugs and declining them
> hinders this. I personally think the best solution is to have
> separate work boards for team management vs mediawiki component.
In my mind "Declined" means "no, this will not be implemented even if a
patch is submitted".
I strongly agree and advertise having both a
project/workboard for the
team (violet project tag) AND a codebase project tag (blue project tag)
for the software.
Scope and thus responsibilities of teams change over time.
A ticket may be still valid for a codebase though some team might not
steward or maintain this codebase anymore.
Generally i find the priority field an endless
source of drama. The
way priority/severity gets conflated is problematic, the way it is
global instead of per work board is problematic. The way non-devs
think it is prescriptive instead of descriptive is very problematic.
Sometimes i wonder if it should be removed entirely, although maybe
that is too far.
Many years ago, restricting who can set/change the Priority field value
was discussed in
https://phabricator.wikimedia.org/T819 .
Over the years we have become more restrictive in who can change
certain aspects of tasks or projects in Phab due to vandalism, e.g. by
having Access-control lists (ACL) like the #Trusted-Contributors group
in Phabricator (and a similar concept in Gerrit).
Adding such restrictions often requires code changes in Phabricator
while it seems that WMF does not invest much effort into actively
fixing some of the shortcomings of its infrastructure software.
Thus some folks might instead prefer to use whatever tools folks are
already used to do or tools which presumably serve better folks' needs,
with the side effect of decreasing collaboration and transparency.
Each team using the same terms for different meaning seems to contribute
to the confusion of work prioritization. Having an SRE-wide definition
of what all of these states mean can help shared understanding. IMO it's
valuable to come together (or lock all the managers in a room) and come
up with a standard of priorities/workboards/statuses that we can all
use/understand. Changes to the process requires an RFC (Forced
conclusions of RFCs to prevent stagnation is another topic for later).
So long as it's consistent I don't really care what attributes are
exposed to us; Arguing over vague definitions that vary between teams
leads nowhere when we can't establish shared understanding of
Phabricator tickets (seemingly as evidenced by "endless drama" of
prioritization).
Can we agree on setting up some standards or is that too quixotic?
[1]
https://gitlab.archlinux.org/archlinux/rfcs (disclosure, I'm an Arch
Linux contributor)
[2] Uh-oh, did I just Godwin's law the thread?