Page MenuHomePhabricator

Merge the Phabricator Priority values "Low" and "Lowest"
Open, LowPublic

Tokens
"Like" token, awarded by Agabi10."Party Time" token, awarded by Zoranzoki21."Like" token, awarded by Quiddity."Orange Medal" token, awarded by Krinkle.
Assigned To
None
Authored By
Aklapper, Jul 23 2019

Description

Our definitions of Priority levels are mostly a chain of "lower than the previous higher value". Which isn't too great.

I'd call the current definition of "low" unrealistic: "Less priority than Normal, but someone is still planning to work on it." IMO that's often not really the case because resources are only in FOSS theory unlimited, but not in practice.

"Lowest" sounds belittling and demotivating, so I'm sure that many people do not set it, also to avoid follow-up discussions with disappointed task authors etc.

In reality, I do not see a real difference between "Low" and "Lowest" so I propose to merge them into "Low", and give "Low" the current definition of "Lowest": "Nobody plans to work on this task, but we would be happy if someone does." Because if we were not happy that someone works on a task it means that we do not want to see the task resolved, and that means the task should have "declined" status.

Event Timeline

Aklapper triaged this task as Low priority.Jul 23 2019, 1:54 PM
Aklapper created this task.

I'd prefer to rename lowest to later or wishlist instead or removing it. Thanks.

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.

or wishlist instead

In my experience "wishlist" semantically collides with "feature request" for some folks. Plus the complete list of all open tasks is already a "wishlist". And if I have a task that was on, say, some Community Wishlist, must the task always have "wishlist" priority? I hope not.

or removing it

That's what I kind of propose (by merging it into "Low").

Jc86035 added a subscriber: Jc86035.EditedJul 27 2019, 1:44 PM
This comment has been deleted.

This priority has its sense IMO. Redefining it as "can sit here for any time", or "not urgent at all" is a better thing to do IMO, while low priority is for tasks that are more important than lowest, and should be worked on before lowest.

An example can be a cleanup task being about stuff that really doesn't bother anyone (standardization and thr like) is almost always lowest, unless the stuff is important for some reasons. Low would be for feature changes that no one currently work on, but can at any time (unless stalled).

Agreed, low and lowest are the most ambiguous priority levels, but I can see an use case.

I don't truly oppose merging through, it's a solution to remove the ambigousity, and surely less difficult to redefine and make everyone aware, including future generations of developers.

Urbanecm lowered the priority of this task from Low to Lowest.EditedAug 30 2019, 5:49 AM

To give a concrete idea, this is lowest IMO. Can sit here for years, if needed. PS: Sorry for demotivating task author :P.

Aklapper raised the priority of this task from Lowest to Low.Aug 31 2019, 5:44 PM

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".

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

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.

Urbanecm removed the point value for this task.Aug 31 2019, 11:19 PM

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

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.)