On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper aklapper@wikimedia.org wrote:
Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
This.
Also....
On Wed, Nov 28, 2012 at 9:56 AM, bawolff bawolff+wn@gmail.com wrote:
An alternative way of looking at priority, is instead of how long it should take to fix - look instead at how long it should take before somebody starts to look into/begin fixing the issue.
I'm comfortable with this as a compromise.
Also, it's worth noting that the most productive use of Bugzilla is going to be for things that take less than a month of dedicated, focused developer time. Any task that's bigger should be broken down into smaller tasks. Using the moon landing metaphor, it's not as though the NASA folks basically went to work every day saying "this is the day we're going to land on the moon", trying and failing every day until July 21, 1969. There were a few interim steps in there, and heck, I'll bet you they even wrote them down somewhere.
Point being: it's fine for something big to be "highest" priority, so long as it's a tracking bug, and there's a smaller subtask somewhere that is also "highest". I would maintain that the subtask is the *only* thing that should have "highest" priority, because saying that the ultimate goal is the "highest" priority, while maybe strictly accurate, is an empty gesture. It doesn't help us organize our work. It's also not even terribly accurate, since the whole "landing on the moon" thing wasn't the highest priority until Apollo 11 got to the moon, and before that got off the ground, and before that...yadda yadda. Yes, it was always helpful to have the ultimate goal in mind, but I'm going to go out on a limb and say that they didn't use an issue tracker for that.
However, I don't care as we take care of this:
On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper aklapper@wikimedia.org wrote:
Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
Rob