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