In T228759#5456352, @Aklapper wrote:

Redefining it as "can sit here for any time", or "not urgent at all" is a better thing to do IMO

Yes, personally I am fine with that definition for "Low priority".

Fine with me as well.

There is no need to keep "Lowest" priority though in reality.

Current reality, agreed, but I think it has its own place.

On a related note, Could you please explain why you raised the priority? I think it's exceptionally important to explain when doing so in a task that is about merging Low and Lowest.

I don't see any "its own place" if nobody can explain how all the current and discrete Priority values are realistically used and isolated against each other.

Could you please explain why you raised the priority?

Because this is not lowest priority but higher than that, and as I'm interested in pushing this task. (What else to reply?)

In T228759#5456749, @Aklapper wrote:

I don't see any "its own place" if nobody can explain how all the current and discrete Priority values are realistically used and isolated against each other.

I tried to explain above. If that's not sufficient, could you ask please?

Could you please explain why you raised the priority?

Because this is not lowest priority but higher than that, and as I'm interested in pushing this task. (What else to reply?)

Why is it "higher than that", or why "can sit here for any time" isn't true, as I said above. If you're interested in pushing this, could you claim it to indicate that to me and others? :-)

I tried to explain above. If that's not sufficient, could you ask please?

I don't see where (and don't understand what the exact question is).
In general, we can have 0 ≤ x ≤ ∞ of discrete "Priority" field values. The data in https://lists.wikimedia.org/pipermail/wikitech-l/2019-September/092475.html shows that Low and Lowest are very much the same. So it looks like we currently have a value that we do not need. Plus that value has a bad name. Plus there is no good isolation between these discrete values anyway. If any of this is not correct then please elaborate.

Why is it "higher than that", or why "can sit here for any time" isn't true, as I said above.

Because I am interested in resolving this task rather sooner than in 100 years (which equals lowest priority to me). :)

If you're interested in pushing this, could you claim it to indicate that to me and others? :-)

No, as I usually only claim tasks when I'm pretty sure that I myself can and will fix them. (Might happen at some point though.)

In T228759#5357845, @Aklapper wrote:

I'd prefer to rename lowest to later

Every task is later than now (as long as you cannot travel back in time). My immediate thought would be "Later than what?" And there is no "sooner" priority.

Maybe we should rename unbreak now / high / medium / low(est) as now / soon / later / never :)

To get more opinions, I put up a quick and dirty "Phabricator survey" paper at Wikimedia Technical Conference 2019:

I use lowest in ZppixBot for tasks that are planned but with no idea when planned and low for tasks that are future but not within this (or maybe next) version.

Normal and above are for this release.

I tried to make use of the priorities for years. A few months ago I gave up. I'm not setting any priorities any more – except I intentionally want to communicate a decision to the world.

When I used the "low" and "lowest" priorities, they didn't mean the same:

• "Low" I used for issues I would love to see being worked on (you can think of it as a kind of approval), but it does not look like there are resources to do it in the near future.
• "Lowest" I used for issues I don't want to spend resources on, e.g. because I think a feature doesn't belong in the product. But I don't want to block others from trying. Maybe they come up with something that can convince me.

As said, I don't do this any more. If I would, I think it would make a lot of sense to use "medium" and "low" instead, and get rid of "lowest".

I find priorities to not be very useful, since they have to be shared between all projects, when prioritization is really a decision every group of developers has to make separately. Also, different groups have different workflows and priority levels are neither flexible nor expressive. Thus, most people use workboard columns for prioritization.

IMO the only useful priority levels are Unbreak Now ("whoever is closest to being responsible, drop everything else and work on this right now"), Lowest ("no one has any plans of working on this") and something neutral in between. Killing Lowest would be a step in the right direction of making priorities easier to understand (so would renaming it to something expressive like "No work planned").

"Lowest" sounds belittling and demotivating

Thanks for this, I always thought that it made no sense to have lowest.

I'm sure that many people do not set it, also to avoid follow-up discussions with disappointed task authors

+1

I think there could be room for something higher than high, but lower than "unbreak now" ("this is important, but not so much as to phone people and ask them to drop everything to work on it" -e.g. "very high"). An example is when the site goes down, and then it comes up (no longer unbreak now, ) but no mitigation has been put in place. That new proposal is outside of the scope, and I don't really feel strongly about it, but adding it here, in case it would help minimize category disruption (keeping 5 named categories) when getting rid of "lowest".

In T228759#5687066, @Tgr wrote:

IMO the only useful priority levels are Unbreak Now ("whoever is closest to being responsible, drop everything else and work on this right now"), Lowest ("no one has any plans of working on this") and something neutral in between.

This is pretty much how I use the priorities as well.

Rather than "remove Lowest", I'd probably characterize this proposal as "remove Low". You may find that people want the stuff currently in "Low" to be bumped up one level rather than down.

I've found the differentiation between Low and Lowest very useful when working as a product owner, when there are dozens or hundreds of tasks which are "not now"; explaining that some things are "not now but maybe next year" vs. "not now and probably not ever unless someone else works on it" was useful.

In T228759#5690705, @Jdforrester-WMF wrote:

I've found the differentiation between Low and Lowest very useful when working as a product owner, when there are dozens or hundreds of tasks which are "not now"; explaining that some things are "not now but maybe next year" vs. "not now and probably not ever unless someone else works on it" was useful.

Yes this is the same for me.

In T228759#5690705, @Jdforrester-WMF wrote:

I've found the differentiation between Low and Lowest very useful when working as a product owner, when there are dozens or hundreds of tasks which are "not now"; explaining that some things are "not now but maybe next year" vs. "not now and probably not ever unless someone else works on it" was useful.

@Jdforrester-WMF: I do not see any realistic difference between "not now but maybe next year" and "not now and probably not ever unless someone else works on it". Do you?
I'm afraid "maybe next year" is wishful thinking for a vast majority of tasks. We have many many open "Medium/Normal" and "Low" priority tasks in Phab which have been open for more than a decade. I personally believe that both priority planning is often unrealistic and that "Lowest" (which already was called like that in Bugzilla) sounds too demotivating so many people will not use that value.

In T228759#5699339, @Lydia_Pintscher wrote:

Yes this is the same for me.

Looking at the project tag with the most open tasks (Wikidata) and ignoring open tasks with "Needs Triage" priority, the distribution of open tasks currently is:

@Lydia_Pintscher: If I understand you correctly, that would mean for 93.25% of the non-"Needs triage" tasks (1478 in total) that these tasks would get "maybe" worked on within the next year or earlier. Do you think that is a realistic expectation to communicate?

How often each non-initial "Priority" field value got set/changed within last 12 months by those 76 users who set/changed the "Priority" field ≥50 times within last 12 months:

39 out of 76 those people never ever set “Lowest” priority.

I don't see a reason to keep a "Lowest" priority.

I do see unrealistic prioritization and a common problem of wishful thinking though.

Change 699493 had a related patch set uploaded (by Aklapper; author: Aklapper):

[operations/puppet@production] Phabricator: Disable setting lowest priority on tasks

https://gerrit.wikimedia.org/r/699493

Numbers a year later:

How often each non-initial "Priority" field value got set/changed within last 12 months by those 65 user accounts who set/changed the "Priority" field ≥50 times within last 12 months [1]:

27 out of those 65 user accounts never ever set “Lowest” priority.

How often each non-initial Priority field value got set within the last 12 months, in general [2]:

[1] based on SELECT usr.username, trs.newValue, COUNT(trs.newValue) AS cnt FROM phabricator_maniphest.maniphest_transaction trs JOIN phabricator_user.user usr WHERE usr.isDisabled = 0 AND trs.transactionType = "priority" AND FROM_UNIXTIME(trs.dateModified) >= (NOW() - INTERVAL 12 MONTH) AND trs.authorPHID = usr.phid AND usr.phid IN (SELECT trs.authorPHID FROM phabricator_maniphest.maniphest_transaction trs WHERE trs.transactionType = "priority" AND FROM_UNIXTIME(trs.dateModified) >= (NOW() - INTERVAL 12 MONTH) GROUP BY authorPHID HAVING COUNT(trs.id) > 50) GROUP BY trs.newValue, usr.username ORDER BY usr.username, trs.newValue DESC;

[2] SELECT trs.newValue, COUNT(trs.newValue) AS count FROM phabricator_maniphest.maniphest_transaction trs JOIN phabricator_user.user usr WHERE usr.isDisabled = 0 AND trs.transactionType = "priority" AND FROM_UNIXTIME(trs.dateModified) >= (NOW() - INTERVAL 12 MONTH) AND trs.authorPHID = usr.phid GROUP BY trs.newValue ORDER BY trs.newValue DESC;

Furthermore, as can be seen in the "Phabricator monthly statistics" emails on`wikitech-l@` over the last months or even years (last edition), there is no significant difference between median age of open tasks with Low and with Lowest priority, thus nothing is realistically differentiated here.

Posted on wikitech-l@: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/X2JVUGM3ULTZVSRWXO3VQ6UVP4UVU42R/

In T228759#8643816, @Aklapper wrote:

Furthermore, as can be seen in the "Phabricator monthly statistics" emails on`wikitech-l@` over the last months or even years (last edition), there is no significant difference between median age of open tasks with Low and with Lowest priority, thus nothing is realistically differentiated here.

That's not an inference I would make from that data. You're merely finding that the propensity to pick tasks up at the bottom of the heap (which is generally done by volunteers, or occasionally by teams when it turns out that priorities change) isn't significantly different, which isn't that surprising. It doesn't speak to the value of distinguishing tasks around product alignment, as I pointed out the last time you pushed this change but you dismissed.

To be honest, I don't know if this and similar issues matter much unless a more formal strategy around Technical-Debt is implemented and code stewardship/maintenance is reassessed. Phabricator in aggregate is pretty noisy and, as others have noted, is without commonly-shared standards around its usage for things like task priority, which I'm not sure is even solvable. I do like @Bawolff's suggestion (in his wikitech-l response) - as an initial step - to separate various teams (wmf, community, both) from actual codebases or projects within Phabricator, in relation to what is being prioritized and worked upon. I believe that would help with various misunderstandings like "the Security-Team works on every task tagged with Security". This would be a significant change though and likely difficult to propagate.

I made a longer comment on the mailing list, but just to add here.

I'm of the opinion that lowest and UBN are basically the only two useful priorities. Because they aren't actually priorities but bug states. UBN meaning drop everything. "Lowest" meaning nobody feels this is worth working on ever (Which is different from "low" where you might work on it if you run out of higher priority tasks), but if someone made a patch for it, that was perfect, we would merge. Both of these are really different from a priority. In essence they are a priority of positive infinity or negative infinity.

Priorities cause endless drama, and have no agreed meaning (but yet are global and not per work board). Users often see them as a way to get attention for their issue (i.e. they think they are prescriptive not descriptive) which is misguided and there is a conflation between severity and priority.

I propose we should remove all the priorty-esque priorities, and just have the state based ones. Namely we should have priorities:

• Unbreak now - drop everything to fix
• Normal - 99% of bugs
• No intent to work on - [Formerly known as lowest] Bugs that the maintainers of the component have no intent to work on ever and don't believe it is worthwhile. However if someone made a patch for it, it would be merged

and no other priorities. Teams that want to prioritize things can still do so by having columns in their workboard.

Agreed on merging the two; Even the guidelines just group the two together.

Considering the age of this ticket I propose this get settled and implemented sooner than later.

I do find it a delicious irony that the ticket is marked "Lowest" :D

In T228759#5690705, @Jdforrester-WMF wrote:

I've found the differentiation between Low and Lowest very useful when working as a product owner, when there are dozens or hundreds of tasks which are "not now"; explaining that some things are "not now but maybe next year" vs. "not now and probably not ever unless someone else works on it" was useful.

Same. "Low" is "we'll get to this eventually", "Lowest" is "not declining this, but also not planning to work on it".

I'll quote @Nemo_bis, who once said:

"Low" and "Lowest" priority are good indicators of thing with high impact and low cost which are of interest to the community. Also for WMF engineers: when they look for something interesting and useful to do outside their work, lowest priority is the obvious candidate. :) Highest priorities are evil emergencies, normal priorities the usual boring stuff we have to do as mandated by someone, lowest all the fun. :)

It doesn't speak to the value of distinguishing tasks around product alignment,

I'm not sure if I get "product alignment" correctly then - if some task is not in scope at all the for a product then the task should be declined. If a product team does not plan to work on some task but would accept contributions then that task should have {low|lowest} priority.

"Low" is "we'll get to this eventually", "Lowest" is "not declining this, but also not planning to work on it".

Would that imply that the difference is "I can imagine someone might show up to work on this and that the person might be paid by some organization and be part of some team in that organization" vs "I can imagine someone shows up to work on this and that the person would rather not be in a team of some organization"?
If some team does and shall not have any capacity to work on a task, then this team should not add that task to the team's (not: code project's) to-do backlog. This is why we have separate team project tags and code base project tags, in my understanding.

I took the liberty to slightly enhance the task description making use of {nav Low} and {nav Lowest} to make them stand out a bit in the text.

My understanding of our usage of Lowest priority in Phabricator is that it is inherit from the Bugzilla LATER resolution which we sometime (often?) used when closing task. We certainly all have a huge backlogs and some tasks are filed merely as a reminder for a later us (months, if not years later) or as an area to discuss features we will eventually need or good ideas but that we can not implement currently. Having those kind of tasks still open gives them a bit of exposure when one search for tasks, the form defaulting to filtering on tasks that are open.

I had a discussion a few months ago about how keeping task open for months or years is not reflecting the reality: they are not going to be addressed or fixed so we might as well close them (possibly Declined) instead of keeping them open with a {nav Lowest}. Cause for most purposes, those tasks are not going to be addressed, so there is little point of keeping them around. But that is one point of view, another one is keeping them open might trigger someone to eventually start working on an old task on their spare time which ends up as a benefit, not declining them thus give them a little chance that maybe they will get done one day.

Anyway, I don't mind, I usually sort task by last creation date or last updated date and ignore anything that is too old. My only use case for priorities are:

• Unbreak now! to indicate I am immediately working on it or to notify anyone who get notification about it. That makes them stand out.
• High To indicate it will be done over the day or whenever the task is scheduled (for example applying a scheduled security update)

Beside those, I do not use priorities, but I would welcome removing lowest for sake of simplicity ;)

Frankly I don't see much difference between "LOWEST" and "untriaged, opened 10 years ago"..... there is a much bigger expectation management problem for phab requests than this.

aklapper opened https://gitlab.wikimedia.org/repos/phabricator/deployment/-/merge_requests/5

Phabricator: Disable setting lowest priority on tasks

Change 699493 abandoned by Aklapper:

[operations/puppet@production] Phabricator: Disable setting lowest priority on tasks

Reason:

Superseded by https://gitlab.wikimedia.org/repos/phabricator/deployment/-/merge_requests/5 per T331673

https://gerrit.wikimedia.org/r/699493

In T228759#8718415, @gerritbot wrote:

aklapper opened https://gitlab.wikimedia.org/repos/phabricator/deployment/-/merge_requests/5
Phabricator: Disable setting lowest priority on tasks

@brennen: Any recommendations how to get that one-liner reviewed / merged / deployed? TIA!

@Aklapper There was a ton of bikeshedding on wikitech-l which resulted in nothing getting done. :(

I know you didn't solicit my opinion but if we could get the SRE management to come to a consensus of how we all use our work management that would be *very* beneficial. Low/Lowest don't matter, what matters is that there's consistency and shared understanding of what these statuses mean. It's a hindrance to continue with the free-for-all definitions; SRE is a team with subteams, not different organizations.

@mark Would you be interested in herding all the cats together in a room?

In T228759#8789350, @Aklapper wrote:

In T228759#8718415, @gerritbot wrote:

aklapper opened https://gitlab.wikimedia.org/repos/phabricator/deployment/-/merge_requests/5
Phabricator: Disable setting lowest priority on tasks

@brennen: Any recommendations how to get that one-liner reviewed / merged / deployed? TIA!

@brennen and I looked at this patch today.

For clarity, the effect of this patch seems to be a slow extinction of the Lowest priority:

1. Removes Lowest as an available status for new tasks
2. Leaves old Lowest tasks as Lowest, but
3. If you update a Lowest priority task to any non-Lowest priority, there's no going back

I reviewed the mailing list thread and this thread it seems like most people are mildly in favor (although a few mildly against). Rough consensus seems good enough for this.

@Aklapper let's coordinate merge/deploy/messaging.

Configuration changes of this type should require very little (if any) user-facing downtime. I'll do the necessary with the deployment repo; we can make the change in production yet this week, if not today.

brennen merged https://gitlab.wikimedia.org/repos/phabricator/deployment/-/merge_requests/5

Phabricator: Disable setting lowest priority on tasks

@brennen: Hmm, https://phabricator.wikimedia.org/config/edit/maniphest.priorities/ shows "disabled": true under Local Config but not under Database. Thus I can still set lowest priority on tasks.

Updated db value.

Thanks! Related docs updated:

• https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette
• https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
• https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels
• https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Bugzilla_data_migrated
• https://www.mediawiki.org/wiki/Phabricator/Project_management/Tracking_tasks
• https://www.mediawiki.org/wiki/Core_Platform_Team/PET_SLAs/Task_Priority_SLAs
• https://www.mediawiki.org/wiki/Reading/Web/Phabricator
• https://www.mediawiki.org/wiki/Design_Systems_Team/Team_Processes

In T228759#8802153, @BCornwall wrote:

I know you didn't solicit my opinion but if we could get the SRE management to come to a consensus of how we all use our work management that would be *very* beneficial. Low/Lowest don't matter, what matters is that there's consistency and shared understanding of what these statuses mean. It's a hindrance to continue with the free-for-all definitions; SRE is a team with subteams, not different organizations.

@mark Would you be interested in herding all the cats together in a room?

@BCornwall: I believe this requires authority to enforce any potential decisions. If you can make authority interested and have time, I'd be happy to see that.

@Aklapper Thanks for bringing that up. I did briefly attempt to bring this up some time ago but I didn't get much traction. @mark Is this something you'd be interested in pitching to the various teams?