The Persona BrowserID Bug Process
Clone this wiki locally
Bugs are prioritized using a star system ranging from one to five stars. Here are the meanings behind the priorities:
- ★★★★★ - An issue affecting a significant number (> 1%) of people that makes browserid unusable and/or puts users at risk - all engineering resources should focus on this issue until it's resolved. These issues block trains and warrant hotfixes. (May be filed against dev, beta, or production)
- ★★★★ - A highly visible defect which is confusing and/or potentially risky for users - or an important new feature.
- ★★★ - A new feature or a defect for which a user discoverable workaround exists.
- ★★ - A defect that is not affecting users or a less important feature, and/or has a very unfavorable cost/benefit ratio.
- ★ - Doesn't affect end users, extremely fringe, a contrived scenario, and/or it's unclear that resolution will have a net positive affect.
Commits and Issues.
- every commit message should reference an issue.
- rule #1 may be broken when the fix takes less time to author and test than the issue would take to open.
Bug Triage Process
How do new bugs filed get assigned a priority?
Triage meetings happen in the Identity vidyo channel on Thursdays from 9:30-10:30am Pacific (see http://mozillapersona.info for Identity calendar and info on joining the conference)
- The triage meeting agenda:
- briefly review high priority (5 stars) issues, raising visibility and adjusting ownership if needed (to give these a better chance of getting addressed during the week)
- discuss and triage all unstarred issues, assigning starrage but not ownership (unless 5-star)
- review issues in maintenance-mode repos:
- verify new bugs in Bugzilla [rawr] and move them to GitHub issues as needed; Bugzilla -> Mozilla Services -> Server: Identity
- question why we have a Bugzilla component if we don't use it for collecting bugs.
- leftover time is spent in the Four Star Hotel, reducing the bug count by reviewing old 4-star bugs and closing where possible.