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