I disagree with "Wishlist". It's again heterogenous and illogical, making the priority options a not-ordered set. In particular, would it mean that an "High" priority feature is not wished by anyone?

"None" is much better, but even better is removing this level entirely. I summarised the discussion so far in the description.

If something has a "none" priority I would expect it not to exist at all.

'Wishlist' is better than 'Needs Volunteer', but it can (and will) be interpreted as an orthogonal concept. I think it is workable, but if it is used (especially by WMF managers) for new features only, and mainly for features that havent been thought through completely (user suggestions rather than buildable designs). The bug database does have a lot of dreamy feature requests which are unlikely to make it onto any roadmap in the next 10 years. 'Wishlist' is good for those. Even concrete and well justified tasks like 'Support transcription of musical scores using abc notation' could be 'Wishlist'.

I am concerned that 'Wishlist' will be used too frequently by WMF managers / paid senior developers, when they are deluged with tasks regarding a new feature. The community sees them as bugs - the development team (esp. product manager) have a different opinion. If the tasks are labelled 'Wishlist' by WMF, it will aggravate the person who put time into writing up the task.

However, there are also nasty bugs with detailed descriptions which (afaics) dont get fixed until they become a problem for some new planned feature, or the developers are bugged constantly on IRC, or someone magically finds it to be itchy . e.g. a serious dataloss bug which has been analysed as "a can of worms, but it only occurs infrequently, and requires someone to do something stupid first"; so infrequently that it has a very low priority in the development communities collective mind. Is that a Wishlist item? IMO, the answer is 'no'. Perhaps we can use a new different priority label for these, which is essentially the opposite of "Unbreak Now!". "Backburner" , or maybe "Back burning" is more appropriate ? ;-)

@Nemo_bis , it is sort of already a non-ordered list with 'Needs Triage' / 'Needs Triage' could be seen as a process ordering (a status), but it isnt a temporal or priority order.

Again, can we all agree on the usefulness of keeping one more priority level below "Low"? I would really miss it if it would be removed.

As for the label for "Low-1", "None" is imho the most confusing of all.

Sending an email to wikitech-l might help bringing more perspective and hopefully fresh views to this discussion.

Keep it as it is. "Needs Volunteer" is self-explanatory even for non native English.

"Needs Volunteer" is confusing, or can be construed as confusing when someone wishes to make a ruckus. I like "Lowest" or "None". (I have not read the entire discussion, forgive me.)

I would suggest do simply call the priorities: Lowest, Low, Normal, High and Highest.

So replace "needs volunteer" with lowest and 'unbreak now' with highest.

Other names seem just confusing for no additional value, since this is what we mean, it has the lowest priority. And calling this 'needs volunteer' additionally makes it sound volunteers are only doing the least important things which is not the message we want to send.

also, KISS

In T78617#1025377, @Dzahn wrote:

I would suggest do simply call the priorities: Lowest, Low, Normal, High and Highest.

Looking at the description of the problem, this looks like a consistent solution. Simple and clear.

About the potentially "derogatory" aspect of "Lowest" with respect to volunteers, the solution is to have objective and well documented criteria. I'm not a volunteer, and currently I have 31 tasks reported that have the lowest priority level. Analytics and Wikidata have tasks looking for volunteers that are not lowest priority, and this trend is likely to increase if we detach "Needs Volunteer" from the lowest priority.

I agree with Daniel here: Just name it "Lowest", that's totally clear and not volunteer degrading at all.

This is a classic mixed audience prioritization problem. Unfortunately Phabricator has no reasonable way to distinguish between the priorities of a WMF team and the relative importance of an issue with the larger community. If Phabricator supported per-project priorities for each task then the WMF teams would be easily satisfied by allowing them to set relative priorities for backlog grooming while allowing the larger community to vote on workflow impact with a separate priority. This would actually be very useful for Product Managers and others attempting to triage open issues into blocks of work for WMF teams.

Creating an "us vs them" split is not the intent of "Volunteer needed" when I apply it to tasks that are filed against MediaWiki-Vagrant or other projects. It is just an indicator that I do not believe that the WMF would be spending donation funds wisely to work on the various tasks that have been marked this way.

I'd personally be fine with merging "low" and "needs volunteer" and adding a "volunteer-needed" or similar tag project. I could use this to the same effect as the "needs volunteer" priority when triaging a backlog by using an exclude filter in my searches.

Wishlist ? :)

"Needs volunteer" sounds like a high priority to me -- it's necessary that someone start working on it! So I agree it's very confusing and should be removed...

In general there needs to be some way to distinguish 'planned work items for an engineering team' from 'ideas about a project that we don't want to just close out because they might be good ideas even though that engineering team is not planning to work on it'.

In T78617#1037088, @bd808 wrote:

This is a classic mixed audience prioritization problem. Unfortunately Phabricator has no reasonable way to distinguish between the priorities of a WMF team and the relative importance of an issue with the larger community. If Phabricator supported per-project priorities for each task then the WMF teams would be easily satisfied by allowing them to set relative priorities for backlog grooming while allowing the larger community to vote on workflow impact with a separate priority. This would actually be very useful for Product Managers and others attempting to triage open issues into blocks of work for WMF teams.

So, like Bugzilla's "Severity" field? /troll

I'm actually kind of leaning towards either more aggressively using the assignment field, or having distinct phab 'projects' for "ideas for project X" and "work plan for WMF Engineering team X".

Is this too crazy? :)

For the records: I brought this task up to bigger audience on wikitech-l@ (plus a heads-up to teampractices@).

Experience and new arguments welcome. (This task is not a popularity contest of wordings.) Thank you for helping make a decision!

My vote is for 2.2 ("Priority: Wishlist"). I find that the differentiation between P4 and P5 is helpful.

I'm voting for keeping it.

I know that in the mobile-web board at some point we've actually used that priority to tag bugs that we wanted contributors to take on.

In our case, at that point, "Needs volunteer" meant "Normal or Low, easy to pick up by new contributor and start getting shit done".

In T78617#1037302, @Jhernandez wrote:

I'm voting for keeping it.

I know that in the mobile-web board at some point we've actually used that priority to tag bugs that we wanted contributors to take on.

In our case, at that point, "Needs volunteer" meant "Normal or Low, easy to pick up by new contributor and start getting shit done".

That sounds like you actually want the patch-welcome project as you don't actually prioritize using it, but want to actually advertise the bug. You just made my point: "Needs volunteer" just isn't a priority.

"Wishlist" is what, in practice, we've been using that priority for in Labs - things that would be nice but for which we do not realistically have the resources to devote to.

"Needs volunteer" isn't entirely a misnomer in that for those tasks to have a fair chance of being tackled, they do need someone to volunteer and pick them up. But "Wishlist" is more semantically meaningful.

I don't have a problem with "Needs Volunteer". My understanding has always been that there is no plan to fix such issues; so if you want to see them fixed, you are welcome to put your hand up and volunteer to fix the issue (no matter whether you're a paid or volunteer developer). I had never interpreted it as meaning "needs a volunteer developer", although if some people do, perhaps that is a sign it should be changed.

I would prefer the suggestion of Wishlist, to the current status quo. I think that is clearer. It means we wish it was implemented (it's not Declined), but there are no plans to work on it (but appropriate patches will be accepted).

I would also be fine with returning to Lowest.

We should move from the "I think it should be called X because of Y" to actually implementing something. This is a high priority issue so we should resolve it soon.

Im for either merging with low or bring back lowest.

I never liked needs volunteer. I always thought it made it sound like "we are too good to fix this bug, but its not beneath a volunteer" which is the wrong message. Volunteers fix bugs of all priorities, from the most "site is down" critical to the most trivial of issues.

I dont like wishlist. I think different people use that in different ways, and some in our wiki community use that term to describe their most important feature request.

"Needs Volunteer" is ambiguous and does not fit for projects that don't have paid people to work on them, such as Pywikibot.
"Wishlist" is not clear either.
Very strict projects should IMHO keep track of their priorities by using workboards.

In T78617#1039871, @Ricordisamoa wrote:

"Needs Volunteer" is ambiguous and does not fit for projects that don't have paid people to work on them, such as Pywikibot.

I'd love a "Needs staff" priority for some of the gnarly pywikibot issues, especially when paid staff decides to deprecate part of the MW API which causes all compat bots to break, or paid staff break the build environment and don't fix it for weeks. ;-)

I wonder if priorities are helpful at all? They are per-bug, not per-project (multiple teams could be interested in the same task but have very different priorities), and are used inconsistently. "Unbreak now" and "Needs volunteer" tell clearly when someone is going to attend to this (right now / never unless someone new picks it up), the rest are pretty much meaningless to me as an interested reader. Even when setting priorities for tasks in an area I maintain, the process feels largely random. (For this reason, I really hate Highest...Lowest which would erode the little meaning the priority systems currently has. If I had to bikeshed for a new name for the "no one is planning to work on this" priority, I would go with something like "no takers yet".)

Maybe roadmap tags could be a more helpful approach (although they require more effort as well): each team (or even interested volunteers) would create projects like "team X Q3" and assign to tasks they intend to take in that quarter. (And if you have no idea which quarter you might be dealing with a task, it's safe to say that task is low priority.)

Re-reading this discussion I think we can narrow the alternative to the current "Needs Volunteer" to these options:

• Lowest
• Wishlist

Can we focus the discussion between these options?

Wishlist has caused a lot of issues in bugzilla already and it is imho clearly not a priority but something different.

I agree with @Tgr ; this was what I was trying to say in T78617#849924. However if we go down that path, we'd need to have a better process for creating projects/tags/etc? The ~seventh most active repository (pywikibot) doesnt have paid staff and 'corporate' drivers/project plans/etc. (I also suspect none of the pywikibot devs cares much about the current priority levels in Phab, and we need priorities 'builds are broken' (unbreak now), 'bot operators are yelling at us' (really unbreak now), 'part of a future release' (tags) and the rest of the activity is 'because its itchy'.

@hoo Makes sense, didn't know about that tag. Then I'd vote to tag "Needs volunteer" tasks with the patch-welcome tag, and merge the priority Low.

In T78617#1037353, @hoo wrote:

In T78617#1037302, @Jhernandez wrote:

I'm voting for keeping it.

I know that in the mobile-web board at some point we've actually used that priority to tag bugs that we wanted contributors to take on.

In our case, at that point, "Needs volunteer" meant "Normal or Low, easy to pick up by new contributor and start getting shit done".

That sounds like you actually want the patch-welcome project as you don't actually prioritize using it, but want to actually advertise the bug. You just made my point: "Needs volunteer" just isn't a priority.

There's a big difference between "Low" and "Needs volunteer" to my team.

Low says "This is a nice idea/is a real bug. We're not going to work on this within the next sprint or two", i.e. the next month. My team frequently picks up low priority bugs that've been sat around for a while once we've got rid of most of the normal priority bugs, so low does not mean never for us.

Needs volunteer says "This is a nice idea. We're not going to work on it ourselves, but we'll do code review for you if you do it yourself". The actual name of this status doesn't matter to us; this could be renamed to "Lowest" as it was in Bugzilla.

Declined says "This is a bad idea and we'll actively block any attempts to do it".

I don't want to lose that nuance.

I'd be okay with having a separate tag for needs volunteers and merging the statuses. I imagine to do our standard triage of low priority issues we could simply modify our query to exclude any low priority tasks marked as needing volunteers.

Converting the lowest priority into a "needs-volunteers" tag would make the priority system more unwieldy while preserving all the problems of its usage being potentially offensive/demotivating/confusing for volunteers.

Thanks everybody for the comments and input.
It sounds like renaming "Needs Volunteer" to "Lowest" is the least controversial.
Also at least two teams have expressed that they differentiate between Low and one level below Low, so merging those two values into one seems to not be an option.

In T78617#1039914, @jayvdb wrote:

I'd love a "Needs staff" priority

That's not a priority value and there are already "Blocked-on-*" projects available.

In T78617#1042191, @Deskana wrote:

I'd be okay with having a separate tag for needs volunteers

This is being discussed at T88266.

Change 192205 had a related patch set uploaded (by Aklapper):
Rename Phabricator's 'Needs Volunteer' priority to 'Lowest'

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

Patch-For-Review

The priority field imo is useless. If I could turn it off for Web-Team-Backlog I would. We use column position on workboard to indicate this. I think popularity can be expressed via tokens. I personally pay no attention to it and its existence sets up false expectations.

@Jdlrobson: Off-topic here (however could be brought up on teampractices@ as an example for other workflows that might work for teams). This task is specifically about the name of one existing Priority value (as a followup on T268), see the task summary. Discussion about fields like {Severity, Priority, Impact, Urgency, _____} took place a few months ago: T102. For tokens, see comments/arguments in T85255 that you created.

Change 192205 merged by Dzahn:
Rename Phabricator's 'Needs Volunteer' priority to 'Lowest'

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

Thank you everybody for your input here (and deploying this)! Very appreciated.

I've filed T91010 to discuss renaming "Unbreak Now!"