|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).|
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:
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 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.
(Could be done at the beginning of the beta phase, with the new features in green published by the developers at, by example, http://techbase.kde.org/Schedules/KDE4/4.6_Feature_Plan)
Organizing a BugDay should be a joint effort which is coordinated using the BugSquad mailinglist (firstname.lastname@example.org). If you want as many people as possible to help, make sure you post to the mailinglist in time.
Currently we use pages on Techbase to give verbose information about a BugDay and distribute work. A template URL for such a page is:
Just replace Product with the application (eg. KWin) and X with the number of the BugDay (ie. 1 for the 1st BugDay for this application).
(to be written)
Marketing should be somewhat coordinated. Be sure to distribute responsibilities in time.
(what should be in a dot article? to be written) (who to contact to publish the dot acrticle? to be written)
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:
(to be written, should contain a timetable of when you should do what when organizing a BugDay)