Archive for the ‘wikimedia’ Category

Bugzilla Tips (IV): Searching for empty fields

Friday, July 5th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

Sometimes you want to search for a specific field being empty, e.g. bug reports without anybody on the CC list.
If you go to Bugzilla’s advanced search and scroll down to the “Custom Search” (called “Boolean Search” in older Bugzilla versions), you can use “matches regular expression” and respectively “does not match regular expression”. Regular expressions (regexes) are powerful patterns to match a certain string (the corresponding Wikipedia article provides more information).

To find all bug reports that have no keywords, enter this:

Keywords | matches regular expression | ^$

^$ is the regular expression for an empty string.

As written before, regexes are very powerful. For example, you could also search for comments in Bugzilla that contain inline Git-formatted patches by using Comment | matches regular expression | —[[:space:]].+[[:space:]]\+\+\+[[:space:]].+[[:space:]]@@[[:space:]].+@@[[:space:]]

Comment | matches regular expression | ---[[:space:]].+[[:space:]]\+\+\+[[:space:]].+[[:space:]]@@[[:space:]].+@@[[:space:]]

As can be seen, the MySQL database requires using [[:space:]] instead of \s for a whitespace character, see its documentation.

Bugzilla Tips (III): Getting copies of another user’s bugmail

Friday, June 28th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

Sometimes you are interested in the stuff that a certain person is doing in Bugzilla. Bugzilla allows receiving the bugmail that a certain other user would also receive⁑. This is called “User Watching”. To enable it, go to your preferences (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):


Click “Email Preferences”:


Scroll to the bottom where the “User Watching” section is. Add the user whose bugmail you would like to receive (and of course this field supports autocompletion.)


After submitting your changes, the user that you watch will be listed, and you will receive her/his bugmail⁑.


⁑Note: You will only receive bugmail for bug reports that you have permissions to access. So watching a user who has access to restricted security bug reports will not make you receive bugmail for these security bugs.

Bugzilla Tips (II): Changing the columns in search results

Friday, June 21st, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

Sometimes you run a search in Bugzilla and you would like to see specific metadata displayed for the resulting list of bug reports, e.g. the Assignees, when the Latest Change took place for each report, or how many votes each report has received (if Voting is enabled in your Bugzilla). At the bottom of your search results, click “Change Columns”:


In the following dialog, the displayed columns are in the list on the right, and the available columns are on the left. You can add and remove columns or changing the order of the columns by selecting a list item and using the arrow buttons:


After clicking the “Change Columns” button, the changes will be applied to the previous search results (and future search results).

Bugzilla Tips (I): Autocompletion

Friday, June 14th, 2013

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

People can be impatient, so not everybody is aware that Bugzilla provides autocompletion for those fields that are about people (like the CC, assignee, and QA contact fields).
The autocompletion kicks in only after waiting a short moment but is extremely helpful in order to set the correct person in a Bugzilla field, or to even check if the person has an account in Bugzilla.


If you want to add somebody to the CC field for example, you first click on “edit”:


If you now start typing three letters of a name or an email address, Bugzilla will show a list of proposals that match the letters you have entered:


After you have selected the person that you have in mind, the person is added to the CC field of the report.

Understanding Bugzilla groups and admin rights

Tuesday, May 28th, 2013

As part of my work for the Wikimedia Foundation I recently tried to understand Bugzilla groups a bit better, specifically which tasks can only be done by Bugzilla administrators. In general, permissions to do stuff in Bugzilla (e.g. editing keywords, components, etc.) are defined by groups in Bugzilla, and Bugzilla users get membership in certain groups, manually or automatically.

Bugzilla logo by Dave Shea

Bugzilla logo by
Dave Shea

Membership in the Bugzilla admin group is always required for the following general tasks:

  • viewing the generated SQL query by using the &debug=1 URL parameter
  • deleting attachments (instead of just marking them as private)
  • editing Bugzilla field values (editvalues.cgi) and editing custom fields (editfields.cgi)
  • editing the bug status workflow (editworkflow.cgi)
  • editing (or banning/blocking) Bugzilla accounts, e.g. in case of violations against the Code of Conduct of your project. This is inherited from the editusers group membership: editusers group membership de facto means admin group membership, as an account with editusers group membership can edit his/her account and set admin group membership.

The list above is not necessarily complete. (Thanks to Byran Jones for input.)

Then there are tasks that might require membership in the Bugzilla admin group, depending on the configuration of your Bugzilla instance:

  • Marking comments and attachments as private and accessing comments and attachments marked as private requires membership in the insidergroup. Manual membership of individuals is not possible, the group can only be set to be another existing group. The insidergroup group might be set to the admin group in your configuration.
  • Inherited group membership: Bugzilla allows defining automatic group membership in group X if an account is member of the group Y or if the account’s email address matches a specific regex defined for a group. The default automatic group membership inclusions of the admin group are tweakparams, editusers, creategroups, editcomponents, editkeywords. It is worth to check your configuration if certain groups automatically inherit membership for either the admin or the editusers group.
  • Creating charts requires membership in the chartgroup (chart.cgi). Manual membership of individuals is not possible, the group can only be set to be another existing group. It is by default set to the admin group in Bugzilla.

I hope this is helpful for other Bugzilla admins out there, as I could not find much documentation. One day I might turn this into a patch for Bugzilla upstream documentation.

Wikimedia Bug Management and the Outreach Program for Women

Sunday, March 31st, 2013

For the last three months I had the pleasure to have an intern for my bugmaster job at Wikimedia, as part of the Outreach Program for Women (OPW) for Free and Open Source Software. It is organized by GNOME and the Wikimedia Foundation participated with six positions.


Valerie’s proposal was to create a proposal for a better feedback workflow, to organize public bug days which we now run every other week as part of the QA weekly goals, and to do bug report triaging. Valerie succeeded in all of them and blogged about her experience and progress, but I’d like to summarize and highlight some of her achievements here.

Valerie analyzed which important Wikimedia feedback channels link to each other and Bugzilla and created a diagram of the current situation, and also a bug life cycle flowchart describing the life of a bug report by its status changes over time. That diagram is now also embedded in our wiki documentation making it easier to understand for Bugzilla newcomers “how things work”.

Wikimedia Foundation Logo

She also wrote and published two blogposts in the Wikimedia Blog explaining how to create a good first bug report and how to help Wikimedia squash software bugs. And apart from co-organizing a number of bugdays, Valerie also participated in Mobile QA by testing the Commons Upload app, helped me with Bugzilla administration (creating new products and components), and taught me about Bugzilla functionality that I had never used before, yay. :)

As this was the first time that I intensively mentored somebody I must say that it went surprisingly well, realizing the presence of all those skills which are helpful for bug triaging: Good analytic skills (what a bug report is about and what not), finding your way to gather information via the query interface, spotting things in the Bugzilla interface and being curious enough to investigate yourself, and a structured approach to testing by using different browsers, coming up with quick testcases yourself, and being aware of MediaWiki’s deployment schedule (basically: which software version is deployed on which server).

So I think we’ve learned a lot from each other, and I’m very happy that Valerie is going to stay involved in our community and bug management.

In general, I’d like to thank Marina Zhurakhinskaya (for GNOME) and Quim Gil (for Wikimedia) for organizing OPW and I am delighted to see more projects planning to join the next round (like KDE, Perl, and more).
The application period for the next round of OPW has already started and its deadline is May 1st. Check out the central wikipage if you’re interested!

Wikimedia’s Bug Management

Tuesday, January 1st, 2013

Wikimedia Foundation Logo

About three months ago I started as bugmaster / bugwrangler of the Wikimedia Foundation (the non-profit organization behind Wikipedia). It’s about time to finally blog before everybody expects WMF to be the same black hole that Google is seen as when it comes to free and open source people suddenly disappearing. ;)

A Day in the Life of a Bugmaster

As part of my daily work I take a look at the latest Wikimedia bug reports and go through some of the feedback sources (like Village Pumps or Greasepits) in the many projects under the Wikimedia umbrella. I also often take a look at reports with immediate and highest priority.


Earlier in December we managed to upgrade Bugzilla from 4.0.9 to version 4.2.4. The upgrade itself did not go 102% perfectly, but still went extremely smooth and way better than I was afraid of.

As I’ve used Greasemonkey scripts for years now to save some time when triaging bug reports, I’ve published the ones that I use in Wikimedia Bugzilla here. Patches are welcome, and the code could likely use some refactoring anyway (IANAC).

And more!

I’ve retriaged a bunch of tickets that were previously marked as “RESOLVED LATER” in Bugzilla and disabled that resolution for future use (also see the related mailing list discussion), plus the huge backlog of unprioritized tickets.

I’ve improved and wrote lots of documentation related to bug triaging, for example a triage guide.

We discussed the interpretation of “Highest priority” and ended up introducing an “Immediate priority” which leaves less room for interpretation.

Plus I got in smaller fixes, e.g. fixing some regexes in Wikimedia’s Bugzilla extensions.

You can find weekly status updates that I publish.

The things around

In the last three months MediaWiki/Wikimedia bug management have seen and survived the merge of ContentHandler, a new media player (TimedMediaHandler) for better HTML5 multimedia support, and first deployments of improved user experience tools such as ArticleFeedback 5, VisualEditor and Notifications. First Wikidata deployments and moving to a new data center are on the list of potential disruptions for early 2013.
And I’ve had fun with server software upgrades, understanding our release cycles and continouos deployment, and watching and analyzing the usage (or non-usage) of the bugtracker by different development teams.


I still need to prioritize my long backlog of potential future plans and ideas. Of course some smaller drive-by cleanups have taken place already.

Among the plans for early 2013 are automatic notifications from Gerrit into Bugzilla about patch status changes (Wikimedia Germany seems to work on that), component watching via bugmail, and a new and more useful Bugzilla frontpage.

Plus for the next three months I will have the pleasure to work with Valerie as part of the Outreach Program for Women. Part of the grand plan is to start having monthly bug days to triage bug reports together – are you in?

And of course WMF is hiring – take a look if there’s a position that fits you!

Free knowledge: Here we go.

Wednesday, October 3rd, 2012

Wikimedia Foundation Logo

I am very happy to announce that from next week on I am going to help Wikimedia Foundation (the organization behind Wikipedia and further projects) tame their bug tracker and manage everything and anything related to issue reports and feature requests.
This job is called a “bug wrangler” (also known as “bugmaster“).

I already had the pleasure to attend the Wikimedia Hackathon earlier this year to get to know the awesome community of this large and important project better and to discuss some patterns, problems and plans. To be continued…

Wikimedia Hackathon, Berlin.

Saturday, June 2nd, 2012

I’m in sunny and windy Berlin (Germany) again this weekend to attend Wikimedia’s “Hackathon” (Wikimedia is the organization behind Wikipedia and some other projects and websites, in case you didn’t know). I’d like to thank Wikimedia Foundation for the invitation.

Apart from discussing bug management with people I spent most of the day looking at the situation in Wikimedia’s bugtracker a bit – checking the growth rates in the most popular products (where to triage reports more aggressively), gathering some statistical data, trying out funky queries to identify rotting reports (no NEEDINFO state or tag? Sigh, Mozilla Bugzilla makes the same mistake), adapting one of my Greasemonkey scripts to work, looking at existing Wikimedia bug management documentation and identifying missing and redundant information, and in the coffee breaks dreaming of a Natural Language Processing hook when submitting new tickets to analyze the quality of a report on the fly and make the reporter improve it (I know that there’s scientific papers about this topic but I still haven’t seen any implementation so far). Errm, yeah, that was a long sentence.