Re: [Wikitech-l] Standardizing highest priority in Bugzilla: "IMMEDIATE" priority added

[Andre Klapper]

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
-- 
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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Andre Klapper]

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
-- 
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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Krinkle]

On Nov 27, 2012, at 5:39 PM, Andre Klapper  wrote:

> On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote:
>> On 26 November 2012 17:25, Rob Lanphier  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





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Arthur Richards]

On Tue, Nov 27, 2012 at 2:57 PM, Platonides  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.

-- 
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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Platonides]

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).


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Antoine Musso]

Le 27/11/12 17:49, David Gerard a écrit :
> On 27 November 2012 16:39, 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. 
> 
> 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 :-)


-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Arthur Richards]

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 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@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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Isarra Yos]

On 27/11/2012 09:55, Andre Klapper wrote:

On Tue, 2012-11-27 at 16:49 +, 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.


--
-— Isarra


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Andre Klapper]

On Tue, 2012-11-27 at 16:49 +, 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
-- 
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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Andre Klapper]

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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[David Gerard]

On 27 November 2012 16:39, 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.


Has anyone suggested a separate "urgency" parameter?


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Andre Klapper]

On Mon, 2012-11-26 at 17:36 -0800, James Forrester wrote:
> On 26 November 2012 17:25, Rob Lanphier  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
-- 
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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Krinkle]

On Nov 27, 2012, at 2:36 AM, James Forrester  wrote:

> On 26 November 2012 17:25, Rob Lanphier  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  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




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[James Forrester]

On 26 November 2012 17:25, Rob Lanphier  wrote:
> On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards
>  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.

jforres...@wikimedia.org | @jdforrester

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Rob Lanphier]

On Mon, Nov 26, 2012 at 1:54 PM, Arthur Richards
 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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Arthur Richards]

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
wrote:

> On 26 November 2012 10:51, Andre Klapper  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.wik

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[James Forrester]

On 26 November 2012 10:51, Andre Klapper  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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Andre Klapper]

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
-- 
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

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Rob Lanphier]

On Mon, Nov 19, 2012 at 7:54 PM, MZMcBride  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[MZMcBride]

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
>  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=history

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



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Standardizing highest priority in Bugzilla

[Mark A. Hershberger]

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
 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.

-- 
http://hexmode.com/

Any time you have "one overriding idea", and push your idea as a
superior ideology, you're going to be wrong. ... The fact is,
reality is complicated -- Linus Torvalds 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l