Rush wrote on 2014-08-20 18:12:20 (UTC)

The exclusion of a 'low' priority, for tasks in other realms than bugs for things that are relegated or otherwise less priority but still on the table is problematic for rt use case, etc. I would imagine other teams would like it as well. I would propose we keep low as a priority, and just not use it for bugs if people don't want? Needs Volunteer here doesn't fit the bill in those cases.

Rush wrote on 2014-08-20 18:13:02 (UTC)

i.e. that means the bugzilla migration chart stays the same, but the rt one can be more uniform to origin.

aklapper wrote on 2014-08-20 18:21:31 (UTC)

The intention to call lower/lowest priorities "Needs volunteer" was to communicate expectations better plus the opportunity of getting involved to get a certain pet-peeve issue fixed. This underlying stuff is expressed less by calling it "Lowest priority" or "Wishlist" instead.

But having discussed the values proposed above, Operations clarified that they need a low priority that is not called "Needs Volunteer". "Needs Volunteer" might work well in the scope of bug reports, but not necessarily for teams like HR, Legal, or Ops, if a volunteer does not necessarily have access to infrastructure or workflows required to resolve such tasks. Another linguistic problem is that items with a medium/higher priority often also welcome volunteers. It's not distinct.

Hence I am going to edit the initial description to stick with transfering Bugzilla's "low priority" to "low priority" in Phabricator, for the time being.
If anybody finds a better and shorter wording for "Nothing's going to happen with this task if you don't work on it no matter if you're paid or not", share it here (bikeshed, yay).

Rush wrote on 2014-08-20 18:38:27 (UTC)

notice priorities available here:

  "100" : {
    "name"  : "Unbreak Now!",
    "short" : "Unbreak!",
    "color" : "indigo"
  },
  "90"  : {
    "name"  : "Needs Triage",
    "short" : "Triage",
    "color" : "violet"
  },
  "80"  : {
    "name"  : "High",
    "short" : "High",
    "color" : "red"
  },
  "50"  : {
    "name"  : "Normal",
    "short" : "Normal",
    "color" : "orange"
  },
  "25"  : {
    "name"  : "Low",
    "short" : "Low",
    "color" : "yellow"
  },
  "10"  : {
    "name"  : "Needs Volunteer",
    "short" : "Volunteer",
    "color" : "sky"
  }
}

Rush wrote on 2014-08-20 18:42:11 (UTC)

further work in T423

Rush wrote on 2014-08-20 18:45:25 (UTC)

https://gerrit.wikimedia.org/r/#/c/155314/

importing issue status

I just saw that "needs volunteer" is a priority. That is mixing two distinct concepts: priority and the fact that we're looking for someone to work on it. (And if it doesn't matter if someone works on it or not then it shouldn't say _needs_ volunteer.)

Any better naming proposal in mind that wasn't brought up in previous comments? And does that imply that you set tickets as high priority though it's entirely unclear if anybody's ever going to commit time to work on them?

I don't have a better wording than "lowest" at the moment. We have a scale there. We shouldn't make this more confusing by adding something that isn't a point on the same scale. The fact that no-one is going to work on it isn't made better by the fact that we're calling it differently ;-)

As for setting tasks to high where it is entirely unclear if anyone is ever going to work on it: Pretty unlikely for high but all the time for normal.

If a task is "lowest" for the maintainers but not Declined, then it really needs someone else out of the team (a volunteer) to pick it up. I think it is an honest and quite transparent resolution.

Hey, I could find "Lowest" degrading. :) I'd rather say it clearly that nobody will work on task X unless someone else comes and takes it. I like it because it sets the right expectation.

Let's see, maybe we need to fine tune our vocabulary. If I take a task of Wikidata, I'm a volunteer for Wikidata, because I'm definitely not paid to work on Wikidata. If Lydia takes a task for Engineering-Community, she is a volunteer for Engineering-Community, because she is definitely not paid to work on WMF Engineering-Community. Yet Lydia works professionaly for Wikidata, and I work professionally for Engineering-Community. I don't feel professionals are better or worse than volunteers, and I do my best when I'm being paid and when I'm not. There is nothing degrading in volunteering or asking for volunteers.

The priority of a task is relative to the priority of the neighboring tasks in a context of limited resources. You say you have a "higher priority" task but you have "no developer time for that". Well, then the truth is that such task has lower priority than the ones you are busy with (unless your plan is wrong). If you really don't see your team working in a task anytime soon, marking it as "Needs Volunteer" is probably the best favor you can do to the ones waiting for it to be resolved. If you think you will work on it at some point, call it Low or Normal.

If you know a task is less than Low priority but you don't dare to say that you need external help to resolve it, that might be involuntary cookie-licking and ultimately deceiving for whoever had any expectations on that task. Let me add that after months using Needs Volunteer, in my mind it is totally detached from the concept of "Lowest". These are tasks that I know we are not going to work on, yet I decide not to decline for some reason. Frankness is useful in project management, and Needs Volunteer is a frank statement.

By the way, this is what our draft documentation says:

https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels

Wikimedia Phabricator offers these priority levels:

• Needs Triage - Default option, signaling that the priority is to assign a priority.
• Unbreak Now! - Something is broken and needs to be fixed immediately, setting anything else aside.
• High - Someone is working or planning to work on this task soon.
• Normal - Less priority than High, but you are still planning to work on it.
• Low - Less priority than Normal, but you are still planning to work on it.
• Needs Volunteer - You are explicitly saying that you don't plan to work on this task, even if you would be happy if someone does.

Now look what Bugzilla has been saying in the past years: https://www.mediawiki.org/wiki/Bugzilla/Fields#importance

I kept thinking about this. There is one subtle change that we might have made by moving to kanban-inspired Phabricator, simplifying Priority levels, getting rid of Severity, and bringing workboards for everybody. Now Priority is a subjective and changing value based on the current understanding of the maintainer(s), while before it was more of an objective value that wouldn't change easily. Now a task is Low, Normal or High basically depending on current needs and possibilities to address the specific task in the short term. Priority is a tool to push tasks up & down in backlogs, and into sprints.

Let me illustrate this with an example:

Bug 53247 - History and diff pages should show labels of properties and items in edit summaries (old-bugzilla link)
Importance: High normal
Keywords: patch-welcome

Today this is T55247: History and diff pages should show labels of properties and items in edit summaries, which is one of the 82 High priority open tasks of MediaWiki-extensions-WikibaseRepository. According to the history of the bug, it was reported on 2013-10-17 and it has been marked as High and need-volunteer since 2014-02-26. There hasn't been any progress since 2014-03-11.

In my opinion, T55247 doesn't look like a real High priority task, but as a real Needs Volunteer priority task.

Every project can organize itself in the way that works best for its members, but from the point of view of the Phabricator maintainers, who need to provide the defaults for all the teams, we believe that it is better to offer a default to identify as High priority those tasks that will be acted upon sooner than later, and as Needs Volunteer those tasks that none of the regular contributors of a project is planning to work on.

If priority is an indication of a project's subjective view on a task, why is it displayed and shared through all projects? It would make much more sense (and avoid confusion) to have it defined for each project individually and removed from the general view.

Can you provide examples where this is confusing? Usually a task belongs
more to one team than another. Of two teams share a same task and it had
very different priority for each, then perhaps what happens is that we have
two actual talks embedded in one, or this tells have to sit and discuss a
common approach.

I disagree.

Can we assign to a dummy "needs volunteer" or "nodody" account when a Team doesn't want to work on this?

And rename "needs volunteer" priority to "lowest".

In T268#834341, @Gryllida wrote:

Can we assign to a dummy "needs volunteer" or "nodody" account when a Team doesn't want to work on this?

No. Having no assignee set on a task is way clearer to express that nobody's working on a task than some dummy account workaround like we had in Bugzilla due to Bugzilla's technical restrictions (plus it's unclear to me which problem your proposal is supposed to solve). And all this is also rather unrelated to the names of Priority values.

There are three states a task may take.

A) We clearly know that if an issue is assigned, then someone (the team or a volunteer) took it.
If an issue is not assigned, then either
B) it's about to get assigned when someone from the team takes it, or
C) it's something the team doesn't want to work on right now (although it's ok if someone else does).

What we need to do is invent a way to distinguish between B and C without abusing the "priority" field, because volunteers should have the ability to invent tasks which Teams don't need, and use priorities within that set of tasks. By abusing this field, we leave volunteers to scribble notes on a piece of paper as to what they need to do first and what they need to do last.

Now, let's invent a way to use the "assigned to" field to distinguish between B and C. Thanks much. :)

In T268#835928, @Gryllida wrote:

There are three states a task may take.

A) We clearly know that if an issue is assigned, then someone (the team or a volunteer) took it.
If an issue is not assigned, then either
B) it's about to get assigned when someone from the team takes it, or

High / Normal usually denotes that the team has these tass in the pipeline, although if a task is vacant and a volunteer has the interest and the skills to complete it, I don't see why they could not take it.

C) it's something the team doesn't want to work on right now (although it's ok if someone else does).

Low, Needs Volunteer denotes that the regular team members are not planning to work on it any time soon.

What we need to do is invent a way to distinguish between B and C without abusing the "priority" field, because volunteers should have the ability to invent tasks which Teams don't need, and use priorities within that set of tasks.

Are you talking about tasks within the same project? If external people to the team ("volunteers") get regularly involved in tasks, then at some point they become part of the team and can influence their priorities. In fact, as soon as a tas is taken by someone it is appropriate to change the priority according to the expectations. If a Needs Volunteer task is taken by someone that will work full time on it from that very minute, setting it to High just corresponds with the reality.

The point on which we keep insisting here is that having tasks marked as High / Normal priority and vacant for months and years doesn't help anybody.

By abusing this field, we leave volunteers to scribble notes on a piece of paper as to what they need to do first and what they need to do last.

Can you put a specific example? I would like to understand what you mean.

I can put a specific example. These two tasks have been ignored by the Flow team:

• https://lists.wikimedia.org/pipermail/ee/2014-December/001319.html
• https://lists.wikimedia.org/pipermail/ee/2014-December/001320.html

Obviously, given how long ago I raised these issues, the Teams are ignoring and are not taking them. However it is my understanding that people from outside of the Team would appreciate these tasks being completed. Therefore I would like to be able to set them a "High" priority, while using the "assigned to" field to move them outside of the Team radar.

These are emails, not tasks in Phabricator. There is a difference.

Imagine that you create the tasks (if such feature requests haven't been created already, didn't check), and imagine that you set them to High priority. So what? You are not going to develop the features requested, so anyway the actual implementation will depend either on the Flow team (making their real priority more important than your High) or... on a volunteer willing to write a patch for this (proving the point that "Needs Volunteer" was indeed applicable to these tasks).

Bottom line: if your problem is that maintainers have other priorities than yours, changing the labels of priority field will not change that fact. We believe that, if anything, "Needs Volunteer" will increase your chances of seeing someone taking a task compared with "Lowest".

PS: please convert those emails in Phabricator tasks. :)

Imagine that you create the tasks (if such feature requests haven't been created already, didn't check), and imagine that you set them to High priority. So what?

If we invent a way to properly indicate which of these tasks are off the Team radar, then anybody will be able to browse such tasks and identify which of them are higher priority. You appear to be missing this point repeatedly by insisting that volunteers should work on a set of tasks with the same priority, that of "needs volunteer". This simply puts them into an entirely different -- and not very nice -- world.

Let's say that a Team acknowledged that it would do tasks A, B, and C, but it doesn't want to do D or E. Yet D is higher priority than E. How would we convey that to the volunteers? We could either not convey it and set "needs volunteer" priority for them both (which sounds silly to me), or actually use the priority field for its original purpose...

In T268#840749, @Gryllida wrote:

If we invent a way to properly indicate which of these tasks are off the Team radar, then anybody will be able to browse such tasks and identify which of them are higher priority.

Anybody is able to search for open tickets with low and needs volunteer priority - the higher the priority of a task, the sooner a team plans to work on a task. "Properly indicate" does not require inventing a way. It requires people to set realistic priorities and update their tickets to reflect their plans.

In T268#840749, @Gryllida wrote:

If we invent a way to properly indicate which of these tasks are off the Team radar, then anybody will be able to browse such tasks and identify which of them are higher priority.

I think this is more a theoretical scenario than something likely to happen, because this situation implies that there is an official team of busy maintainers (a likely situation), an organized group of volunteers ready to start developing bugfixes and features considered low priority by the maintainers (a rare situation), and at the same time these two separate developer groups will not plan task assignments and priorities together (a very unlikely, surreal, and pretty broken situation).

Your case sounds more about users having different opinions than maintainers about the priorities of tasks, and willing to reflect their opinion, and willing to influence the team priorities. In situations like this, the aspect that is frequently missed is which tasks should be deprioritized in order to prioritize these other ones, but I'm digressing...

You might want to look at what we are doing in the Phabricator upstream project, where we use the "Wikimedia" label to tag tasks that are relevant for us, and then place them in an "Important" or "Details" column, providing a hint to developers about how relevant certain tasks are for us: https://secure.phabricator.com/project/board/404/. This way we don't touch (even less argue about) the priorities assigned by the maintainers.

This solution doesn't scale; they can't have 100 users each one using their labels. Wikimedia got the label when it was clear that we would become the maintainers of one of the biggest Phabricator instances, putting developer resources as well. So we cannot have a label here for e.g. "Gryllida's-Priorities" or "Flow-Community-Lobby". But I could see the usefulness of i.e. "Tech-Ambassadors-Radar" or "MediaWiki Stakeholders' Group" as way to channel and consolidate the most relevant feedback from the communities, as long as these groups would be organized and could agree on the selection and relevance of the tasks they would pick. If an organized process results in task XYZ being placed in the "Important" column of such board, I can see how that could have some real weight focusing discussions and influencing developer plans.

If you are interested in this idea, in this tool, please create a task under Project-Creators, and let's discuss there.

WARNING: You may have received a lot of email, as I am learning to edit comments. And editing them doesn't have a preview button. I apologize. Please read this comment before replying.

Using tags solves the problem, yes. Because we're not abusing priorities field anymore. :)

Let's use a "needs-volunteer" tag, and rename "needs volunteer" priority to "lowest".

(BTW, in my view, we could add such "Tech-Ambassadors-Radar" or "MediaWiki Stakeholders' Group" tags, but only in addition to the "needs-volunteer" tag. Participation in bug reports should be unconditionally open (without conditions on being "organized" or big group).)

Let's use a "needs-volunteer" tag

Well, somebody still needs to set that tag, or remove it when setting an assignee or adding the task to a sprint. Adding some tags is easy, consistently using them not so much. Likely 80% of all the open tasks are not in anybody's list of plans. Instead, teams should set more realistic (=lower) priorities on tasks IMHO.

Ok, I understand, you want to set it to Lowest because you aren't taking it. I am now ok with setting a lowest-ever priority if a Team doesn't want to work on it now. It's relatively painless compared to manually maintaining tags.

However, I'd rather say that any unassigned tasks need volunteers. I just disagree with the name of the lowest priority, right now. Could we change it, and point volunteers to any unassigned tasks instead? Pointing volunteers to lowest priority tasks is not a useful use of their time.

I agree with @Gryllida on this one. Having a "needs volunteer" priority sorta sounds disingenuous. Might as well call a duck a duck and name it "priority: none."

That said, it's quite a bit late to discuss this now as it was already decided a while ago and we have a lot of other important things to work on.

Maybe this should be assigned "priority: needs volunteer" :D

This task can't be done by a volunteer. It's a configuration change that only an admin can do. If anything, it may be "declined".

And you should not give up on your original opinion just because some people insist; your first line is what really matters.

I don't see how to programmatically say that it's related. But it is:

• https://phabricator.wikimedia.org/T78482 XXXX-Radar projects for Wikimedia family projects and languages + MediaWiki Stakeholders

I agree that 'Needs Volunteer' isnt very nice, and doesnt really fit into the Priority scheme. 'Needs Developer' isnt always accurate, as it might not be a development task, and it has the same problem - resourcing is typically (sadly) orthogonal to priority, as paid resources are put onto feature work over high priority bugfixes (and not always commonly desired features) and volunteers typically fix bugs that are itchy rather than have a high priority. Also dedicated human resources (paid or unpaid) are typically working from a workboard, not priority. Team Leads will be using Priority to build the workboard, but they are unlikely to care about Low or any other priority lower than Low.

Why do we need a value beneath 'Low' ?

As this task is closed (and about Priority values in general), let's continue the discussion about the "Needs Volunteer" priority value specifically in T78617 and find consensus there. I've copied the CC/subscribers list.
Thanks everybody!

In T268#793873, @Qgil wrote:

Can you provide examples where this is confusing? Usually a task belongs
more to one team than another. Of two teams share a same task and it had
very different priority for each, then perhaps what happens is that we have
two actual talks embedded in one, or this tells have to sit and discuss a
common approach.

It doesn't say anywhere in the UI that the field reflects the (which?) team's plan, but just "Priority:". If it was labelled "WMF priority:" or "Lead team:"/"Lead team priority:", noone would assume that it is up for discussion.

IIRC the changed meaning of "Priority" has crept in over time in Bugzilla. Earlier on, it usually depicted what the users wanted to prioritize, while later it referred to WMF's work plans.

Or, to put it in another way: If priority is meant to reflect the planning of the assignee of a task (cf. https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels: "Less priority than High, but *you* are still planning to work on it.", etc.), only the assignee should be able to set it.

In T268#849975, @scfc wrote:

Or, to put it in another way: If priority is meant to reflect the planning of the assignee of a task (cf. https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels: "Less priority than High, but *you* are still planning to work on it.", etc.), only the assignee should be able to set it.

I misread "set" as "see", interesting lapsus. :) If "You" defines the priority, only that "You" should see it, as it applies to nobody else.