Improving the Bugzilla Product Selection

Selecting the right product and component for bugs filed on has been a challenge for many users in the past years.
Our bug wranglers had the “pleasure” of closing or moving a plethora of misfiled issues which either could have been directly assigned to the proper team, or weren’t suited for a bug report in the first place.

How do so many issues end up being improperly filed and what can we do to mitigate that problem? Let’s take a trip back in time.


Before our upgrade to Bugzilla 4 (which happened in March of 2011), our component selection looked like this:

Selecting a Product in Bugzilla 2

An unstyled table listing every component in alphabetical order, even though the Gentoo Linux product accounts for a good 90% of the bugs filed on our Bugzilla. I personally really like the note printed above the table: GENTOO LINUX IS WHERE YOU PUT EBUILD BUGS. The uppercase letters—put as if used on IRC to denote shouting—seem to express the developers’ desperation in an attempt to get users to use the product they likely should be using–and not Bugzilla (because we’re on Bugzilla after all) or any of the other things listed (mhh, Infrastructure, sounds like a place to report my build failure).

I doubt we can really blame our users for not making much sense of this table mess with no clear visual structure and a NOTICE printed on top that is as eye-catching as insert good analogy here.

Bugzilla 4: Yes, we skipped 3

By the time Christian (idl0r) took over Bugzilla maintenance and prepared the upgrade to version 4 of our beloved bug-tracking suite®, I worked on some visual bits, gentooifying the bug filing and browsing experience and also made an attempt to reduce the number of bugs misfiled by users confused with the selection provided.

The result was a new product selection page offering the Gentoo Linux product in its own section, complete with examples which bugs should be filed there and which ones shouldn’t:

Selecting a Product in Bugzilla 4

Monitoring the Bugzilla component, in the weeks after we deployed the update, I noticed that there were less bugs misfiled there that should have been Gentoo Linux issues. Success!

The future? Selecting issues instead of components

But we still haven’t fixed the issue of presenting people with a wall of text, one that few people seem to read anyway, as for instance plenty of Security issues still are filed in Gentoo Linux even if the examples explicitly list these as not belonging there. So we need further improvement.

Speaking of improvement, I currently am working on a super secret project I gave the super cool name Tyrian (named after the tyrian purple). It aims to give our websites a new, unified look, including Since I’m already ripping apart the current (and might I add awfully outdated) Bugzilla HTML markup, I could just as well experiment a bit more with product selection to hopefully generate better bugs.

Here’s what it looks like as of now:

Selecting a product in the Tyrian Bugzilla theme

You no longer get a list of components, you get a list of issue types you might have, thus we switch terminology from ours to one users understand and use as well. A search bar provides a keyword search functionality, for instance people might not be familiar with the specific term Version bump, so searching for “update” or “upgrade” would also find a version bump request.

Another issue that occurs is that people don’t read additional instructions for certain bug types, given our version bump we usually ask people to wait for two days before filing a bug, just because we might already have it in the tree by then. My take on fixing this is requiring more interaction by the user. Each of the issue types in the list can trigger an additional confirmation dialog containing extra instructions that the user needs to explicitly acknowledge before filing a bug:

Confirming selection

What, you use JavaScript?

I have implemented this selection feature using a few lines of jQuery code with a JSON object as ‘database’. The version bump entry looks like this:

   "title": "Version Bump",
   "tags": ["update", "upgrade", "new"],
   "desc": "Request to update existing software in Portage, no security-related update",
   "prod": "Gentoo Linux",
   "comp": "",
   "note": "No Security updates should be reported here!<br><br>Please wait at least <strong>48 hours</strong> after release before reporting package updates.",

It is triggered when any of the words in ‘title’ or ‘tags’ are (partially) entered into the search field. ‘prod’ denotes the component we use for this kind of issue, ‘comp’ the next-level component (optional) and if ‘note’ is set, it contains the HTML to display to the user.

From our Website survey I conducted last year, I know quite a few Gentoo users don’t particularly like modern web technology like JavaScript. For those of you, the feature falls back to the classic selection used in the current Bugzilla version (just a bit prettier). Beware though, you get to be extra careful when filing bugs. Or else!


This was the first preview of new things planned for (more hopefully to come).

Any usability gurus among the Planet Gentoo readers? I would welcome some feedback (or issues you think might be worthy to include in the list).

8 thoughts on “Improving the Bugzilla Product Selection”

  1. Hi Alex,

    I see big improvement in re-categorization of the bug type to the issue type perspective.
    In some cases I really don’t know what group I should pickup in these days :-), so finally I use the abstraction path and select some general group like Gentoo Linux, which I even know is wrong and I am generating just another work to the developers, which is wrong.

    Can you post the whole setup of Issue category so I can think from my experience about the whole set?

    Regarding that UI aspect I will think about it in more detail.

    Good job!


    1. Here is the current list. Lots of it just copied from current components and products plus some additions like recently filed bugs (like Wiki article issues which don’t belong on b.g.o at all).

  2. While you’re at it… what do you think about providing MarkDown support for b.g.o?

    There is a plugin/hook which seems to work mostly and might be integrated in future releases:

    I really miss being able to structure text at least a bit in Bugzilla.
    Maybe it could be provided as “hidden feature” for now until it is considered stable upstream.

    1. This seems to be more than just a UI update, so I’m reluctant to add it to the list of things to do with the next update I work on.

      But if it’s going to be shipped with Bugzilla in the future, we’re likely going to have it as well.

  3. “But we still haven’t fixed the issue of presenting people with a wall of text, one that few people seem to read anyway, as for instance plenty of Security issues still are filed in Gentoo Linux even if the examples explicitly list these as not belonging there. So we need further improvement.”
    Well, the example lists “Security Updates”, you talk about “Security Issues”, those can be very different subjects based on interpretation.

    The basic problem is that Bugzilla is structured based on internal organization. If you don’t know that the grouping is a total mess.
    Just like a number of other categories overlap as their main purpose is to help with the available fields/assignments, not logical separation. Stuff like Infrastructure/Mirrors/Website, the different documentation groups, Gentoo Hosted Projects/Gentoo Linux/Portage Development are mostly the same from an external point of view. Gentoo/Alt overlaps with the platform field, and Community Relations/Gentoo Developers/Staff and Gentoo Foundation don’t make any sense to users at all.

    The “guided” form is a nice idea, but don’t expect much of it. Stuff like “updates here, except what we consider security updates” just isn’t intuitive so it’s never going to work as you’d like.

    1. Well, the example lists “Security Updates”, you talk about “Security Issues”, those can be very different subjects based on interpretation.

      Um, these still share ‘security’ as keyword. Searching for it would yield the appropriate issue type right away.

      The “guided” form is a nice idea, but don’t expect much of it. Stuff like “updates here, except what we consider security updates” just isn’t intuitive so it’s never going to work as you’d like.

      Well then, what is? :)

  4. Hello

    Now we see where your efforts on Bugzilla went; good job, this will definitely help.

    tyrian-prod-select.png could be made more usable by bringing more room for the options and removing redundancy:

    – The “Enter Bug” doesn’t add usability value because this is already implied by the question “What kind of bug would you like to report?” thus the “Enter Bug” title could be removed. On the same line, there is a quick search; since this gets to be on every page, I think this would be something that is to be part of every page, thus this can move to the header (assuming the header is made slightly larger) Both these changes would remove a 40px in height which moves the warnings up and brings more bug types on the screen.

    – Just a readability issue that could yield more usability; is that there is a lot of “request” repeated, I’d suggest removing all occurences of “Request” and “Request(s) to” such that the word never sits in the way. As a bonus, it gives the users a slight feeling to be more in control and thus encourages them to continue to file the bug; as things would read “Update existing software in …”, “Add software to …”, “Add Security updates …” and “Keyword or stabilize” which are all action descriptions and don’t co-notate that the bug might not be answered (due to the request nature).

    – I think that there might be a bit of redundancy between the warnings (“Before reporting …”, “First time reporting …” and “Always attach …”) as well; which I wonder if we can combine at least two of them into a single box. I think that the “please make sure the …” text can fit after the “Always attach” warning such that both fit in the same box and you effectively spare out one box. Perhaps the support venues can be shortened to link to a page that details the various support venues we have.

    Some other questions / feature requests (after writing this I see you’ve put some of these in the warnings, but I wonder if they could instead be on the bug page):

    – Can we also automatically ask the user for build.log in a red warning above the bug filing form when applicable?

    – If the “config.log” warning is found in the build.log output, can we ask for config.log in the same style as above?

    – If a segmentation fault or something similar is detected in a comment or an attachment, can we direct the user to such that the user can provide better details?

    – Can we do something similar to the above for ICE errors in compilers?

    – Will the package ATOMs be separate fields (see Kensignton’s Bugzilla instance for an implementation example) such that this eases bug wrangling as well?

    For the other screenshot tyrian-prod-select1.png I am not sure whether doing it this way is a good idea, it feels kind of like an extra nag screen “do you really want to do this?”.

    We could perhaps suggest the user instead to do this based on heuristics on what is being input in the field, mentions of terms like CVE for instance are of interest, but also terms like DoS, privelege escalation, buffer overflow, …; and then even further less clear words might be used as indicators as well to then suggest the user to change the product / component.

    It’s not that the nag screen is necessarily bad for first time visitors, but it could end up being tiring if you file multiple bugs. Or is this only for he basic filing method and not for the advanced one?

    On a side note, I don’t understand why it mentions “48 hours” on that product warning, isn’t this something that belongs to one of the sub components (eg. “version bumps”)? Oh, just saw in the json that this is for a component, I think the title of that warning box has a mistake then.

    And for a last suggestion, it would be nice if we can let a group of users test this particulac bug type feature; since you are opening up users to a text box where they can input anything, it might be used differently than you intended to. I imagine users entering “slow boot”, “kernel bug”, “poppler blocker”, “permission/access denied”, “package patch”, “forgotten dependency”, … and the list can go on and on.

    Feel free to let me know if I can help you with something.

    Thanks you for working on a new Bugzilla and thank you in advance.

Leave a Reply

Your email address will not be published. Required fields are marked *