[Development] Priority field in Jira

[Mitch Curtis]

>From: Volker Hilsheimer <volker.hilsheimer at qt.io>
> 
> The priority field changes it’s meaning during the lifetime of the bug report:
> 
> * in the beginning, it tells us how important it is for the reporter of the bug. This is useful.

This is news to me; I've not once heard of it being used this way. I also question the usefulness of a field that has two meanings over time. Why not have two fields with distinct meanings that can't be confused and that result in no extra work? However little that work may be, it's still unnecessary. This solution is even more "inclusive" [1], as well.

I would argue that a good bug report should explain what the consequences of a bug are and how this affects the user's application. I have asked for this exact information in several instances in the past and it greatly helped me come up with a suitable priority. If this information is not initially present in the report, this question has to be asked eventually anyway. When you ask what the consequences of a bug are and how it affects the end user, you can quite easily come up with an objective assessment of the priority of that bug, and of course any +1 comments, votes and watchers can naturally increase that priority over time to some extent.

> * after triaging (which we do regularly, at least in The Qt Company), it tells us how important it is for the Qt Company (and perhaps the Qt community/project at large)

But if the initial priority as reported by the customer is important, then you've just lost it by overriding during triage (not many people are going to check the "All" tab to see the history). This might solve the issue of being "inclusive", but then becomes a lack of transparency.

> Anything that is still a P0 after triaging should be treated as such: unplanned work that needs to be fixed so urgently that it preempts any planned work.
> 
> For everything else: if you are in a team that plans their work weeks based on JIRA tickets, then the priority of a ticket is one piece of information for that planning process.
> 
> Not allowing reporters to set priority removes a piece of information, but shouldn’t change anything else, so I’m not convinced that we should limit things by default.

Most reports are created with priorities left as unevaluated, so by now we should be used to coming to a conclusion about the priority without an initial assessment from the reporter. This is something I think the bug triaging duties are great for getting better at, and I think pretty much everyone in the company does a good job at assessing priorities.

> If reporters consistently abuse their privilege, in spite of dialogue and feedback, then we might need to find more effective ways to deal with those particular reporters.

To be clear: I've probably ever only had a ping-pong issue once, so I'm not claiming that that is a problem. I'm just questioning whether our process could be more efficient.

[1] Though if you look another popular open source project with a public bug tracker with lots of bugs, you'll see that reporters have even less freedom in managing a report and somehow it works fine: https://github.com/godotengine/godot/issues