On 26 November 2012 17:25, Rob Lanphier <ro...@wikimedia.org> wrote: > 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. > > 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
