== Situation ==
In Wikimedia Bugzilla you can set a priority for a bug report. Some people and teams set highest priority often (meaning "These issues should get fixed first in the next weeks"). Some don't set it at all (and likely related: Some teams don't really use Bugzilla but other tools). Some are in-between. This use might work well for each team.
* Currently there are 15 open tickets with highest priority: https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=-... (You might only see 14 if you don't have access to security bugs) * 5 of them have highest priority for more than 30 days: https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=-... * 2 of them for more than 90 days (Huggle vs IPv6; moving to EQIAD): https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=-... The latter imply either missing maintainership (Huggle?) or tasks that take longer (EQIAD) and could be broken down into subtasks.
== Problem ==
Currently "Highest Priority" has no single (cross-team) meaning. This makes it hard for people outside of a team (e.g. Engineering Management) to see at a glance what's most important and urgent for each team.
== Proposal ==
Proposing the following definitions for Priority: * highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field. * high: Should be fixed within the next four weeks.
andre
On 11/19/2012 08:33 PM, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field.
- high: Should be fixed within the next four weeks.
You don't refer to it, so I assume you haven't seen https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority where all this was spelled out before.
(I don't see the assignee bit there -- "A human assignee should be set..." -- but that sounds like how I tried to use highest before.)
Mark.
Mark A. Hershberger wrote:
On 11/19/2012 08:33 PM, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field.
- high: Should be fixed within the next four weeks.
You don't refer to it, so I assume you haven't seen https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority where all this was spelled out before.
(I don't see the assignee bit there -- "A human assignee should be set..." -- but that sounds like how I tried to use highest before.)
Andre didn't refer to that page, but he edited it on November 2, 2012: https://www.mediawiki.org/w/index.php?title=Bugzilla/Fields&action=histo...
So I think it's fair to assume that he's familiar with it. ;-)
For what it's worth (and not to ruin the "silence is consensus" model), the proposed priority scheme sounds fine to me. Traditionally these fields have been mostly ignored by just about everyone (developers included). High priority bugs have many other ways of making themselves high priority; they really don't need help from a drop-down menu, but if you can increase the utility (or perceived utility) of that field, go for it. :-)
MZMcBride
On Mon, Nov 19, 2012 at 7:54 PM, MZMcBride z@mzmcbride.com wrote:
For what it's worth (and not to ruin the "silence is consensus" model), the proposed priority scheme sounds fine to me. Traditionally these fields have been mostly ignored by just about everyone (developers included). High priority bugs have many other ways of making themselves high priority; they really don't need help from a drop-down menu, but if you can increase the utility (or perceived utility) of that field, go for it. :-)
Andre has been tasked with curating the list of highest priority bugs so that it makes sense to pay attention to the list.
For the engineers in Platform Engineering, we've been pretty good at paying attention to the priorities of bugs assigned to team members. We've fallen off the wagon when it comes to triaging unassigned issues with the "platformeng" keyword, but that may be something we ask for Andre's help on as well (later)
Rob
On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field.
- high: Should be fixed within the next four weeks.
Any other opinions, especially by project/product managers? Or does silence mean "I don't really care, go ahead"?
andre
On 26 November 2012 10:51, Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field.
- high: Should be fixed within the next four weeks.
Any other opinions, especially by project/product managers? Or does silence mean "I don't really care, go ahead"?
For VisualEditor, this is pretty much how I use it *when in conjunction with a release window* - i.e. "Highest" and "2012-11-26" meant that it was one of the top priority things for the milestone that went out on the deploy train this morning, so it would have been worked on and hopefully closed within that two-week period (of course, some things take longer).
However, I'd also expect "High"-tagged bugs to get fixed in that two week period; I suppose that the one week / four weeks split it about right, but I worry about "Highest"-tagged bugs for work that doesn't need to land for months. Just because it's not urgent doesn't mean it's not important. The problem is that our "priority" field refers mostly to the second and a little to the first, and our "Severity" refers mostly to the first, but partially to release management work ("Blocker" is not a statement of severity of the problem, but a prioritisation flag about whether we can release the code; "Enhancement" similarly is not about severity but about work priority).
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Thanks for tackling this, Andre!
I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone. Different teams/products use bugzilla to varying degrees and in different ways, and a reasonable time frame resolving a 'high' priority bug may be different depending on the specific component. Additionally, a bug's 'importance' in bugzilla may not directly map to other priorities they have (managed elsewhere), and it's up to each team/maintainer/etc to figure out how to prioritize bugzilla bugs relativel to everything else on their plates.
That said, I think it makes a LOT of sense to have a shared understanding of what things like 'importrance' in bugzilla actually means. It might be more useful to come up with a rubric of meanings for the different priorities instead of time constraints (or at least instead of thinking of bugs in terms of 'this should be resolved within the week') - eg:
* Highest = a mission-critical component is broken in such a way as to make the component completely unable to fulfill its purpose (eg credit card processing is broken in DonationInterface), or is a serious security or privacy vulnerability, or otherwise immediately threatens the health of the cluster * High = a mission-critical component is broken in such a way that does not prevent the component from totally fulfilling its purpose but greatly impedes its functioning/utility, or an issue that might not immediately threaten the health of the cluster but has potential to cause major problems if left unattended to (eg a performance issue that isn't causing problems now but will start causing problems a month from now) * Normal = an issue that does not affect a mission-critical component in such a way to to prevent it from fulfilling its purpose, but has a significant negative impact on users that may be addressable with a workaround * Low = an issue that does not affect a mission-critical component in such a way as to prevent it from fulfilling its purpose, is has low impact on users, and may be addressable with a simple workaround * Lowest = an issue that does not affect a mission-critical component in such a way as to prevent it from fulfilling it purpose, has minimal impact on users, addressable with trivial workaround or can otherwise be easily ignored
I'm not suggesting we necessarily go with these definitions, but rather offering these as an example of potential meanings for the different priorities. To me this is a much more useful approach than trying to define importance using timeframes, as timeframes are going to be (and should be) totally dependent on the responsible teams/maintainers/etc to figure out.
Thanks again for working to get bugzilla on track - I look forward to the bright future of our bug tracking system :)
On Mon, Nov 26, 2012 at 1:29 PM, James Forrester jforrester@wikimedia.orgwrote:
On 26 November 2012 10:51, Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field.
- high: Should be fixed within the next four weeks.
Any other opinions, especially by project/product managers? Or does silence mean "I don't really care, go ahead"?
For VisualEditor, this is pretty much how I use it *when in conjunction with a release window* - i.e. "Highest" and "2012-11-26" meant that it was one of the top priority things for the milestone that went out on the deploy train this morning, so it would have been worked on and hopefully closed within that two-week period (of course, some things take longer).
However, I'd also expect "High"-tagged bugs to get fixed in that two week period; I suppose that the one week / four weeks split it about right, but I worry about "Highest"-tagged bugs for work that doesn't need to land for months. Just because it's not urgent doesn't mean it's not important. The problem is that our "priority" field refers mostly to the second and a little to the first, and our "Severity" refers mostly to the first, but partially to release management work ("Blocker" is not a statement of severity of the problem, but a prioritisation flag about whether we can release the code; "Enhancement" similarly is not about severity but about work priority).
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards arichards@wikimedia.org wrote:
I'm not suggesting we necessarily go with these definitions, but rather offering these as an example of potential meanings for the different priorities. To me this is a much more useful approach than trying to define importance using timeframes, as timeframes are going to be (and should be) totally dependent on the responsible teams/maintainers/etc to figure out.
Hi Arthur,
Timeframes seem like a pretty good proxy for priority. If something is "highest" priority, and yet is not on track to be completed for several months, then.....wait, what?
Your definitions of priority strike me as redefining the field as a "severity" field, which makes it redundant and also not terribly useful as a prioritization tool. Sometimes, if a feature isn't very important, it can have a very severe bug against it that is low priority.
At a minimum, can we agree that no single developer should have multiple "highest" priority bugs assigned to them? Can we also agree that "highest"/"unassigned" is a state that we shouldn't leave any bug in for very long at all?
Maybe we'll need to cede the priority field to a team-only status, but I'm pretty skeptical that each team is such a unique and delicate flower that we can't agree to some rough guideline for at least "highest" priority. "High" and "normal" are more debatable, but I suspect we can also come up with very broad definitions that everyone can abide by.
Rob
On 26 November 2012 17:25, Rob Lanphier robla@wikimedia.org wrote:
On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards arichards@wikimedia.org wrote:
I'm not suggesting we necessarily go with these definitions, but rather offering these as an example of potential meanings for the different priorities. To me this is a much more useful approach than trying to define importance using timeframes, as timeframes are going to be (and should be) totally dependent on the responsible teams/maintainers/etc to figure out.
Timeframes seem like a pretty good proxy for priority. If something is "highest" priority, and yet is not on track to be completed for several months, then.....wait, what?
I disagree. In 1962, NASA's "highest" (most-high?) priority was to put a human on the Moon; that doesn't mean they achieved it before 1969. High priority and soonness-to-be-done are orthogonal. More prosaically, VE's most-high priority task in July was to deploy a test version of the VisualEditor to the English Wikipedia in December; it's now only a few weeks away, but for the past five months it's remained our most-high priority, whilst we've worked on things to support that.
At a minimum, can we agree that no single developer should have multiple "highest" priority bugs assigned to them?
No? If you have a few dozen bugs in "your" area of the product/component, two or three of them being the "ones I really must get done before the others" isn't a bad concept. It's always /nice/ if you have at most one bug in "highest" (ideally, none) but that's an ideal case rather than the real world in most cases.
To put it another way: in my mind, "highest" refers to the box these bugs sit in, not the individual bugs themselves. You can have lots of bugs in the "top" priority, or none, and in general you start at the "top" of these boxes and work "down".
Can we also agree that "highest"/"unassigned" is a state that we shouldn't leave any bug in for very long at all?
Indeed, completely agreed with that.
Maybe we'll need to cede the priority field to a team-only status, but I'm pretty skeptical that each team is such a unique and delicate flower that we can't agree to some rough guideline for at least "highest" priority. "High" and "normal" are more debatable, but I suspect we can also come up with very broad definitions that everyone can abide by.
Agreed, but I think that this is inextricably linked with the wider set of fields in Bugzilla and whether they're fit for purpose; I thought there was an RFC about changing BZ's fields, but I can't find it now...
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote:
On 26 November 2012 17:25, Rob Lanphier robla@wikimedia.org wrote:
Timeframes seem like a pretty good proxy for priority. If something is "highest" priority, and yet is not on track to be completed for several months, then.....wait, what?
I disagree. In 1962, NASA's "highest" (most-high?) priority was to put a human on the Moon; that doesn't mean they achieved it before 1969. High priority and soonness-to-be-done are orthogonal.
I've been made aware (off-list) of some concerns of this proposal, and your comment provides the same sentiment.
The term "highest priority" has some ambiguity in human language. It's perfectly fine to state that a bunch of bug reports are "highest priority": Issues that a team is working on currently, or should work on as the very next task. My initial proposal was to make "highest priority" mean "really urgent" or "immediate". Consequently, this should also be reflected by its name. Still there should be a way to express what's highest priority for a team.
== Reworked proposal: New "Immediately" priority ==
I propose adding a *new* priority called "Immediate" which should only be used to mark really urgent stuff to fix. This priority would be added above the existing "Highest" priority.
[I'm going to respond to the wider "priority vs. severity vs. target milestones vs. does this all make sense together" discussion in a separate email.]
andre
On 27 November 2012 16:39, Andre Klapper aklapper@wikimedia.org wrote:
I propose adding a *new* priority called "Immediate" which should only be used to mark really urgent stuff to fix. This priority would be added above the existing "Highest" priority.
Has anyone suggested a separate "urgency" parameter?
- d.
On Tue, 2012-11-27 at 16:49 +0000, David Gerard wrote:
Has anyone suggested a separate "urgency" parameter?
I don't think adding another parameter in the user interface improves anything. We have already "Priority", "Severity", "Target milestone" and blocker bugs that are all used to somehow express some "ranking of issues" (to avoid terms like prioritization or severness).
andre
On 27/11/2012 09:55, Andre Klapper wrote:
On Tue, 2012-11-27 at 16:49 +0000, David Gerard wrote:
Has anyone suggested a separate "urgency" parameter?
I don't think adding another parameter in the user interface improves anything. We have already "Priority", "Severity", "Target milestone" and blocker bugs that are all used to somehow express some "ranking of issues" (to avoid terms like prioritization or severness).
andre
Perhaps merging the priority and severity ones, and only then adding the urgency, might work, though, since then the wording could be a lot less ambiguous. Not that it would make a whole lot of difference what anything is called so long as the specific fields aren't even bloody labelled, but that's another issue entirely.
Le 27/11/12 17:49, David Gerard a écrit :
On 27 November 2012 16:39, Andre Klapper aklapper@wikimedia.org wrote:
I propose adding a *new* priority called "Immediate" which should only be used to mark really urgent stuff to fix. This priority would be added above the existing "Highest" priority.
Has anyone suggested a separate "urgency" parameter?
Usually the priority is the result of both severity and urgency and is determined using a matrix.
Severity would be how much it impacts our mission, for example how many users are facing the issue. Gerrit being down is less a severity than having a US datacenter in fire (literally).
Urgency is how fast you are required to fix the incident, this is usually associated with service level agreement contracted with the users. Not providing the database dump would probably be an SLA of one week whereas providing the wikis main pages is probably a 1 minute SLA.
Whenever an incident is triaged, people evaluate the impact and urgency depending on the context of the incident. Given a very simple system with only two levels (low / high) here are four examples representing all possibilities:
Change a MediaWiki setting for the Klingon wikipedia urgency : low (the change request the links to be green) severity : low (there is only a few reader for that wiki)
A database is almost out of disk space: urgency : high (whenever it is filled up we will have a major outage) severity : low (nobody is affected yet)
People get disconnected from they sessions and need to relog urgency : low (that is annoying but users can still read content) severity: high (a lot of people are facing the issue)
Wiki serving blank pages: urgency : high (our mission to share knowledge is no more fulfilled) severity: high (nobody can read content)
So now how do you determine the priority? Just assign increasing scores to each level, sum them, the highest score deserves all your attention.
Given low receives 0 points and high receives 1 point, the priorities would be something like:
0 : low - respond under 1 week, resolution target is month 1 : high - respond in 1 day, resolution target is week 2 : critical - respond immediately, resolution target is hour
Then you could add a specific status known as a major incident that would have a very specific process attached to it. Usually because you want C-Level to be made aware of it, have to gather peoples from different teams in the same place, assign someone managing everyone and finally having someone in charge of communicating with the users.
Building an incident process is definitely a though task but we are lucky to have smart people in our teams and lot of available literacy available from people that had to implements such process before us :-)
On Tue, 2012-11-27 at 17:39 +0100, Andre Klapper wrote:
I propose adding a *new* priority called "Immediate" which should only be used to mark really urgent stuff to fix. This priority would be added above the existing "Highest" priority.
1) Look at the current distribution of priorities at https://bugzilla.wikimedia.org/report.cgi?y_axis_field=&cumulate=0&z... and see that "Normal" in the center is the clear peek.
Realistically, a way larger amount of reports should be low priority: Nobody working on it, and nothing will happen soon without sudden unlimited manpower.
2) Look at our priority definitions in https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority
a) "normal" means "Should be fixed by the next release."[1] This is extremely unrealistic with above usage of "Normal".
b) There is no real difference between "would be good to get fixed somewhere in the future" (low) and "can be fixed, but we're not going to worry about it" (lowest). Hence no good reason to keep them separately. We need to be able to differentiate on *important* stuff instead.
So in a mysterious future not that far away, I'd like to merge "Normal" and "Low", or "Low" and "Lowest" priorities.
Combined with a new "Immediate" priority as proposed above (quoting myself), we would keep the same number of priorities, but we'd communicate way more realistic expectations on fixing issues by moving the peek from the center to the right, where "Low priority" lives.
andre
[1] "normal" priority meaning "Should be fixed by the next release" should be questioned too, but I'd prefer to NOT do it as part of this thread but do that later.
PS: Bonus material: Which priorities do other Bugzillas use?: KDE: {VHI, HI, NOR, LO, VLO} Mozilla: {P1, P2, P3, P4, P5, --} Mer: {High, Normal, Low, Undecided} GNOME: {Immediate, Urgent, High, Normal, Low} FreeDesktop.org: {Highest, High, Medium, Low, Lowest}
-- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
On 27 November 2012 17:09, Andre Klapper aklapper@wikimedia.org wrote:
- Look at our priority definitions in
https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority a) "normal" means "Should be fixed by the next release."[1] This is extremely unrealistic with above usage of "Normal".
You may be up against human nature there. How about SERIOUS, VERY SERIOUS, PROFOUNDLY SERIOUS, HIDEOUSLY SERIOUS, OH MY GOD WE'RE ALL GONNA DIE , where the documentation shows that the last one actually means "yeah, we should get around to looking at that some time"? That would fit human nature as applied to bug reporting ;-)
- d.
Andre Klapper aklapper@wikimedia.org wrote:
[...] So in a mysterious future not that far away, I'd like to merge "Normal" and "Low", or "Low" and "Lowest" priorities.
Combined with a new "Immediate" priority as proposed above (quoting myself), we would keep the same number of priorities, but we'd communicate way more realistic expectations on fixing issues by moving the peek from the center to the right, where "Low priority" lives.
If at the moment the priority field neither necessarily triggers action nor reflects the actual state of affairs, why even bother and not just delete/hide it from view? This would free more time to fix bugs.
[...] PS: Bonus material: Which priorities do other Bugzillas use?: KDE: {VHI, HI, NOR, LO, VLO} Mozilla: {P1, P2, P3, P4, P5, --} Mer: {High, Normal, Low, Undecided} GNOME: {Immediate, Urgent, High, Normal, Low} FreeDesktop.org: {Highest, High, Medium, Low, Lowest}
Not to quote from another video about GitHub (where "issues" have only title and comment), let's not forget Git: No bug- tracker at all :-).
Tim
On Tue, Nov 27, 2012 at 11:23 PM, Tim Landscheidt tim@tim-landscheidt.de wrote:
[...] Not to quote from another video about GitHub (where "issues" have only title and comment), let's not forget Git: No bug- tracker at all :-).
Tim
According the http://git-scm.com/community page: "Bug reports should be sent to this mailing list."
So it seems the Git development mailing list is the bug tracker.
On Tue, 2012-11-27 at 22:23 +0000, Tim Landscheidt wrote:
If at the moment the priority field neither necessarily triggers action nor reflects the actual state of affairs, why even bother and not just delete/hide it from view? This would free more time to fix bugs.
I don't see how dropping it all together helps planning or how it "frees more time". Obviously anybody is free to work on anything but some stuff simply is more important than other stuff. I understand that there are many options and ways to express that importance though, and that "severity", "priority", "target milestones", "blocker bugs" have some ambiguity to discuss in the long run. Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
Not to quote from another video about GitHub (where "issues" have only title and comment), let's not forget Git: No bug- tracker at all :-).
I'm happy if using http://dir.gmane.org/gmane.comp.version-control.git works well for the Git developers and if important issues don't get lost. There are many ways and tools how to do software development, some work well for some, others work well for others, and not every tool is needed by everybody. GitHub itself has a bugtracker ("Issues" tab) by the way.
andre
On Wed, Nov 28, 2012 at 9:32 AM, Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2012-11-27 at 22:23 +0000, Tim Landscheidt wrote:
If at the moment the priority field neither necessarily triggers action nor reflects the actual state of affairs, why even bother and not just delete/hide it from view? This would free more time to fix bugs.
I don't see how dropping it all together helps planning or how it "frees more time". Obviously anybody is free to work on anything but some stuff simply is more important than other stuff. I understand that there are many options and ways to express that importance though, and that "severity", "priority", "target milestones", "blocker bugs" have some ambiguity to discuss in the long run. Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
I think the priority field is important. And I sometimes use it for finding bugs to fix (or you know, did back when I had more free time and went around fixing random bugs).
What I would really like to see is banning users from touching the priority field. The field is made rather useless by bug reporters who feel their pet issue is the most important thing to ever happen - and suddenly there's a whole lot of issues at highest. Of course I would still like to see triaging people setting the field - just not the randoms who think by marking their bug highest priority it will actually be treated like highest priority.
Some of the suggestions mentioned earlier for priority meanings seem a bit inflated to me. At most times there's not a huge number of high priority issues (Limited person power = not everything can be fixed instantly) - Thus the field should be more distinguishing on the lower end of the spectrum. I personally think that the following would more reflect reality: lowest = nobody cares. If somebody cares they can fix it, and we won't stop them low = Not very important. Maybe one day if I'm very bored. If this issue never got fixed I wouldn't loose too much sleep Normal = Your average bug (Realizing that your average bug isn't very important). This should get fixed at some point. Doesn't have to be at next release - But if I was browsing Wikipedia 5 years from now I hope I don't encounter the issue High = This was kind of bad. Unless there is some very good reason we cannot, this should be fixed by next release. Preferably in the next month if it is not a large amount of work Highest = This is a major issue. Somebody should be working on this right now. If somebody sets this to high they should either be working on the issue, or working to find someone to fix the issue.
An alternative way of looking at priority, is instead of how long it should take to fix - look instead at how long it should take before somebody starts to look into/begin fixing the issue.
-bawolff
On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper aklapper@wikimedia.org wrote:
Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
This.
Also....
On Wed, Nov 28, 2012 at 9:56 AM, bawolff bawolff+wn@gmail.com wrote:
An alternative way of looking at priority, is instead of how long it should take to fix - look instead at how long it should take before somebody starts to look into/begin fixing the issue.
I'm comfortable with this as a compromise.
Also, it's worth noting that the most productive use of Bugzilla is going to be for things that take less than a month of dedicated, focused developer time. Any task that's bigger should be broken down into smaller tasks. Using the moon landing metaphor, it's not as though the NASA folks basically went to work every day saying "this is the day we're going to land on the moon", trying and failing every day until July 21, 1969. There were a few interim steps in there, and heck, I'll bet you they even wrote them down somewhere.
Point being: it's fine for something big to be "highest" priority, so long as it's a tracking bug, and there's a smaller subtask somewhere that is also "highest". I would maintain that the subtask is the *only* thing that should have "highest" priority, because saying that the ultimate goal is the "highest" priority, while maybe strictly accurate, is an empty gesture. It doesn't help us organize our work. It's also not even terribly accurate, since the whole "landing on the moon" thing wasn't the highest priority until Apollo 11 got to the moon, and before that got off the ground, and before that...yadda yadda. Yes, it was always helpful to have the ultimate goal in mind, but I'm going to go out on a limb and say that they didn't use an issue tracker for that.
However, I don't care as we take care of this:
On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper aklapper@wikimedia.org wrote:
Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
Rob
On Wed, Nov 28, 2012 at 12:56 PM, bawolff bawolff+wn@gmail.com wrote:
What I would really like to see is banning users from touching the priority field. The field is made rather useless by bug reporters who feel their pet issue is the most important thing to ever happen - and suddenly there's a whole lot of issues at highest. Of course I would still like to see triaging people setting the field - just not the randoms who think by marking their bug highest priority it will actually be treated like highest priority.
Although Bugzilla isn't a wiki, it might still be helpful to follow the
wiki principle of letting it remain easy to fix people's bad changes (e.g. setting the wrong priority) rather than tying their hands from making those changes. Could we instead draw users' attention to the page listing what all the different priorities mean, e.g. by having Bugzilla ask "Are you sure this meets the criteria for a highest priority bug?" and then linking to http://www.mediawiki.org/wiki/Bugzilla/Fields#Priority ?
On Nov 27, 2012, at 5:39 PM, Andre Klapper aklapper@wikimedia.org wrote:
On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote:
On 26 November 2012 17:25, Rob Lanphier robla@wikimedia.org wrote:
Timeframes seem like a pretty good proxy for priority. If something is "highest" priority, and yet is not on track to be completed for several months, then.....wait, what?
I disagree. In 1962, NASA's "highest" (most-high?) priority was to put a human on the Moon; that doesn't mean they achieved it before 1969. High priority and soonness-to-be-done are orthogonal.
I've been made aware (off-list) of some concerns of this proposal, and your comment provides the same sentiment.
The term "highest priority" has some ambiguity in human language. It's perfectly fine to state that a bunch of bug reports are "highest priority": Issues that a team is working on currently, or should work on as the very next task. My initial proposal was to make "highest priority" mean "really urgent" or "immediate". Consequently, this should also be reflected by its name. Still there should be a way to express what's highest priority for a team.
== Reworked proposal: New "Immediately" priority ==
I propose adding a *new* priority called "Immediate" which should only be used to mark really urgent stuff to fix. This priority would be added above the existing "Highest" priority.
[I'm going to respond to the wider "priority vs. severity vs. target milestones vs. does this all make sense together" discussion in a separate email.]
I don't think adding more fields/values is the solution. Perhaps use milestone for "immediate"?
So both "Get man on the moon (tracking)" and "[Regression] Bike shed should not be on fire" have highest priority. But one is a regression milestoned for the current release, and the other is on track for N+2 release or maybe "Future release".
Besides an "immediate" bug without a milestone doesn't make sense to start with? If that is possible, there is a missing milestone I guess.
We should make more use of being able to combine and query different fields to express clarity instead of adding more options that represent a multiple of values in other fields which then also need to be set separately (Commons categories comes to mind, like "Category:Blue objects made of recycled glass hanging upside-down in Amsterdam, Netherlands").
-- Krinkle
On Wed, 2012-11-28 at 00:36 +0100, Krinkle wrote:
I don't think adding more fields/values is the solution. Perhaps use milestone for "immediate"?
Currently milestones are used in "MediaWiki" for tarballs (that we don't create for MW 1.21), in "VisualEditor" for deployments (VE-2012-12-34), and globally in "MediaWiki Extensions" for branches refering to a MediaWiki version. See my last two lines down there in this email.
So both "Get man on the moon (tracking)" and "[Regression] Bike shed should not be on fire" have highest priority. But one is a regression milestoned for the current release, and the other is on track for N+2 release or maybe "Future release".
For the "MediaWiki" Bugzilla product: The conflict would be "wmf deployments" vs "MW tarballs". We currently use TMs for MW tarballs and we have a "1.20.x", "1.21.0" there. We tag regressions with a "code-update-regression" keyword. For issue that should block wmf deployments the blocker bug 38865 is used (which is not great but I plan to tackle this later, not now).
Besides an "immediate" bug without a milestone doesn't make sense to start with? If that is possible, there is a missing milestone I guess.
It's possible. Immediate means immediate. ;) If it should block wmf deployment, also mark it as blocking bug 38865. If it should block an MW tarball, set the Target Milestone accordingly.
We should make more use of being able to combine and query different fields to express clarity instead of adding more options that represent a multiple of values in other fields which then also need to be set separately
I agree in the long run, but it might interfere with teams and their use of Bugzilla again. Global workflows vs. "this works for my team". Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
andre
On Nov 27, 2012, at 2:36 AM, James Forrester jforrester@wikimedia.org wrote:
On 26 November 2012 17:25, Rob Lanphier robla@wikimedia.org wrote:
Timeframes seem like a pretty good proxy for priority. If something is "highest" priority, and yet is not on track to be completed for several months, then.....wait, what?
I disagree. In 1962, NASA's "highest" (most-high?) priority was to put a human on the Moon; that doesn't mean they achieved it before 1969. High priority and soonness-to-be-done are orthogonal. More prosaically, VE's most-high priority task in July was to deploy a test version of the VisualEditor to the English Wikipedia in December; it's now only a few weeks away, but for the past five months it's remained our most-high priority, whilst we've worked on things to support that.
I agree with Rob, there is a strong correlation between priority and milestone. However, I don't believe they are linked enough to be able to merge them.
Last year I proposed to replace Priority, Severity and Milestone with just Milestones. However I now believe that Priority and Timeframe (milestone) should stay separate.
On Nov 27, 2012, at 2:25 AM, Rob Lanphier robla@wikimedia.org wrote:
Your definitions of priority strike me as redefining the field as a "severity" field, which makes it redundant and also not terribly useful as a prioritization tool.
It seems Severity (or Priority) is redundant in practice. Severity may be useful for statistical purposes afterwards, but given that it is rarely useful for anything other than "enhancement", we might as well drop it and just have a tag for "enhancement" (like for "regression").
Highest priority is the next primary feature in a component and/or a critical bug that needs fixing. Both are very important, but one is long-term the other short-term (as James demonstrates well with the NASA example).
On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the
most. A human assignee should be set in the "Assigned to" field.
I'd recommend we also require a Milestone to be set for "Highest" priority tickets.
That way it is clear to both the assigned developer and the community what the expectations are.
-- Krinkle
Hi Arthur,
On Mon, 2012-11-26 at 14:54 -0700, Arthur Richards wrote:
I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone.
With regard to the wider picture, the confusing and partially unclear concept "severity vs priority vs target milestone vs importance" can and should be discussed in the long run.
For the specific problem I'd like to solve in the short run, we need to agree on a way to mark an issue as "we must fix this report as soon as possible and should drop nearly all over ongoing work".
It might be more useful to come up with a rubric of meanings for the different priorities - eg:
- Highest =
[snip]
- Lowest =
I like your definitions a lot as they are very descriptive and provide clear criteria, but to me they fit very well with what "severity" (blocker, critical, ..., trivial, enhancement) in Bugzilla is supposed to mean.
andre
Rob and Andre, I hear what you're saying. I think I've always had a lack of clarity around the meanings of priority/urgency/severity/whatever in bugzilla, and it sounds like I'm not alone :p. That said, I still do not think timeframes are a good proxy for priority (a la James' example). I think of priority in terms of value - the highest priority items should be the ones that result in the most value - that could be fixing totally broken credit card processing in DonationInterface in the middle of the fundraiser, enabling a new mobile feature for editing an article, etc. Of course, it's difficult to define what that means in our case since we're not selling anything, but the principle remains the same. I think priorities should always be relative to one another and I think defining the temporal scope of a bug without actually knowing what the bug is is a very arbitrary and not particularly useful way to approach the problem. The 'highest' priority items should be getting worked on ahead of 'normal' priority items, and they should be finished as soon as whoever is working on them is... finished.
Part of the reason I suggested the rubric the way that I did is because that's what we wound up doing to define task priorities in the midst of the 2011 fundraiser. After the 2011 fundraiser started and issues started sprouting up, it was difficult to not feel like every issue was a 'fire' - that is something that needed to be dealt with immediately. We then defined a rubric for what a 'fire' actually was, or what made one thing more important to work than another. This gave us a shared understanding of what was most valuable. This made prioritizing issues in a way that everyone could mostly agree on/understand trivial. Temporality had nothing to do with it, but it was understood that we always work on issues in priority order.
After thinking about this some more, I realized that my reaction to the proposal in part came from feeling apprehensive about external forces defining bug priorities/resolution timelines, and thereby defining how a team must respond to issues in bugzilla. Who would be (is?) responsible for setting bug priorities? Given that teams rely on bugzilla in different ways, organize their work in different ways, and likely have differing criteria for defining what priority a bug/task/etc should have, it seems it ought to be fully up to the team responsible for dealing with issues in bugzilla to prioritize them (rather than directly from some external actor). Of course this prioritization should be informed by people/things beyond the team, but at the end of the day prioritization should be managed by the team/maintainer responsible for the issue.
On Tue, Nov 27, 2012 at 9:50 AM, Andre Klapper aklapper@wikimedia.orgwrote:
Hi Arthur,
On Mon, 2012-11-26 at 14:54 -0700, Arthur Richards wrote:
I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone.
With regard to the wider picture, the confusing and partially unclear concept "severity vs priority vs target milestone vs importance" can and should be discussed in the long run.
For the specific problem I'd like to solve in the short run, we need to agree on a way to mark an issue as "we must fix this report as soon as possible and should drop nearly all over ongoing work".
It might be more useful to come up with a rubric of meanings for the different priorities - eg:
- Highest =
[snip]
- Lowest =
I like your definitions a lot as they are very descriptive and provide clear criteria, but to me they fit very well with what "severity" (blocker, critical, ..., trivial, enhancement) in Bugzilla is supposed to mean.
andre
Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 27/11/12 19:26, Arthur Richards wrote:
After thinking about this some more, I realized that my reaction to the proposal in part came from feeling apprehensive about external forces defining bug priorities/resolution timelines, and thereby defining how a team must respond to issues in bugzilla. Who would be (is?) responsible for setting bug priorities? Given that teams rely on bugzilla in different ways, organize their work in different ways, and likely have differing criteria for defining what priority a bug/task/etc should have, it seems it ought to be fully up to the team responsible for dealing with issues in bugzilla to prioritize them (rather than directly from some external actor). Of course this prioritization should be informed by people/things beyond the team, but at the end of the day prioritization should be managed by the team/maintainer responsible for the issue.
Well, I don't think you would need to ban people not in your group from touching those fields. You only need to take into account who said that as well as what they said. Even when having a shared meaning, it doesn't hold the same meaning the priority set by the reporter (how he thinks it should be treated), other developers/bugzilla gnomes (a more accurate view) or your boss (this is how you must consider it).
On Tue, Nov 27, 2012 at 2:57 PM, Platonides Platonides@gmail.com wrote:
Well, I don't think you would need to ban people not in your group from touching those fields. You only need to take into account who said that as well as what they said. Even when having a shared meaning, it doesn't hold the same meaning the priority set by the reporter (how he thinks it should be treated), other developers/bugzilla gnomes (a more accurate view) or your boss (this is how you must consider it).
I agree - and I dont mean to suggest we ban people from touching the priority/severity fields, but rather determine a sound approach as a matter of policy. A part of my concern is setting expectations around temporally based priorities that may not jive with a team's use of bugzilla, and/or setting a precedent for somehow interrupting a team's normal flow. But if I'm the only one who doesn't agree with assigning temporal values to priorities I don't want to bikeshed or otherwise stand in the way of this getting done - we can always revisit it later if it turns out to be problematic/ineffective/etc.
Thanks for all the good and valuable feedback, explaining your workflows, and discussing current flaws & potential improvements in the long run.
For the short term I have now created a priority called "Immediate" which should be used to identify issues that need immediate attention. This means that teams don't have to change their use of "highest".
Please set IMMEDIATE PRIORITY when it is appropriate.
The documentation at http://www.mediawiki.org/wiki/Bugzilla/Fields has been updated accordingly: * Immediate priority: Must be fixed immediately (means: "Drop any other work"). Reports should have an assignee set in the "Assigned to" field. * Highest priority: Should be fixed next by a team. Teams should only have very few issues (preferably one) with highest priority at the same time. Reports should have an assignee set in the "Assigned to" field.
andre
wikitech-l@lists.wikimedia.org