Bug management/Meeting preparations
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
This is an overview of the process involved in holding a public bug triage. Typically, these happen on IRC (#wikimedia-dev connect).
Choose a topic
[edit]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.
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
[edit]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
[edit]Go to the generic bugtriage etherpad and empty it.
It can be helpful to have a list of bugs for starters prepared and available in that Etherpad instance, so newbies are not overwhelmed by the choice of available bug reports to triage.
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.
* https://phabricator.wikimedia.org/T36138: Stage source tree on fenari with git instead of svn * blocks on #36139 * https://phabricator.wikimedia.org/T37140: Create submodules for WMF deployment branch * https://phabricator.wikimedia.org/T36141: Integrate Jenkins with Git * HIGHEST
Contact stakeholders
[edit]Contact a number of stake holders. 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.
You can find stake holders by searching for keywords for the component among the recent commits in Gerrit, looking at the project members in the corresponding Phabricator project(s) to triage, the (not always up-to-date) list of maintainers, or the Wikimedia custom search on Google.
Pick a time, announce, remind
[edit]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 in California because of their 11-12 hour time difference.
- Wiki: Make sure it's listed as next meeting and that it's added to Project:Calendar so it will be listed on the main page. 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.
- If you use the IRC channel #wikimedia-office, reserve the room.
- 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 max. one day before the event starts, and if it's IRC based also advertise in #mediawiki, #wikimedia-tech, #wikimedia and perhaps #wikipedia.
Finally …
[edit]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
[edit]- Clean up mw:Bug management/Triage#Next meeting
- Copy content (results) from Etherpad to specific bugday page
- Summarize attendees and achievements on specific bugday page
- Link specific bugday page from mw:Bug_management/Triage/Past_meetings
- Think about what went well and what could be improved
- Tell the world what you achieved!