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?
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/
