From Fedora Project Wiki
No edit summary |
No edit summary |
||
| 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
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.