Page MenuHomePhabricator

Decide on "Priority" field values for Maniphest tasks
Closed, ResolvedPublic

Description

Conversion of Priority field values (added to task description on 2014-07-23):

BugzillaPhabricator
UnprioritizedNeeds Triage
ImmediateUnbreak Now!
HighestUnbreak Now!
HighHigh
NormalMedium
LowLow
LowestNeeds Volunteer


Everything below only for historical reasons.

Andre's initial rough proposal to iterate on, plus some thoughts:

Bugzilla PriorityPhabricator PriorityComments
ImmediateUnbreak Now!
UnprioritizedNeeds Triage
HighestDrop. in a Phab world, this should be covered by making the task a member of a sprint project, I think?
HighHigh
NormalMedium"Normal" is subjective, cf. https://bugzilla.wikimedia.org/show_bug.cgi?id=46020
LowLowOr does "Low" sound too derogative? "Far future"?
LowestLowOr does "Low" sound too derogative? "Far future"?
WishlistI am not very happy with this and it depends highly what "Wishlist" means: Functional feature request vs. I'd wish this bug got fixed? Any ideas? Enhancement requests are independent from Priority (Phab default implementation) and Severity (Bugzilla default implementation), IMHO, plus feels very similar to low priority by default anyway. What is the actual need to differentiate between feature requests and bugs? Pure statistics and influence on burndown statistics?

Global meaning of values: There are some Bugzillas out there using generic priorities like P-1 to P-5 (leaving exact interpretation to teams), but I'd prefer to aim for a shared and global understanding because "outsiders" with their expectations wouldn't need to look up unwritten interpretations of each team.

Why potential drop highest priority: Bugzilla gives you a group of tickets with priority XY, but inside of that group it is currently impossible to make a ranking - which one is first? (cf. page 297 of http://grouplab.cpsc.ucalgary.ca/grouplab/uploads/Publications/Publications/2009-IssueTracking.Report2009-933-12.pdf ). Phabricator will fix this by providing workboards, so I have the naive hope that we'll need less priority values.

Why trying to reduced the number: Though it is not possible to directly transfer findings in other projects / audiences, in Eclipse Bugzilla, "only the second top developer is using the five levels of priority. The rest are using only two or three levels.", plus "While developers are using only three priorities, not all developers are using them in a consistent manner. Some never use priority 1 and 2, and some never use 4 and 5." quoted from http://herraiz.org/papers/english/msr84cp-herraiz.pdf pages 147-148.
(Nota Bene: Those researchers only analyzed ''closed bugs'' in Eclipse Bugzilla but did not clarify if that means FIXED or also other resolutions, plus it is based on the highly questionable assumption that the fields are correctly used, but fixing bug metadata after resolving an issue normally does not take place because nobody cares - see http://www.st.cs.uni-saarland.de/softevo/bugclassify/paper/icse2013-bugclassify.pdf page 396)

Details

Reference
fl436

Event Timeline

flimport raised the priority of this task from to Lowest.
flimport set Reference to fl436.

qgil wrote on 2014-07-09 15:25:53 (UTC)

Sounds good.

My simplified interpretation:

  • "Needs Triage" is exactly what it says in the label.
  • "Unbreak now!", "High", and "Medium" are the tasks that someone is ether working on or having an actual plan to address at some point, in a future sprint.
  • The rest of tasks open are not in anybody's plans, even if they are accepted as good tasks for someone else. Instead of calling them "Low", "Lowest" or "Wishlist", we could be positively explicit and precise by saying "Needs Volunteer".

The end result:

  • Needs Triage
  • Unbreak Now!
  • High
  • Medium
  • Needs Volunteer

Looks clear and discrete to me.

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

importing issue status

flimport closed this task as Resolved.Sep 12 2014, 1:41 AM
Qgil reopened this task as Open.Sep 17 2014, 7:45 PM
Qgil added a subscriber: Qgil.
Qgil raised the priority of this task from Lowest to High.Sep 17 2014, 8:03 PM

Ah, actually this is implemented. Good!

Qgil assigned this task to chasemp.Sep 17 2014, 8:04 PM
Qgil closed this task as Resolved.

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.

Qgil added a comment.Nov 25 2014, 8:47 PM

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.

hoo reopened this task as Open.Nov 26 2014, 1:07 PM
hoo added a subscriber: hoo.

I still think calling a priority (and especially the lowest priority) "Needs volunteer" sounds degrading, as it creates the impression that volunteers only do unimportant stuff that no one cares about ... Also there are higher-priority tasks in various projects that actually need a volunteer to take care of, as there simply is no developer time for that.

Qgil added a comment.EditedNov 26 2014, 1:24 PM

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.

Qgil removed chasemp as the assignee of this task.Nov 26 2014, 1:25 PM
Qgil added a comment.Nov 26 2014, 1:42 PM

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

Qgil lowered the priority of this task from High to Normal.Nov 27 2014, 7:35 AM
Qgil added a project: Phabricator.
Qgil set Security to None.
Qgil moved this task from To Triage to Need discussion on the Phabricator board.
Qgil added a subscriber: Awjrichards.

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.

scfc added a comment.Nov 28 2014, 8:52 PM

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.

Qgil added a comment.Nov 28 2014, 11:00 PM

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.

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Qgil closed this task as Resolved.Dec 8 2014, 8:22 AM
Qgil claimed this task.

The discussion seems to be settled. Resolving.

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

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

Qgil added a comment.Dec 10 2014, 1:09 PM

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:

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.

Qgil added a comment.Dec 10 2014, 10:30 PM

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

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.

Qgil added a comment.EditedDec 11 2014, 11:00 AM

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.

This comment was removed by Gryllida.
This comment was removed by Gryllida.
This comment was removed by Gryllida.
Gryllida added a comment.EditedDec 11 2014, 11:15 AM

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.

mmodell added a subscriber: mmodell.EditedDec 12 2014, 6:56 AM

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.

He7d3r added a subscriber: He7d3r.Dec 13 2014, 11:41 PM

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

jayvdb added a subscriber: jayvdb.Dec 15 2014, 10:39 AM

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!

scfc added a comment.EditedDec 16 2014, 9:10 AM
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.