Topic on Talk:Phabricator

@Johan (WMF) has been thinking about priority levels in Phab this week, and it made me wonder whether we could solve some of the problems by changing the words used in the software. Looking at Phabricator/Project management#Priority levels, here's what I think would be clearer:

Current and proposed labels

Current	Proposed
Needs triage	Not rated
Unbreak now	Blocks weekly deployment
High	I will do this soon
Medium	I will do this
Low	I will do this eventually
Lowest	Needs volunteer

I think that labeling these in terms of what "I will do" will have the effect of discouraging people from setting priorities when their goal is for "somebody else" to do it.

Thanks for sharing this!

I think the underlying problem is the lack of a movement-wide shared understanding of the term "priority". I interpret "priority" as a mix of mostly "urgency" but to some extent also "risk" and "implementation complexity"/"do the benefits outweigh the costs".

First-person phrasing could be confusing if no assignee is set. Who would be "I"? The engineering manager sorting out a team's priorities? I might be less willing to set priorities at all if it implies that I myself commit to doing something when prioritizing tasks on my team's workboard when I personally might not be able to work on a task due to lack of expertise and skills.

Regarding "Needs volunteer", see phab:T78617.

This might also relate to Bug management/Development prioritization.

Should there be a priority set, if nobody's assigned to/working on it? A team/group could agree to set priorities for each other, but I think that discouraging people from setting priorities when they're not doing the work is probably the right thing. If you're not going to do the work (or have permission from the person who is most likely to do the work), then you probably shouldn't set the priority.

Probably there should be a priority set in an ideal world, otherwise you could not organize/sort larger backlogs. This might be also a reason why Kanban got popular but that's only my interpretation (like having higher priority tasks in the current sprint, and medium priority resembling the next sprint, in a very simplified way).

So in most cases the priority should be low but that's not the reality.

The problem is developing shared understanding and definitions (plus as a limitation in Phab, tasks have one priority field but can have several project tags, and one team might think that a task is more urgent than the other team).

Generally, issue tracking systems have very straight-forward priority settings. Either "Lowest/Low/Medium/High" or "P1, P2, P3, P4" or something else similarly short. The *use* and *interpretation* of those straight-forward names are made by individual teams as their needs require. Putting English sentences/phrases in place of those simple words 1) makes translation more difficult and 2) presupposes how all teams interpret the values, which isn't always the same (rarely is!).

Various teams have documented how they interpret the priority levels with such statements as "UBN!s will be triaged and fixed within 3 days" or similar so discovering how they use (or don't use!) priorities is one option (but not *easily* discoverable, certainly).

I wonder whether it would be possible to make the field uneditable by people who shouldn't be changing it. The main problem isn't teams with different ideas of what "medium" priority means (or even whether it means anything; Editing is not setting priorities at all these days). IMO the main problem is non-devs thinking that if they change that field, then it will have the practical effect of changing when the work gets done.

Interesting... is this a common problem that you experience? My impression is not that many folks expect setting the priority field to influence when something gets worked on, expect for Phab newcomers. But my impression is limited as I do not follow each and every task (despite some contrary rumors out there).

Restricting Priority field setting was originally brought up in phab:T819 (and maybe phab:T1178 for those teams rather relying on workboard columns than the Priority field). Historically there once was a "Can Prioritze" setting (see phab:T583), this is not the case anymore and has been replaced by the "Default Edit Policy". So if this was explicitly wanted it would require some custom code changes and their maintenance.

On a related note, Phab nowadays offers Forms (both for creating a task and separately for editing a task) which allow hiding or locking fields (see e.g. phab:T128540); we may want to increase the use of the Forms workflow to also encourage setting task subtypes (bug report vs feature request) in phab:T253744.

> I do not follow each and every task (despite some contrary rumors out there).

Just so you know, I reject this scurrilous rumor. ;-)

The main problem is misunderstandings by Phab newcomers, and the problem is less practical (if I'm doing the work myself, then presumably I know what it's real priority level is) and more about the gap between expectations ("if I type something here, they'll fix this bug now!") and reality (there is usually very little that any non-dev individual can do to affect the speed at which a given bug is addressed), which results in people feeling hurt and angry. It is mostly a "social" problem. If it were possible to "semi-protect" the field, or if the contents of the field were much clearer, then we'd probably have fewer people being sad and angry about Phab.

I wonder if this is really about the "Priority" of tasks in Phab and not about communication in general: If I write on an on-wiki village pump for the first time about a tech problem, wouldn't I have the same "if I type something here, they'll fix this bug now!" expectation as in Phab?

How would "semi-protecting" the field solve a problem? (Unrealistic thought: Wouldn't completely hiding the Priority field everywhere for 'non-developers' only make more sense then?)

Generally speaking, I'd love people to read docs to understand things: There isn't a large pool of developers to immediately look into things; anyone can report anything but not everyone can fix everything. There are also guidelines how to create good Phab tickets which are linked from the ticket creation form; I'd dare to say the majority of "Phab newcomers" ignores them (plus some not so newcomers too, despite my repeated requests). Sadness and anger sometimes, indeed... :-/ Phab tries to cover both "File a technical bug report as a user in a system which is not a black box like with most other software producing places" and "Plan your work as a developer in a public system" and while that's a open source transparency ideal, these two things maybe collide.

I don't think that posting on wiki has the same effect, because you can see that it's a discussion forum. You would probably hope that your report will kick off a chain of events that leads to your desired change being made, but you aren't likely to think that what you type (beyond the natural results of the facts) would directly change how quickly the problem is addressed. That is, if you post on wiki saying "This is broken, please help", you expect the same initial results as if you post "This is broken" or "This is broken and very important".

If we could "semi-protect" the priority field, people would see that they can't change the priority (directly). They can't change the words on the page and they can't change the reality. The appearance and the reality match. Looking at it from a design-ish perspective, if I can't change the reality, why should I be able to change the appearance? Why would someone bother installing an accelerator pedal (or a brake pedal) for passengers in a car, if the pedal doesn't have any effect on how fast the car is moving?

We lose transparency if we hide the information. My point is that the current system is also not transparent: the system falsely tells users that they can change the priority, even if they can't affect it at all.