How to organize a BugDay

Note

This is a WIP page on how we organize our BugDays. Information is collected and refined here, so more people can take part in planning and conducting such events. When it's done we should have a good checklist as well as some checkpoints (including when to do what).

Choosing a target

First of all you need to pick a good target for the BugDay including whether to triage or krush. Generally you should keep the following in mind:

Make sure you contact the developers of the product you're working on early enough to get their support (2-3 weeks in advance).
Choose an application that's important enough for users so some of them join the effort.

Triage

Parts of KDE that qualify are usually applications with a bug count so high its developers have trouble keeping up. The weekly summary statistic page on our bug tracker can serve as a starting point.

Krush

Krush days are usually suitable for finding plenty of bugs in advance of a release. It's also easier for inexperienced people to take part if beta versions are available via regular distribution channels.

Organizing

Organizing a BugDay should be a joint effort which is coordinated using the BugSquad mailinglist ([email protected]). If you want as many people as possible to help, make sure you post to the mailinglist in time.

Often developers will have special requests (like intervals of bugs or specific components to triage). Take that into account.
Let the developers tell you which version of their software people should use when working on bugs.

Notes.kde.org

Use notes.kde.org to organize your work. Here is an example of template:

https://community.kde.org/Bugsquad/BugDays/example

Notes:

For triage, use a script to generate the batches (put scripts on svn, link here and put documentation somewhere)
Make sure you adapt the page to the BugDay's needs.
Make one or more developers check if they have special hints to add for the BugDay.

Marketing

Marketing should be somewhat coordinated. Be sure to distribute responsibilities in time.

Create an article to be published on dot.kde.org. Make sure you submit it in time (2 weeks before the event!).
Release informal follow-up blog posts on planetkde.org. Denominate the people who do that so there's no confusion.
If possible get the triaged product's developers to blog about the BugDay as well asking their users to help.
In addition you can translate the dot article to other languages and get people to post it on local KDE sites.
Use micro-blogging to create some buzz (identi.ca, twitter).

(what should be in a dot article? to be written) (who to contact to publish the dot article? to be written)

During the BugDay

During a BugDay new users will often join and either say nothing or just greet everyone. Most of the time those users need help but might be hesitant to ask. In the past it has often helped to check for new people joining and start talking to them when they do offering help. Thus at least one experienced member of BugSquad should always have an eye on IRC. It might be a good idea to designate someone to do that.

Apart from that:

If there are new people around, keep an eye on what they do. Make them feel their work is appreciated, but also double-check some of it in order to avoid mistakes (we know we all made them when we started).
Don't be shy to advertise our mailinglist.
Make sure the BugDay is in the IRC channel's topic (as well as a link to the BugDay's community page).
If possible, make some of the application's developers join our IRC channel so they can help with certain bugs. Seeing your own work appreciated motivates.
Be a bit verbose about what you're doing on IRC as to not make the channel seem too deserted. Seeing other people work might be motivating.

Checkpoints

(to be written, should contain a timetable of when you should do what when organizing a BugDay)

Templates

Find the templates for the BugDays here