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

Hold a pre-triage meeting
This is not absolutely necessary, but I've found it helpful.

Contact one or two stake holders. These can be active editors or product managers who are concerned with the bugs and will involved the main triage. During this time you can use the Etherpad you've set up to work with the stake holders to weed out non-issues or include things that you might not be aware of.

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. See the 1.18 triage announcement 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).

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.

Followup

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