User:Tibbs/Mass Ticket Filing

From FedoraProject

< User:Tibbs(Difference between revisions)
Jump to: navigation, search
 
Line 2: Line 2:
  
 
* First, just don't.  Opening a pile of tickets is rarely the best way to reach maintainers who are often already overwhelmed by tickets, many of them auto-filed from other things which also shouldn't be opening tickets.
 
* First, just don't.  Opening a pile of tickets is rarely the best way to reach maintainers who are often already overwhelmed by tickets, many of them auto-filed from other things which also shouldn't be opening tickets.
* If you really think you need to do so, first make an announcement on the devel@ mailing list.  Be sure to explain clearly what needs changing.  Include two lists of packages that need fixing, one list indexed by package name and one by maintainer/comaintainer ID.  Posting to the list gives everyone time to discuss the proposed changes in one place instead of fragmenting discussion off in a pile of random tickets, and also gives those with a bit of spare time the chance to go in and help out fixing things instead of having to sit in front of a web browser waiting for bugzilla.
+
* If you really think you need to do so, first make an announcement on the devel-announce@ mailing list.  Be sure to explain clearly what needs changing.  Include two lists of packages that need fixing, one list indexed by package name and one by maintainer/comaintainer ID. (We need a tool to do this automatically.) Posting to the list gives everyone time to discuss the proposed changes in one place instead of fragmenting discussion off in a pile of random tickets, and also gives those with a bit of spare time the chance to go in and help out fixing things instead of having to sit in front of a web browser waiting for bugzilla.
 
* Repeat the announcement after a week, and preferably again a week after that.  Make sure to actually update the lists of packages that need fixing _and_ update the clear explanation of what needs changing based on previous discussion.  If this is so urgent that it can't wait for a few weeks, someone didn't plan ahead.  (Or it's some huge security problem, in which case ignore all policy with claxons blaring.)
 
* Repeat the announcement after a week, and preferably again a week after that.  Make sure to actually update the lists of packages that need fixing _and_ update the clear explanation of what needs changing based on previous discussion.  If this is so urgent that it can't wait for a few weeks, someone didn't plan ahead.  (Or it's some huge security problem, in which case ignore all policy with claxons blaring.)
 
* Now, you should hopefully be down to only a small set of packages which haven't been fixed.  Now you can file tickets.  Be sure to include the clear explanation of what needs fixing in each ticket.
 
* Now, you should hopefully be down to only a small set of packages which haven't been fixed.  Now you can file tickets.  Be sure to include the clear explanation of what needs fixing in each ticket.

Latest revision as of 17:53, 1 November 2012

[edit] Best practises for mass-filing bugzilla tickets

  • First, just don't. Opening a pile of tickets is rarely the best way to reach maintainers who are often already overwhelmed by tickets, many of them auto-filed from other things which also shouldn't be opening tickets.
  • If you really think you need to do so, first make an announcement on the devel-announce@ mailing list. Be sure to explain clearly what needs changing. Include two lists of packages that need fixing, one list indexed by package name and one by maintainer/comaintainer ID. (We need a tool to do this automatically.) Posting to the list gives everyone time to discuss the proposed changes in one place instead of fragmenting discussion off in a pile of random tickets, and also gives those with a bit of spare time the chance to go in and help out fixing things instead of having to sit in front of a web browser waiting for bugzilla.
  • Repeat the announcement after a week, and preferably again a week after that. Make sure to actually update the lists of packages that need fixing _and_ update the clear explanation of what needs changing based on previous discussion. If this is so urgent that it can't wait for a few weeks, someone didn't plan ahead. (Or it's some huge security problem, in which case ignore all policy with claxons blaring.)
  • Now, you should hopefully be down to only a small set of packages which haven't been fixed. Now you can file tickets. Be sure to include the clear explanation of what needs fixing in each ticket.