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