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
<jforres...@wikimedia.org>wrote:
> On 26 November 2012 10:51, Andre Klapper <aklap...@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.
>
> jforres...@wikimedia.org | @jdforrester
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
