| || |
| || |
The results of all past bug days can be found [[/BugDays|here]].
The results of all past bug days can be found [[/BugDays|here]].
Revision as of 16:00, 11 October 2010
What is BugSquad?
The KDE BugSquad keeps track of incoming bugs in KDE software, and goes through old bugs. We verify that a bug exists, and is reproducible, and that the reporter has given enough information. When applicable, we write testcases. Our end goal is to help developers notice valid bugs quicker, and to save their time.
You do not need any programming knowledge to be in the Bugsquad, and it is a great way to give practical support to the KDE community. If you are just starting to learn programming, it is a great way to gain familiarity with the components.
We have regular days where we pick a software package and look through all the old Bugzilla bugs to see if they are still valid. Sort of a Bugzilla cleaning day.
The next Bug Day will be 10th October 2010 and it will the first KWin Bug Day: http://techbase.kde.org/Contribute/Bugsquad/BugDays/KWinDay1
How to organize a BugDay
|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.
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.
- 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.
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).
- Use previous BugDay pages as a template.
- 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.
(to be written)
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 acrticle? 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 Techbase 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.
(to be written, should contain a timetable of when you should do what when organizing a BugDay)
Find the templates for the BugDays here
The results of all past bug days can be found here.
Our team has recently launched a new iniciative named "Bug Weeks", as an evolution of the traditional BugDays. All the workflow is based on the KDE Community Forums.
You can find more information about it at its official announcement
The first bugweek was about triaging Plasma Desktop bug reports. You can find more information in the BugWeek Session 0 article. (A summary article is yet to come)
|We don't just do bugs on BugDays! Don't hesitate to join us at #kde-bugs on irc.freenode.net, we have plenty for you to do. ;) Check the topic to see what we are currently working on. And if you are new, please read the "how to triage bugs" page.|
How to help
Read the ultimate guide to BugTriaging for KDE Projects (Recommended)
Read this guide and join us for one of our bug days or bug weeks. We meet on IRC in the #kde-bugs channel on irc.freenode.org. You can easily get started by having your questions answered there, and having someone guide you as to general bug triaging philosophy. Someone in IRC will usually be able to help you. Although we do sleep sometimes!
A summary of the BugSquad guide is provided below to give you a quick idea of how you can help:
- Confirming bugs. Bugs with the UNCONFIRMED status should get the NEW status once someone else is able to reproduce the bug reliably.
- Finding bug duplicates. Many bugs entered into Bugzilla are duplicates of other bugs. Sometimes it's hard to recognize these as duplicates but multiple people checking can make the duplicates bubble to the top of the pile. The following remarks may help you identifying them:
- Using the Similar Bugs link to look if there are duplicates.
- In the case of crashes, use the link below the comment field to look for crash reports with the same backtrace. The backtrace must be in the body of the report in order to look for similar reports. This tool does not look in attachments with backtraces.
- Close bugs which have insufficient information and which have been open for a long time (e.g. reporter does not respond to a need-more-info request). Usually a timeout of one month or more is considered to be an "information timeout".
- Categorize bugs into the right components. Many bug reports can be further categorized into components. For example, Konqueror reports can be assigned to KHTML and kfm components.
- Labeling bugs which contain testcases as such in the title. Ideally, testcases contain the minimal amount of code (HTML, scripts, C++ etc.) necessary to reproduce a bug.
- Writing testcases. Very useful and saves developers' time.
The sheer number of open bugs can be overwhelming at the start. Here are some hints on getting started more smoothly:
- Look at a single product at a time. For large applications (like Konqueror), you may want to further limit your search to a particular component.
- Don't try to find duplicates early on. Finding duplicates is hard until you have become familiar with the bugs in a component. Start out with verifying UNCONFIRMED bugs as described above. That's valuable work, and a great way to familiarize yourself with the bug database.
- Avoid very old bugs with many comments, and also bugs with many votes. This may seem counter-intuitive, but in most cases these bugs are hard, have gotten a lot of attention, and are probably on a developer's TODO list already. If it is from an older version of KDE, and there are no recent comments, verify them, make a notation, and move on.
- Don't be afraid to ask the reporter for more info. It's something you can even do without Bugzilla permissions. And reporters will generally prefer being asked one question too many, instead of their report never being dealt with. Just remember to be polite. Ask yourself how you would feel if you got the message you are thinking about sending to a user.
- Look at the incoming Bugzilla bugs. Or find the oldest bugs for your favorite software application.
- Look through the rest of our documentation for more information!
- Quick introduction to Bugzilla - This article explains the basics about the bugtracking software that KDE uses: "Bugzilla". It includes the description of a bug reports fields and the workflow of most common tasks like searching into the databse.
- A Bug's Life Cycle - This article describes the possible status of a bug report and when each should be used.
- How to triage bugs - This article gives step-by-step what you do during a BugDay, or how to start triaging on your own in our "ongoing triage" (usually for old Konqueror bugs; see #kde-bugs for the current link).
- Preparing a testing environment - This article from the BugWeeks initiative describes how to properly configure and setup a KDE SC environment in order to test the bugs.