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(a)wikimedia.org>wrote;wrote:
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687