Bug triage refers to assuring quality of bug reports in Wikimedia Bugzilla. The process of triaging is explained in the Triage guide. The main job of triagers and the Bugsquad is to help users and developers in Bugzilla. Triaging a bug report involves making sure that the bug report
- has enough information for developers and makes sense
- has not already been reported before (checking for duplicates)
- is filed in the correct place (product and component)
- has sensible "Severity" and "Priority" fields
- is versioned correctly
We currently have a bugwrangler who triages bugs and organizes bug triage meetings to collectively prioritize, validate and assign bug reports, and to sometimes recruit developers to fix the bug or implement the enhancement. We announce the meetings ahead of time on wikitech-l and via Google Calendar, Identi.ca and Twitter. Bug triage meetings are held in a public IRC channel, either #wikimedia-dev (webchat link) or #wikimedia-office (webchat link). See MediaWiki on IRC for general information on IRC.
Triages currently take place about once a month, and the next triage will be announced here.
Next meeting[edit | edit source]
What: Collection/Book/PDF/OCG Bug Day to re-triage or re-discuss old reports and new PDF issues against recent Collection and PDF rendering code.
When: On 2014-10-08, 14:00–22:00 UTC (Every Timezone).
Where: IRC, progress is updated at:on
- etherpad:BugTriage-Collection, where 80 lost PediaPress reports are listed: they'll be 0 at the end of the day, with all relevant ones tracked in bugzilla; Mission accomplished
- Collection component, where confirmed reports will be filed or updated;
- old and fresh bugs specific to the PDF format must be filed against OCG.
No technical knowledge needed, no obligations! It's a nice and easy way to get involved in the community or to give something back. See also How to triage.
Step by, say hello, and give it a try! :-)