Difference between revisions of "Talk:Using Bugzilla"

From Audacity Wiki
Jump to: navigation, search
(Handling rules.)
(reply to James)
Line 25: Line 25:
 
* If you keep the headlines here, I suggest they should be in a div at the top so they don't get lost.
 
* If you keep the headlines here, I suggest they should be in a div at the top so they don't get lost.
 
** @Gale, I've put a link from [[Bug Lists]] to here, which should be enough.  I am trying to avoid instuctionitis - at least on this page.  It sounds like you're feeling a need for something more formal.  If you are, how about starting 'Bugzilla Workflow' or 'Bugzilla Rules', even with just the headline rules, and we can link to it from both these pages?  It could be good to cater to both people who need clarity about ''what'' to do, and people who need to have a sense of ''why'' we do things the way we do.  This is all experimental.  I simply don't know what is going to work best.  I do know I want the Audacity group to be fun to work in and productive. -- [[User:James|James]] 09:33, 20 April 2011 (UTC)
 
** @Gale, I've put a link from [[Bug Lists]] to here, which should be enough.  I am trying to avoid instuctionitis - at least on this page.  It sounds like you're feeling a need for something more formal.  If you are, how about starting 'Bugzilla Workflow' or 'Bugzilla Rules', even with just the headline rules, and we can link to it from both these pages?  It could be good to cater to both people who need clarity about ''what'' to do, and people who need to have a sense of ''why'' we do things the way we do.  This is all experimental.  I simply don't know what is going to work best.  I do know I want the Audacity group to be fun to work in and productive. -- [[User:James|James]] 09:33, 20 April 2011 (UTC)
 +
*** '''Gale:''' I don't think we have so many rules/guidelines (or should have) that we need three pages. I have two points. First, the article is called "Using Bugzilla", but really it's a mix of some guidelines interspersed with a (mostly deserved) diatribe against commercial bug trackers and bug tracking. I think the article is a bit jumbled as it is now and could do with the "headlines" suggested keeping together. The meaning of Moonphase and Heisenbug is quite important too, but it's rather a long way down, and confusingly suggests an importance "Comet Returns" that we don't have. I'm fine with keeping all the current material here, but suggest some "Quick Points" or restructuring may help. Vaughan's idea of linking to [[Bug_Lists#Bugs by Priority]] seems good too.<p> We seem to have had a significant outbreak of instructionitis with release processes, so there seems some demand for it. It's a balance, with I guess more need for it with releases than in bugtracking. However some bugzilla users will definitely want a bit more instruction on what to post on bugzilla and what not, as well as how to do it. The fact this isn't clear enough to everyone has created its own "toxicity" recently. I think bugzilla posting of compiling issues and policy issues needs to be covered somewhere, and probably here is best.</p>

Revision as of 20:19, 20 April 2011

Peter 19Apr11: ROFLMAO James you have brightened my morning up. But a lot of serious points in there.

We should also have "Schroedinger's cat" bugs where you are not sure what the outcome will be - and observing the outcome changes it anyway...


Vaughan 19Apr11:

Excellent, James. Except I'm non-union so don't get a hazmat suit.

Actually, my only comment is that yes, it doesn't need to define the Pn ratings but would be good to link to the definitions; and maybe from there to the definitions of Moonphase, Heisenbug and Comet Returns.


Gale 20Apr11:

James, I'm unsure if this page is meant to be linked to Bug Lists (which "Using Audacity Bugzilla" on bugzilla links to), or to replace Bug Lists? I assume it's extra documentation for Bug Lists, including a warning about bug tracker "toxicity".

If it's additional to bug lists, maybe its headlines as follows would bear repetition on Bug Lists?

  • including the symptoms in the bug title (and keeping that title updated)
  • move discussions about solutions to Wiki, move anyway if 30 + (?) posts (or my suggestion, use the top of "Steps to repro" if a few lines will suffice)
  • (from -quality) post about code errors and warnings to -devel in the first instance (but disregard lib-src warnings)
  • If you keep the headlines here, I suggest they should be in a div at the top so they don't get lost.
    • @Gale, I've put a link from Bug Lists to here, which should be enough. I am trying to avoid instuctionitis - at least on this page. It sounds like you're feeling a need for something more formal. If you are, how about starting 'Bugzilla Workflow' or 'Bugzilla Rules', even with just the headline rules, and we can link to it from both these pages? It could be good to cater to both people who need clarity about what to do, and people who need to have a sense of why we do things the way we do. This is all experimental. I simply don't know what is going to work best. I do know I want the Audacity group to be fun to work in and productive. -- James 09:33, 20 April 2011 (UTC)
      • Gale: I don't think we have so many rules/guidelines (or should have) that we need three pages. I have two points. First, the article is called "Using Bugzilla", but really it's a mix of some guidelines interspersed with a (mostly deserved) diatribe against commercial bug trackers and bug tracking. I think the article is a bit jumbled as it is now and could do with the "headlines" suggested keeping together. The meaning of Moonphase and Heisenbug is quite important too, but it's rather a long way down, and confusingly suggests an importance "Comet Returns" that we don't have. I'm fine with keeping all the current material here, but suggest some "Quick Points" or restructuring may help. Vaughan's idea of linking to Bug_Lists#Bugs by Priority seems good too.

        We seem to have had a significant outbreak of instructionitis with release processes, so there seems some demand for it. It's a balance, with I guess more need for it with releases than in bugtracking. However some bugzilla users will definitely want a bit more instruction on what to post on bugzilla and what not, as well as how to do it. The fact this isn't clear enough to everyone has created its own "toxicity" recently. I think bugzilla posting of compiling issues and policy issues needs to be covered somewhere, and probably here is best.