[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
On 2023-03-17 09:46, Derk-Jan Hartman wrote: 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. You're right, and thanks for reminding me that the stakeholders are broader than WMF. I really like your proposal but, of course, people more important than me would have to decide on that. 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. You're right in that it's more foundational but I do think that this more generalized approach would benefit all, not just WMF. signature.asc Description: PGP signature ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
> 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 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@lists.wikimedia.org > To unsubscribe send an email to
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
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. signature.asc Description: PGP signature ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
> Can we agree on setting up some standards […]? I wonder why? What problem are we trying to solve? I mean, it's not like I can edit the priority of a Phabricator ticket and expect some other team to act accordingly. This is not how cross-team collaboration works, neither with nor without an agreed on standard. 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? 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. 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). I believe what we are really discussing here is what https://www.mediawiki.org/wiki/Developers/Maintainers stands for and partly solves. A ticket alone doesn't do anything, no matter how we prioritize it. Ownership and responsibilities are what matters. I support dropping "lowest". Best Thiemo ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
I problem I've whined^h^h^h^h^h^h discussed about in the wishlist surveys
before is that phab is a catch all, just as it isn't the best RFC platform
(we do have several wikis after all) it is fairly poor incident management
system ("helpdesk ticket") system as well. We've got a rule-of-the-hammer
problem.
Xaosflux
On Mon, Mar 13, 2023 at 4:07 PM Brett Cornwall
wrote:
> 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-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
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 -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
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. 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. 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. 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. Cheers, andre -- Andre Klapper (he/him) | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
On Mon, Feb 27, 2023 at 4:24 AM Antoine Musso wrote: > Le 27/02/2023 à 13:05, David Gerard a écrit : > > Can I just note that however you word it, closing volunteers' good > > faith bugs because nobody is available from the organisation right now > > is an excellent way to get them never to file a bug again. > > Hello, > > Possibly, though laying them open for years with priority "lowest" is > not ideal either. At least when the task is closed there is a clear > intent it is not going to be fixed/implemented. > > > Note: the issue applies to all users (volunteers and paid staff from the > various organizations participating on Phabricator) > > -- > Antoine "hashar" Musso At least in my experience, one of the most demotivating things is when people don't call a spade a spade - e.g. Gerrit patches that just languish in silence instead of someone rejecting it and explaining why. A rejection might sting in the moment, but at least it allows the person to either find an alternative path to solving their problem, or move on with their life. Ambiguous silence is so much worse. Of course, that's no excuse to reject things rudely - rejections should always be polite and compassionate, but ultimately clear. The primary reason why I don't support declining things nobody intends to work on is we're an open project - there is no fixed group of people who are allowed to work on stuff. Anyone can work on things. I also think having a list of all known bugs, even the ones that nobody wants to fix, can be a useful thing in and of itself. From that perspective certain bugs being lowest forever seem inevitable and reasonable. -- Brian ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
Le 27/02/2023 à 13:05, David Gerard a écrit : Can I just note that however you word it, closing volunteers' good faith bugs because nobody is available from the organisation right now is an excellent way to get them never to file a bug again. Hello, Possibly, though laying them open for years with priority "lowest" is not ideal either. At least when the task is closed there is a clear intent it is not going to be fixed/implemented. Note: the issue applies to all users (volunteers and paid staff from the various organizations participating on Phabricator) -- Antoine "hashar" Musso ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
Can I just note that however you word it, closing volunteers' good
faith bugs because nobody is available from the organisation right now
is an excellent way to get them never to file a bug again.
- d.
On Mon, 27 Feb 2023 at 12:02, Jaime Crespo wrote:
>
> Hi,
>
>
> On Fri, Feb 24, 2023 at 4:32 PM Brian Wolff wrote:
>>
>> If i could change the priority field i would probably change it to be only:
>> * unbreak now
>> * work on next (or "urgent")
>> * normal
>> * no intention to fix (aka lowest)
>
>
> I support this, but we should be careful about the wording. The problem with
> lowest is that is has negative connotations that I would like to avoid- that
> is why I proposed to name the above levels:
> * unbreak now
> * very high ("urgent" works too)
> * high (equivalent to work on next)
> (* normal) this would be optional, but in case we want to keep 5 categories
> * low (no intention to fix, old lowest)
>
> While this seems to be an inflation of the name usage, the original issue,
> and the one I still have sometimes, is to say something is "very low", which
> in my experience doesn't sit well for the casual reader, even if it has a
> relatively well established meaning, and leads to people complaining and
> getting an explanation, etc.
> --
> Jaime Crespo
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
Hi,
On Fri, Feb 24, 2023 at 4:32 PM Brian Wolff wrote:
> If i could change the priority field i would probably change it to be only:
> * unbreak now
> * work on next (or "urgent")
> * normal
> * no intention to fix (aka lowest)
>
I support this, but we should be careful about the wording. The problem
with lowest is that is has negative connotations that I would like to
avoid- that is why I proposed to name the above levels:
* unbreak now
* very high ("urgent" works too)
* high (equivalent to work on next)
(* normal) this would be optional, but in case we want to keep 5 categories
* low (no intention to fix, old lowest)
While this seems to be an inflation of the name usage, the original issue,
and the one I still have sometimes, is to say something is "very low",
which in my experience doesn't sit well for the casual reader, even if it
has a relatively well established meaning, and leads to people complaining
and getting an explanation, etc.
--
Jaime Crespo
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
On Friday, February 24, 2023, Dan Garry (Deskana) wrote: > On Fri, 24 Feb 2023 at 11:20, Andre Klapper > wrote: > >> * Personally I also assume Lowest priority is sometimes used instead >>of honestly declining a task (means: "this is not a good idea"[5]). >>But of course that is rather hard to prove. >> > > This is anecodal, but when I was a product manager at the WMF, I did this > sometimes. As is true in any company or project, there will always be > tickets that contain valid bugs or requests, but the reward per unit effort > makes them not worth fixing. I often tried to close these as declined to > reflect that reality, but not infrequently someone outside the team would > reopen the ticket. The path of least resistance to stop team workboards > being filled with tickets that would never be actioned was to mark them as > lowest priority, and then use a filter to remove those tickets from our > views of the board. > > I don't particularly have a view one way or the other on removal of the > "lowest" priority. The workflow I described above wouldn't really change; > "low" could just become the new "lowest", but people wouldn't find it > demoralising, I suppose? > > Dan > 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. 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. 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. My personal definition of lowest vs declined: Declined: if you wrote a patch for this it would be rejected. Fixing this is a bad idea. Lowest: nobody cares and nobody is going to work on it. However if you care, feel free to write a patch and it will get reviewed. 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. If i could change the priority field i would probably change it to be only: * unbreak now * work on next (or "urgent") * normal * no intention to fix (aka lowest) I think that's the only useful statuses. I would prefer statuses to be more descriptive. Nobody knows what "high" means. Everyone knows what unbreak now means. I would also suggest being really blunt with the names too. It's much more demotivating to give people false hope. -- Bawolff ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator
On Fri, 24 Feb 2023 at 11:20, Andre Klapper wrote: > * Personally I also assume Lowest priority is sometimes used instead >of honestly declining a task (means: "this is not a good idea"[5]). >But of course that is rather hard to prove. > This is anecodal, but when I was a product manager at the WMF, I did this sometimes. As is true in any company or project, there will always be tickets that contain valid bugs or requests, but the reward per unit effort makes them not worth fixing. I often tried to close these as declined to reflect that reality, but not infrequently someone outside the team would reopen the ticket. The path of least resistance to stop team workboards being filled with tickets that would never be actioned was to mark them as lowest priority, and then use a filter to remove those tickets from our views of the board. I don't particularly have a view one way or the other on removal of the "lowest" priority. The workflow I described above wouldn't really change; "low" could just become the new "lowest", but people wouldn't find it demoralising, I suppose? Dan ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
