Bug management/Meeting preparations

This is an overview of the process involved in holding a public bug triage. Typically, these happen on IRC.

Choose a topic
A bug triage needs a theme. From your perusal of the incoming bugs and your own interest, you may have a good idea of what would make a good topic for a public discussion for current issues.

You should be familiar with the product managers and directors current focus. This way you will know what the various teams inside Wikimedia are working on. Some teams will want to do regular triages. The i18n team wants to hold a triage every second Wednesday.

Another good target are products or features that have recently been rolled out. Now that we're working with rolling releases, a more general triage should be held on a semi-regular basis.

Produce a list of bugs
If you're familiar with the bug database and have some grasp of the topic, then this should not be too hard. Spending time “in the community” (usually, by perusing discussion and announcement venues) will help you understand those bugs that need discussion.

Etherpad setup
Start a new etherpad. I've used etherpad names such as BugTriage-YYYY-MM in the past to group all the triages held in a month onto a single Etherpad and putting the newest information at the top of the pad.

Because of the way Etherpad works, it is useful to put a single bug on a bulleted line that begins with the bug's url and, on the next line, begin an empty bullet with one further indention for making notes about the bug. This provides a natural way of working around the bugs. For example, after your triage, this way of setting up an etherpad will make it easy to read and report on.

* blocks on #34139
 * http://bugzilla.wikimedia.org/34138: Stage source tree on fenari with git instead of svn

* HIGHEST
 * http://bugzilla.wikimedia.org/35140: Create submodules for WMF deployment branch
 * http://bugzilla.wikimedia.org/34141: Integrate Jenkins with Git

Contact stakeholders
Contact one or two stake holders, e.g. by checking recent commits in Gerrit or checking the default CC list of the Bugzilla component to triage. These can be active editors or product managers who are concerned with the bugs and will be involved. They should agree on the time for the triage and be available on IRC.

Pick a time and Announce
Triages are probably best held on Wednesday or earlier if you expect the people involved are full time MediaWiki developers. If you're triage is aimed at people who are doing this in their off time, then later in the week is probably a better choice.

Remember, though, to keep your audience in mind. For example if you are doing a triage that covers Indic languages, then you're probably going to want to schedule at a time that is more convenient for people in UTC +5:30 which is generally not going to be convenient for people on in San Francisco because of their 11-12 hour time difference.


 * Wiki: Make sure it's added to Project:Calendar so it will be listed on Weekly QA Goals. Also, be sure to update the wiki for people who watch that page. If the triaging is a physical meeting, also consider adding it to Events.
 * Mailing lists: Make an announcement on wikitech-l so that anyone can attend and provide a link to a timezone converter in your announcement. If the triage has a main topic (e.g. an extension), remember to mention it in the summary to attract people interested in it which would otherwise not read. See the bug day email template for an example.
 * Web Calendar: Some people use the Triage calendar to keep up. Be sure the event is added (Andre has write access to "Bug Triages" in Google Calendar, for example).
 * Consider announcing via microblogging services (Identi.ca, Twitter).

Send a reminder on wikitech-l about 10 minutes before the event starts, and if it's IRC based also advertise it in #mediawiki, #wikimedia-tech, #wikimedia and perhaps #wikipedia

Finally …
Hold the triage.

Be verbose on the IRC channel (explain what you're doing in the bugtracker and why, communicate your thoughts and actions) and be welcoming to people.

Followup

 * Clean up Bug management/Triage
 * Think about what went well and what could be improved
 * Tell the world what you achieved!