Re: [Wikitech-l] Priorities in Bugzilla
On Tue, Nov 27, 2012 at 11:23 PM, Tim Landscheidt t...@tim-landscheidt.de wrote: [...] Not to quote from another video about GitHub (where issues have only title and comment), let's not forget Git: No bug- tracker at all :-). Tim According the http://git-scm.com/community page: Bug reports should be sent to this mailing list. So it seems the Git development mailing list is the bug tracker. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Tue, 2012-11-27 at 22:23 +, Tim Landscheidt wrote: If at the moment the priority field neither necessarily triggers action nor reflects the actual state of affairs, why even bother and not just delete/hide it from view? This would free more time to fix bugs. I don't see how dropping it all together helps planning or how it frees more time. Obviously anybody is free to work on anything but some stuff simply is more important than other stuff. I understand that there are many options and ways to express that importance though, and that severity, priority, target milestones, blocker bugs have some ambiguity to discuss in the long run. Right now I'd like to introduce a clear way to mark issues that should be handled immediately. Not to quote from another video about GitHub (where issues have only title and comment), let's not forget Git: No bug- tracker at all :-). I'm happy if using http://dir.gmane.org/gmane.comp.version-control.git works well for the Git developers and if important issues don't get lost. There are many ways and tools how to do software development, some work well for some, others work well for others, and not every tool is needed by everybody. GitHub itself has a bugtracker (Issues tab) by the way. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Wed, Nov 28, 2012 at 9:32 AM, Andre Klapper aklap...@wikimedia.org wrote: On Tue, 2012-11-27 at 22:23 +, Tim Landscheidt wrote: If at the moment the priority field neither necessarily triggers action nor reflects the actual state of affairs, why even bother and not just delete/hide it from view? This would free more time to fix bugs. I don't see how dropping it all together helps planning or how it frees more time. Obviously anybody is free to work on anything but some stuff simply is more important than other stuff. I understand that there are many options and ways to express that importance though, and that severity, priority, target milestones, blocker bugs have some ambiguity to discuss in the long run. Right now I'd like to introduce a clear way to mark issues that should be handled immediately. I think the priority field is important. And I sometimes use it for finding bugs to fix (or you know, did back when I had more free time and went around fixing random bugs). What I would really like to see is banning users from touching the priority field. The field is made rather useless by bug reporters who feel their pet issue is the most important thing to ever happen - and suddenly there's a whole lot of issues at highest. Of course I would still like to see triaging people setting the field - just not the randoms who think by marking their bug highest priority it will actually be treated like highest priority. Some of the suggestions mentioned earlier for priority meanings seem a bit inflated to me. At most times there's not a huge number of high priority issues (Limited person power = not everything can be fixed instantly) - Thus the field should be more distinguishing on the lower end of the spectrum. I personally think that the following would more reflect reality: lowest = nobody cares. If somebody cares they can fix it, and we won't stop them low = Not very important. Maybe one day if I'm very bored. If this issue never got fixed I wouldn't loose too much sleep Normal = Your average bug (Realizing that your average bug isn't very important). This should get fixed at some point. Doesn't have to be at next release - But if I was browsing Wikipedia 5 years from now I hope I don't encounter the issue High = This was kind of bad. Unless there is some very good reason we cannot, this should be fixed by next release. Preferably in the next month if it is not a large amount of work Highest = This is a major issue. Somebody should be working on this right now. If somebody sets this to high they should either be working on the issue, or working to find someone to fix the issue. 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. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper aklap...@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...@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 aklap...@wikimedia.org wrote: Right now I'd like to introduce a clear way to mark issues that should be handled immediately. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Wed, Nov 28, 2012 at 12:56 PM, bawolff bawolff...@gmail.com wrote: What I would really like to see is banning users from touching the priority field. The field is made rather useless by bug reporters who feel their pet issue is the most important thing to ever happen - and suddenly there's a whole lot of issues at highest. Of course I would still like to see triaging people setting the field - just not the randoms who think by marking their bug highest priority it will actually be treated like highest priority. Although Bugzilla isn't a wiki, it might still be helpful to follow the wiki principle of letting it remain easy to fix people's bad changes (e.g. setting the wrong priority) rather than tying their hands from making those changes. Could we instead draw users' attention to the page listing what all the different priorities mean, e.g. by having Bugzilla ask Are you sure this meets the criteria for a highest priority bug? and then linking to http://www.mediawiki.org/wiki/Bugzilla/Fields#Priority ? -- Nathan Larson 703-399-9376 http://mediawiki.org/wiki/User:Leucosticte ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla [was: Re: Standardizing highest priority]
On 27 November 2012 17:09, Andre Klapper aklap...@wikimedia.org wrote: 2) Look at our priority definitions in https://www.mediawiki.org/wiki/Bugzilla/Fields#Priority a) normal means Should be fixed by the next release.[1] This is extremely unrealistic with above usage of Normal. You may be up against human nature there. How about SERIOUS, VERY SERIOUS, PROFOUNDLY SERIOUS, HIDEOUSLY SERIOUS, OH MY GOD WE'RE ALL GONNA DIE , where the documentation shows that the last one actually means yeah, we should get around to looking at that some time? That would fit human nature as applied to bug reporting ;-) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
Andre Klapper aklap...@wikimedia.org wrote:
[...]
So in a mysterious future not that far away, I'd like to merge Normal
and Low, or Low and Lowest priorities.
Combined with a new Immediate priority as proposed above (quoting
myself), we would keep the same number of priorities, but we'd
communicate way more realistic expectations on fixing issues by moving
the peek from the center to the right, where Low priority lives.
If at the moment the priority field neither necessarily
triggers action nor reflects the actual state of affairs,
why even bother and not just delete/hide it from view? This
would free more time to fix bugs.
[...]
PS:
Bonus material: Which priorities do other Bugzillas use?:
KDE: {VHI, HI, NOR, LO, VLO}
Mozilla: {P1, P2, P3, P4, P5, --}
Mer: {High, Normal, Low, Undecided}
GNOME: {Immediate, Urgent, High, Normal, Low}
FreeDesktop.org: {Highest, High, Medium, Low, Lowest}
Not to quote from another video about GitHub (where issues
have only title and comment), let's not forget Git: No bug-
tracker at all :-).
Tim
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
