On Nov 27, 2012, at 5:39 PM, Andre Klapper <aklapper(a)wikimedia.org> wrote:
On Mon, 2012-11-26 at 17:36 -0800, James Forrester
wrote:
On 26 November 2012 17:25, Rob Lanphier
<robla(a)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