Wikimedia Blog/Drafts/Bug Days

How to create a good first Bug Report

A software bug is an error or flaw in a program that produces incorrect or unintended results. Developers work hard to produce software that looks and works as intended, but bugs are as inevitable as death and taxes. The Wikimedia Foundation uses the bug tracker Bugzilla as the system for users to report bugs they encounter while using MediaWiki and Wikimedia sites.

Can you make it happen again?

So, you think you've run into a bug and want to report it to Wikimedia's bug tracker. The first thing to do is to try to reproduce the bug with concrete steps. These steps help developers reproduce the bug, which allows them to investigate the source of the issue. If the bug does not appear consistently, you can still file it, and developers will likely ask you questions to gather more information about the bug.

Life Cycle of a Bug Report

Has it already been reported?

Once you have attempted to replicate the bug, you can log in or register with Bugzilla. As your registered email address will be visible to other logged in users, consider creating a free email account to register with Bugzilla. Bugzilla notifies you of changes to your bug report through email. Before you file a bug report, it would be helpful to see if a report is already filed about the bug you found. This reduces the chances of people duplicating work on the same issue. When you file a bug, Bugzilla checks for duplicates, but you can also spend time independently searching.

If you find a similar report, see if you can add more information than what was originally reported. For example, the original report may be from an older version of MediaWiki, so it would be helpful for you to add a comment that the bug still appears, and to list the newer version, if you can. Maybe the original version does not have steps to reproduce; in that case, add a comment that your listed steps can reproduce the bug. If you do not find a duplicate report, you can go on to filing a new bug. You may end up unintentionally filing a duplicate report, and that's ok. It's better to report a second time than not at all.

Where does it belong?

When filing a bug report, the first thing you're asked to do is choose a product to file the bug in. These products represent software projects, and it can be tricky to choose the right one. You have to consider what sort of error you have. Does the error seem to be with the MediaWiki software itself? The error could be in a MediaWiki extension.

Once you select a product, you're brought to the page where you enter information about the bug. Here you can go through the components associated with the product you chose and read their descriptions. If the bug doesn't seem to fit into any of those components, go back and select another product and look through those components. If you're still not sure or you're in a hurry, file the bug in the MediaWiki product and the General/Unknown component (MediaWiki > General/Unknown).

If the problem doesn't seem to be with the MediaWiki software but with the configuration of a Wikimedia site, you should file the bug in Wikimedia > General/Unknown. Filing a bug in the right product and component helps developers address the bug sooner, because developers working on that specific component usually monitor incoming bug reports. However, bug triagers will move misplaced reports to the right product and component, so do not worry.

What does it say?

Now you should write a summary of the bug you found. Be specific in writing your summary. Vague, generic summaries like "Does not work" or "Feature request" are not helpful to get a quick idea what your report is about. Your summary is what developers, bug triagers, and other reporters will see when they are looking through bug lists in a component or that have been returned as search results.

As stated above, when you fill in a summary, Bugzilla lists possible duplicates. If you see a similar report, follow the steps above and comment if you have some new information to provide. If you don't see a duplicate at this point then you can continue on and fill in a description. The description is where you can elaborate on the problem described in the summary. Here you list your steps to reproduce, what you expect to happen, and then what actually happens. You can also list other details like what browser you're using if it seems like it is relevant to the report. Clicking the Add an Attachment button below the description will allow you to attach a file, e.g. a screenshot, to help enhance the quality of the report. Once you feel you have described the problem sufficiently, you can click Submit Bug.

You're done!

Alright! You filed your bug! It may not be perfect, but that's no problem. There is always somebody to help and improve them. You can look forward to receiving bug mail to keep you up to date on changes, which includes status changes and comments, with your report. Check your user preferences in Bugzilla to view and update what changes trigger an email. You may get comments requesting more information to help diagnose the issue. If you want to see an example of a developer fixing a bug, check out this video of a bug getting fixed.

Valerie Juarez, Bug Management Intern

Help Wikimedia squash software bugs

Wikimedia's Bug Squad has started hosting bi-monthly Bug Days as a part of our QA weekly goals. During a bug day, bug triagers and developers sort bug reports, usually from a specific component or reports fitting a specific criteria. Triaging reports includes testing reports to confirm they are valid, prioritizing reports so developers can efficiently address pressing issues, and identifying and marking duplicate reports to avoid duplicated work. Our next Bug Day on March 19th will work on bug reports in Mediawiki extension > LiquidThreads. For more information on the event and how to participate, check out the event page.

Help us squash bugs!

We have already held three Bug Days. The first Bug Day on January 29, 2013 focused on reports that had not been changed for over a year. We retested many reports to see if they were still valid for newer versions of MediaWiki and MediaWiki Extensions. We also requested more information from reporters whose reports needed clarification. We addressed 30 reports out of about 170. Because of the recent Gerrit upgrade, our bug day on February 19, 2013 addressed bug reports in the Git/Gerrit component. Our focus was addressing upstream issues in Gerrit that may have been fixed with the update. For upstream bugs that were not fixed with the update, status reports were left on our corresponding Bugzilla reports. We addressed about 24 bug reports out of 70 open reports in Git/Gerrit. Our latest bug day focused on General/Unknown reports in the MediaWiki product, which is known to be catch-all for bug reports. 38 reports were triaged. Many were retested and confirmed, prioritized, and moved out of General/Unknown into their proper components.

You can contribute to the Wikimedia Foundation by triaging bug reports. Follow the Calendar of QA events, to keep up with upcoming Bug Days and other testing events. You can also find an announcement of upcoming Bug Days on Bug Management's Triage page. Bug Days are not just for bug triagers; developers are welcome to join and help by 'taking' reports and submitting bug fixes. Fixing bugs is a great way for new volunteer developers to get started, and joining a Bug Day would be a great way to find a few bugs to fix.

Bug Days support the Wikimedia Foundation by ensuring the quality of bug reports and bringing focus to reports that may not have had attention in a while. It is difficult for developers to keep up with the number of bug reports that reside and move into Bugzilla every day. Bug Days and bug triaging can help developers efficiently address these issues.

Valerie Juarez, Bug Management Intern

Notes

For the first post, I didn't link to example bug reports. Would the post benefit if I did that? Andre linked me to many and I can search for them, so it's not an issue of finding them. I just didn't want to put too many links.