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