Archive for the ‘wikimedia’ Category

Bugzilla Tips (VII): Simpler searching for open tickets only

Friday, July 26th, 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.

If you go to Bugzilla’s advanced search and would like to see only those tickets in your search results which are still open, I have seen users selecting all non-closed statuses (like “UNCONFIRMED”, “NEW”, “ASSIGNED”, “REOPENED” etc. – the exact statuses depend on the configuration of your Bugzilla) either with several mouse clicks while holding down the Ctrl key, or by using arrow keys and Shift on the keyboard.
But you can have the same results with one click in the “Resolution” field: Choose “– – –”.

This is how it looks in Wikimedia Bugzilla:

Screenshot from Wikimedia Bugzilla

Only when a bug report gets resolved (e.g. by fixing it, or marking it as a duplicate) it receives a resolution like FIXED or DUPLICATE. Before it does not have any resolution (hence the “– – –”). This resolution is kept for the follow-up VERIFIED status, but if the report gets reopened it is removed again.

And this is how it looks in upstream Bugzilla:

Screenshot from upstream Bugzilla

Bugzilla Tips (VI): Creating reports and tables

Friday, July 19th, 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.

Quite often I want to quickly check how things are going for specific projects, teams and individuals. Bugzilla’s reporting functionality provides some basic functionality for that. Go to Reports (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):

bugzilla-tips-reports1

Click on Tabular Reports:

bugzilla-tips-reports2

You will get the usual advanced query interface, with additional settings at the top:

bugzilla-tips-reports3

One common usecase for me are tables displaying the severity × priority numbers for bug reports of a specific product or component. For this, I set the “Vertical Axis” field to “Priority” and the “Horizontal Axis” field to “Severity”, and in the interface below I choose one Product (in this example: “Datasets”) and set the Resolution field to “—” as I am only interested in unresolved reports. After clicking the “Generate Report” button I get this table:

bugzilla-tips-reports5

Of course you can also select several products by setting “Multiple Tables” to “Product”.

Another usecase is to check which individuals are set as assignees for how many bug reports whenever I wonder if things scale. For this I set “Vertical Axis” to “Assignee”, leave “Horizontal Axis” blank, leave “Product” blank (so the results are global) and set “Resolution” again to “—” (as I am only interested in unresolved, open reports):

bugzilla-tips-reports-assignees

Click on the table headers to sort the columns.

Or if you have Voting enabled in your Bugzilla, you can get a list how many reports have which number of votes by following the steps above by setting “Vertical Axis” to “Votes” instead of “Assignee”.

Note: Saved reports, similar to saved searches, are available from Bugzilla 4.4 on.

Bugzilla Tips (V): Saved and shared searches

Friday, July 12th, 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.

If you find yourself running the same (or very similar) searches in Bugzilla from time to time, you might want Bugzilla to remember your search at the bottom of the list of search results:

bugzilla-tips-columns-saved

Enter a descriptive name in the text field behind “Remember search as” and click the “Remember search” button:

bugzilla-tips-saved-searches2

Bugzilla will confirm the successful creation:

bugzilla-tips-saved-searches3

Your search will now be available as a link in the sidebar of Wikimedia Bugzilla, or in footer at the bottom of other (standard) Bugzillas:

bugzilla-tips-saved-searches5

If your query could also be useful for other Bugzilla users (e.g. members of your development team), you can share your saved search. Go to your preferences (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):

bugzilla-tips-user-watching1

Click “Saved Searches”:

bugzilla-tips-saved-searches4

Here you can share your search by enabling the “Share With a Group” checkbox, or also display saved searches that other users have shared:

bugzilla-tips-saved-searches4

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):

bugzilla-tips-user-watching1

Click “Email Preferences”:

bugzilla-tips-user-watching2

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.)

bugzilla-tips-user-watching3

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

bugzilla-tips-user-watching4

⁑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”:

bugzilla-tips-columns-saved

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:

bugzilla-tips-columns-change2

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.

bugzilla-tips-autocomplete-CC1

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

bugzilla-tips-autocomplete-CC2

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:

bugzilla-tips-autocomplete-CC3

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.

opw-logo

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.

Code

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.

Future

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!