Confirmed users
1,136
edits
No edit summary |
(→Project/release-cycle: Adding optimal bugflow workflow) |
||
Line 82: | Line 82: | ||
#Are the third-party developers cc:d on all relevant bugs? If possible (i.e. not "mozilla-confidential" flagged), have them follow the Bugzilla component (and make sure they have accounts). | #Are the third-party developers cc:d on all relevant bugs? If possible (i.e. not "mozilla-confidential" flagged), have them follow the Bugzilla component (and make sure they have accounts). | ||
#Has a push bug, and a release checklist, even if you don't think they need it (they do) | #Has a push bug, and a release checklist, even if you don't think they need it (they do) | ||
== Optimal Bugzilla Workflow == | |||
Each project can be different, but please use this flow if starting a new project: | |||
* A bug is filed in the correct product/component | |||
* Bug is triaged for severity, priority and assigned to a target milestone | |||
* Bug is fixed in work based on next target mileston release | |||
* Dev marks bug CLOSED:FIXED | |||
* Tester verifyies bug on stage, bug marked CLOSED:VERIFIED | |||
* Code is deployed to production | |||
* Tester verifies bug | |||
* Tester verifies deployment | |||
Whiteboard may be used for various reasons: | |||
* [good first bug] - Communicates a contributor opportunity | |||
=Site Config= | =Site Config= |