Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Posts Tagged ‘Bugzilla’

Buggin’ out! How the Wikimedia Foundation triages and fixes software bugs

Finding software problems

As part of the Wikimedia Foundation’s mandate to operate the Wikimedia sites, a small technical team is responsible for maintaining the MediaWiki core platform, along with its features and extensions. The developers who maintain key software in the stack, improving and enhancing the functionality of MediaWiki, include people outside and inside the Wikimedia Foundation, working side by side — and similarly, volunteers and staff work together to detect and diagnose problems to fix. Unusual among many of its tech peers, the engineering team at the Wikimedia Foundation is helped in this process by a contingent of dedicated volunteers who aid in finding, reporting and fixing unintended software problems, or bugs.

Bugzilla is the website where any user or developer can report a software bug or, if they have an idea, request a feature enhancement be made to MediaWiki. Users of Bugzilla can also search current reports to add new comments or information and search for previous reports about a similar bug.

Andre Klapper, Bug Wrangler

The first step in resolving bugs is getting each Bugzilla report to the developer who handles that area of software code. Wikimedia’s Bug Wrangler, Andre Klapper, takes a look at each bug report to figure out the correct product, such as MediaWiki or MediaWiki extensions, and the related subcomponent that each bug falls into. As Bug Wrangler, it’s also his job to make sure each report has enough information for the developers to fix the bug.

“I’m responsible for triaging, and there are some great community members who help me with that,” said Klapper. “When I see problems that are urgent or really critical, I escalate by making developers explicitly aware of such problems. I also try to keep an eye on the many forums (such as Village Pumps) and places where users report problems, and make sure that software bugs end up as a report in Bugzilla, so developers can find them.”

In describing the open platform used by the Wikimedia Foundation, Klapper added, “Basically anybody can define or correct the priority of bug reports and feature requests. Often it’s members of development teams or other volunteers who triage, or I set priorities in order to help developers see what’s the most important stuff to work on.”

Klapper, who joined the Wikimedia Foundation in 2012, estimates that 70 percent of bugs are reported by Foundation staff and developers, 30 percent by users. The role of Bug Wrangler was a natural fit for him because the “position described pretty well what I’ve worked on before” at GNOME and the now defunct Maemo/MeeGo.

Bugzilla has taken its share of knocks from critics, said Klapper (who counts himself among them), because it requires a separate registration, the user interface is complex and it lacks dashboards. He said the developers at bugzilla.org are working on these issues for the next Bugzilla version, and in the meantime, he has started a weekly blog entry called “Bugzilla Tips,” where he gives advice for using the tool.

“I try to make Bugzilla work better for everybody and, hence, ask teams what they are missing, or try to help establish good workflows,” he said. “For example, I introduced a new Bugzilla front page on bugzilla.wikimedia.org recently that provides quicker access to the main tasks.”

(more…)

Help Wikimedia squash software bugs

Help us squash bugs!

Help us squash bugs!

Reporting a new software bug is only the first step towards fixing the issue; the sorting and prioritization steps come next, usually referred to as “triage”.

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 is today (March 19th), and we’ll work on bug reports in Mediawiki extension > LiquidThreads. For more information on the event and how to participate, check out the event page.

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

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.

Has it already been reported?

Life cycle of a software bug

Life cycle of a software bug

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

Wikimedia Bugzilla upgraded to version 3.4.5 with REST APIs

Bugzilla Buggie

This morning we upgraded the Wikimedia Bug Tracker to Bugzilla version 3.4.5. The release notes are available here.

For those of you who have been eagerly awaiting the REST APIs, wait no more. You can now find our Bugzilla server’s APIs at https://bugzilla.wikimedia.org/bzapi. Documentation about the APIs is available at https://wiki.mozilla.org/Bugzilla:REST_API.

If you find any issues with the bugzilla instance or the APIs, submit a bug. Make sure you set the Component to Bugzilla so that it gets my attention.

Bugzilla upgrade.

Thanks to Priyanka’s wonderful work in theming Bugzilla and ironing out the last couple bugs and extensions, we are finally ready to move on with the upgrade.Bugzilla_Logo As a side effect, Bugzilla will be down for a couple of hours (let’s say 2 to be on the safe side) around lunch-time.  (Edit Addition: 2010-01-19 between 20:00 GMT and 22:00 GMT)