Talk:The Ideal Bugtracker

From Audacity Wiki
Jump to: navigation, search

Classify by what's needed now

Gale: 30 Aug 09: James wrote "Classify by what's needed now: Work via a family of related lists, one for each kind of action needed. Separate feature requests and design decisions involving multiple people from patches that are reviewed agreed and ready to apply. Have short lists of urgent issues and long lists of feature requests rather than mixing all kinds of issues in one list."

Well, as you know I think "Feature Requests" (where supported by developers) should be part of the main list. History shows they'll never be dealt with otherwise. Isn't P1/2 "classify by what's needed now"? Is the answer to call the "requests" F3, 4, 5 on the main list? You could have a separate "Developer Supported Requests page" (main contents of which is currently "Release Checklist Not Aiming") but how do you rate them? Is an F1 = P3?

Clearly if I had time to fill Checklist with all the bugs there really are (most P3 and below) then we would have a worse scanning problem than we have now. A separate list for P3 - P5 means those will then be ignored, so I'm beginning to think the only answer is not to comment on the bugs or even give steps to reproduce. Put it all on -devel and that thread becomes like the Bugzilla page for that bug. That of course depends wholly on list archiving working, which is currently under SF control.


Rights to Edit

  • Gale 22 Apr 09 This (anyone can edit) does not seem to accord with the "Audacity Devel" template that you put on the Release Checklist, so it depends who you mean by "anyone". I don't think anyone other than devel list subscribers should be re-prioritising bugs, and I even question if any other registered Wiki users should be editing the list. All it means is a garbage clean-up job, as per Bugzilla. It's fine if we want to formalise using the discussion tab to add comments, and fine if someone wants to say "hey that bug does not occur on OS X".
  • James Indeed, I'm not being consistent. The distinction I guess I am making is that Bugzilla enforces the special powers. Our wiki does not prevent random people re-prioritising. We just ask that they do not! Giving someone inexperienced free reign in Bugzilla it is a royal pain to clean up after them. In our wiki tracker, it is one revert. I'm not proposing we change our 'rules' anytime soon. Rather I am trying to come up with something that is better than a normal bugtracker without being quite as free-form as wiki. I'm certainly keen on the release notes idea. Being able with minimal work to get an up-to-date preview of what our release notes would look like would be very good.
  • Gale 24 Apr 09: Thanks. To prevent random people modifying the Checklist, everyone who wants to edit it has to have sysop privileges? Did you see my comments on the "Checklist not aiming" discussion?
  • James Oh! I had thought anyone could edit the page! I got that wrong then. Hadn't seen that discussion and am responding now...
  • Gale 26 Apr 09: Yes at the moment anyone can edit the page, though we ask only devel-list subscribers to do so. Protecting it so that only sysops can edit it (and thus giving everyone we deem serious devel-list contributors sysop status) is a way to prevent random spurious edits. But in practice I can only recall one bad and one good edit by people outside devel list.


Formal user-level bug input

  • Gale 26 Apr 09: I think having forms for user bug reports is good (as long as those forms are not the active bug list). Think how much better bug reports might be if users had to fill in their OS, version of Audacity, steps to reproduce etc. on a web form. It might also have some deterrent effect which might be both bad and good.


Release Notes Autogeneration

  • Gale 24 Apr 09: I'm not clear at the moment how Release Notes will be autogenerated other than with Bugzilla Reports which seems to mean actually going back down the Bugzilla road? I'm not keen on Bugzilla but the Wiki just is not automated enough if we had many hundreds of listed bugs (+ activity tracking / Feature Requests, which I am unconvinced should be on (the same) tracker). I think ultimately what may be needed is actually some kind of custom Wiki "extension" or functionality written by us?
  • James I'm not keen on bugzilla either (or the other alternatives). Custom wiki extension looks right. What I'm trying to do is to (a) make the effort more worthwhile by the idea being a general enhancement to wiki that can make tables from multiple pages (b) make it less work for us, e.g. by having Melange do it.