hide priority if it's just noise for a project

[willkg]

Some projects (SUMO) use the priority column from Bugzilla. Others (MDN) do not. For those that don't, the priority column is just noise and should not get shown.

We talked on IRC about ways to figure out whether priority is used or not:

1. hide it if the priority is the same for all the bugs in the sprint --- this has the edge case where if SUMO had all the bugs at the same priority, the column disappears
2. create a project-level setting for whether to show/hide the priority --- settings are icky and should be avoided, so it'd be better to do something else
3. is there a way to do the bug query url in such a way that it suggests which fields to show?

[willkg]

I had a new idea. What if we have a series of columns that could be shown. Then we pick a default set that get shown by default. Then there's a "show/hide columns" link which you click on, it pops up an overlay, and lets you choose which columns you want shown. Then that gets persisted in a cookie or local storage and affects which columns get shown. Probably do this all in JavaScript on the client-side.

The nice thing about this is that you can show/hide columns as you see fit, it doesn't affect anyone else, it's not really a setting, the defaults could be molded for Luke and MDN, and it makes it easier going forward to add additional columns that only a few people will care about.

[openjck]

Yeah. In fact, we use the priority field for something totally different -- priority reflects the importance of a particular bug to the MDN as a whole, not the importance of that bug to a particular sprint. Something might be very important to the MDN (P1) but still the least important bug in given sprint.

[openjck]

Here's one idea: What if Scrumbugs ignored the "Priority" field altogether and instead used a "sp" whiteboard value, where sp stands for "sprint priority"?

[pmclanahan]

I do like the idea of configurable columns. And I also like a separate "sprint priority" thing, but I'm thinking we'll just implement an ordering mechanism in scrumbugz. I don't think sprint priority is necessary data for bugzilla to house.

[willkg]

I'm +1 for specifying ordering in scrumbugz. It'd be super fancy if it could take depends_on into account.

Also, I think I wrote up this issue because Luke thought the priority was noisy.

[pmclanahan]

Now that we're getting backlog, perhaps priority is useful there, and not in a sprint?

[openjck]

On the topic of ordering mechanisms, I really really love what Launchpad does. A bug is given a priority "score" based on how many dependencies it has, how many people are in the cc: list, whether it's a security issue, and so on. You can see an example here (click the flame icon near the top-right).

I do this manually anyway -- for example, I know that this bug is very important because it has so many duplicates and so many people on the cc: list. Having this information conveyed in Scrumbugs somehow would be amazing.

[willkg]

@pmclanahan Yeah. With the backlog and the fact that sprint data is in scrumbugz now and not in bugzilla, it'd be helpful to have some kind of ordering mechanism. I'll create a new issue for that. After that, we could nix the priority column.

@openjck That sounds like a separate issue.