Improving Bugzilla: People, Bugs, Search, and Planning
The Firefox UI team recently got together with the Bugzilla UI team to brainstorm future features and user experiences for Bugzilla.
We scoped our brainstorming session to be between trivial fixes and doable-in-a-couple-months features. That is, pragmatic, nearish-term sorta-big thinking. Our brainstorm revolved around four major themes: People, Bugs, Search, and Planning. Of course, during the session most of the themes blended together — real-life is never as orderly as our a priori taxonomies would have them.
Before we delve into our thoughts, what would make Bugzilla better for you? For a beginning contributor? For project management types? For a one-time bug submitter? Most of the Firefox contributors spend most of their day in Bugzilla, so any improvements made are dramatically multiplied.
Many thanks to the folks on both teams who took the time to sit down for the better part of an afternoon. In particular thanks go to Max Kanat-Alexander, Alex Faaborg, Jennifer Boriss, Madhava Enros, Dave Miller, and an especially large thanks for Guy Pyrzak (who took notes and guided the session).
Thoughts on Bugzilla
People
* Bugzilla is fundamentally about issue tracking. But Bugzilla is also scaffolding and structure for the people who report and fix those bugs. Make people first-class citizens in Bugzilla (yes—a social platform…)
* Help users determine “who is this guy”, when looking at bug reports and commenters. Dashboard for people: what bugs they’ve filed, what patches they’ve submitted, what groups they are in, how active they are, etc. See Github for an example.
* Social rankings by participation (bug submitting, duplicate marking, patch submitting, patch reviewal, high-valued comments, etc.). Social incentives and social standing.
* Help create a “team” feeling. Should be able to become a part of a virtual working group (I’m interesting in UI, Graphics, Networking, etc.). There are some open questions here: Are built in user groups good enough? Is fluid definitions of groups better than restrictive (probably, yes).
* Autocomplete for user names, ordered by social ranking.
* Extensible, RESTful APIs for accessing the social graph and other social features. Support Open Social API.
Bugs
* Allow tagging comments with meta data (useful/troll/repeat/etc.) to make it easier to read, parse, and participate.
* Display users and groups in comments (in the classes/style area). This way ambient information about which comments are important can be visual indicated.
* Understanding how “Hot” a bug is. How many times has it been viewed? How many times has it been commented on? How many times has it been marked as a duplicate of other bugs? How often people start to create a bug that they find out is a duplicate?
*A five-minute undo/edit ability for bug comments. So that when you’ve got that bother-I-forgot-to-spellcheck feeling just after hitting submit, you can do something about it.
* Google Mail style shortcuts to help with efficiency handling bugs (would require some more info on most used actions)
* Improve Bugmail work-flow with a more human readable format. Better fonts, better diffs, built-in threading.
Search
* Make search not horrible! It should be as painless and as easy to find the bugs you need to find (or the ones you didn’t know you need to find) as a web search.
* Make automatic finding of duplicate bugs a zero-cost action for users.
Planning
* Create a dashboard overview of projects, groups, and sets of bugs. See Trac. Questions the dashboard should answer: When are we going to release? What needs to be done for the next milestone? How can I get involved, and at what level? What’s happened since the last time I checked? Which things are at risk? What’s the big picture? What’s the long term trending?
RT @azaaza Improving Bugzilla: People, Bugs, Search, and Planning | Follow @azaaza on Twitter | All blog posts
Curtis Bartley
One really simple change I’d like to see is how form posts are handled in Bugzilla. Right now, when you make a change of any sort, say add a comment, and submit, the result of the form post is the newly updated bug. That’s convenient. That is, right up until you see an email that someone else has made a change that you want to see. The bug’s still up, so you naturally hit F5/Cmd-R to refresh the bug. The problem is that when you do this, Bugzilla tries to resubmit the last change, which you don’t want to do.
I think there’s probably a simple way to deal with this — have a separate page that’s displayed when you submit, and have that page automatically redirect back to the main URL for the bug using a GET rather than a POST. The basic behavior would be the same as today — you submit a change and immediately see an updated bug. However, when you refresh, your view of the bug updates just like you expect, and there is no accidental duplicate form submission.
Aza Raskin
@Curtis That’s a good point. I’ll forward it back to the Bugzilla folks.
Another thing I forgot to mention was a five-minute undo/edit ability for bug comments. So that when you’ve got that bother-I-forgot-to-spellcheck feeling just after hitting submit, you can do something about it.
picardo
This is probably going to sound too simplistic, but I’d really like it if Bugzilla’s bug submit form were made usable, dynamic, and tabbed.
Using more Javascript would improve a lot of the ugliness and difficulty. The description fields can be presented as tooltips over the textboxes. The steps to reproduce field can be a tooltip as well, rather than a prefilled list of numbers 1,2,3.
Second, some fields could be automatically filled to make life easier. Operating system, browser, and some other fields I forget can be grabbed directly from the browser’s native objects, right? So why aren’t they?
In general, my vision of the form is one that can be fitted entirely above the fold of the page, the cut off line of the viewport, so no one has to scroll down in order to fill the form.
My pet peeve is forms that are burdened by superfluous fields, overly complicated explanations, and lacking in asynchronicity — even though ajax has been with us for so long.
Can Bugzilla team do something about these concerns?
Max Kanat-Alexander
* The “who is this guy” thing–definitely a good idea.
* The social rankings system exists on bugzilla.gnome.org as a “points” system. I may be doing an upgrade of bugzilla.gnome.org to Bugzilla 3.2 as a contract fairly soon, and I may be able to make the “points” system into a plugin that all Bugzillas could use.
* I’d rather see the autocomplete for user names just stay alphabetical. But it should definitely exist.
* Nearly all the social aspects should be plugins. Launchpad has this sort of stuff in it by default and it makes the UI just crazy complex.
* The bug tagging thing would probably be better with a fixed set of tags as opposed to user-generated tags, in which case it would effectively be this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=283695
* The undo/edit thing is feasible and probably a good idea, but somewhat of a low priority. We’d still have to send out an email with the new comment, or perhaps just an email that the comment changed. So it’d be nice for people looking at the history, but it would be just the same as it is now (pretty much) for people already subscribed to the bug. Anyhow, this is essentially bug 540.
* Shortcuts are definitely a good idea. Already the “Mark as Duplicate” link helps me and others out.
* The bugmails should definitely be improved, but that requires a lot of backend work first. That’s basically this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=301447
* In search, that first item is nice to write, but without some more concrete ideas than that, what we have now is in practice better than any other bug-tracker I’ve used. (In fact, the search in Bugzilla is one of the main things that people pick Bugzilla for.)
* The duplicate-finding thing is definitely possible. Launchpad has an algorithm for that, and the LP project manager said he’d give me the algorithm.
* Dashboard–definitely a good idea.
-Max
Max Kanat-Alexander
@Curtis What you want is the following two bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=365078
https://bugzilla.mozilla.org/show_bug.cgi?id=427913
What I want is those two bugs plus the ability to preserve the list of who was emailed, which is actually fairly useful, at least to me. In a normal web application, we’d do this with sessions, but we’re tied to supporting mod_cgi with no web framework, so all we have are cookies. Any ideas in this area would be welcome (as comments on the bugs).
-Max
Max Kanat-Alexander
@picardo I take it that you’re using the simple entry form on bugzilla.mozilla.org? That’s essentially a custom form that they use.
OS and Platform are already grabbed from the browser.
We have a bug for making the default enter_bug form simpler. It actually requires very little work at this point, but the developer assigned hasn’t done anything about it for a while.
-Max
Axel Hecht
Hrm. None of the above on my list.
To me, mass handling bug queries and APIs are way more important than the features mentioned here.
Like, my use case is getting all blocker bugs for bugs that have an alias of the form … in a json output would be valuable. I guess that might be useful in a different variant for project triage, too.
Proper escaping of bug data in the various output formats, too.
FWIW, I didn’t find trac useful in the few projects that I have seen use it. I’d rather see us code a dashboard as an app on top of bugzilla and other web apps using bugzilla APIs than trying to incorporate every use case into it.
Aza Raskin
@Axel: You are absolutely right. Having everything accessible through a RESTful web api would be fantastic — allowing full separation of front-end from backend. Even better if it can be accessed through JSONP, so that anyone can whip up a mashup to create dashboards, etc.
Guy Pyrzak
@Axel: Work is currently being done to add a json capabilities to bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=432907), it’s using json-rpc, which isn’t restful, but I do think that it is a step in the right direction. Dojo has full json-rpc support. The hope is if this is helpful, more restful like capability could be added if it determined that the json-rpc capabilities are not fitting the bill.
Smokey Ardisson
Loading a bug and the advanced search page is too slow, and queries seem to take longer to run (more time spent watching Chompy). I’ve been working in bmo for five years now, and it seems over the last year or so page load times have increased noticeably even while my hardware and browser have gotten faster!
Unfortunately I don’t know how to instrument this (unless someone has a time machine hidden away!); I just know that it’s painful to use now and it didn’t use to be (even those periods of time when I used to be on dial-up). :-(
Ryan Doherty
All these ideas sound great. Where are the notes located? Is there a project planning wiki or buglist for all these features? I’d love to follow the progress.
Prakash
I would love if Bugzilla allows search engines to index – without hurting its performance. At Eclipse.org’s Bugzilla, the search engines are not allowed to index, simply because it kills the CPU :-(
Archaeopteryx
Being better able to define when you will receive bugmail by using user-defined tags would be helpful. At the moment, I can’t unsubscribe to a bug I reported and not watch a list of collected bugs for changing theirs status to RESOLVED.
Philip Ganchev
In search results, duplicate bugs can be hidden, only showing their count or list of bug IDs next to the main bug. Clicking on a show/hide icon next to the main bug could show the duplicates indented under it. Of course, there would still be a global setting for showing or hiding and sorting of duplicates.
Maybe the search form could be simplified by putting the filters inside the results, in the form of combo-boxes. That would also make the search process more direct and real-time. Example: search for bugs matching some tags or strings; see the results; filter the results by selecting “Normal or higer” from the Severity field’s combo box at the top of the result list. A possible drawback of this added convenience is an increased server load.
Sander
I’d certainly hope there’d be a way to opt-out of any “open social” data sharing, and to hide all the social “rankings” crap from view if you’re not interested in it. I contribute (in however minor a way that might be over time) because I care about bugs being fixed and the products getting better, not because I want a high “social standing”; yet as soon as you introduce that concept, people will start figuring out how to game the system. (For an example of how bad it can get, see the outrage in the comments at stackoverflow when they tweaked their “reputation” algorithm: http://blog.stackoverflow.com/2008/12/vote-fraud-and-you/ )
I’d also worry about getting that “team feeling” implemented just right. One of the great things about the Mozilla community is that participation goes very gradual; you can put in one hour, three hours, ten hours, twenty hours or sixty hours a week (and change from one extreme to the other and back), and there’s not much of a difference between each of those ‘levels’. Yet when you draw lines to include people, you’ll automatically _exclude_ people, too. The “fluid definitions” mention in the notes gives me some hope that this is being considered, but it’s very easy to get the implementation wrong, and very hard to get it right.
Ted Mielczarek
* Help users determine “who is this guy”, when looking at bug reports and commenters.
Yes, please. I’ve wanted this for quite some time. I think usernames should link to a user info page by default, instead of an email link. (I practically never email people directly from bugzilla, why is that the default?)
* Autocomplete for user names, ordered by social ranking.
I have a bitrotted patch for this on bug 386600 (well, not including social ranking). It would be super handy.
I’d also second Curtis’ request about having process_bug.cgi do something so that session restore can restore it.
Philip
Google Code has some ideas [1]:
- Hide “+1″ comments; maybe provide a count instead, maybe allow users to “star” an issue instead.
- Issue dependence (blocking) and merging
- Assigned code reviews
- Feeds for issues and whole projects
- Auto-link URLs
- Compact notification emails
[1] http://code.google.com/p/support/wiki/WhatsNew
Gerv
“Help users determine “who is this guy”, when looking at bug reports and commenters. Dashboard for people: what bugs they’ve filed, what patches they’ve submitted, what groups they are in, how active they are, etc.”
Yes, but don’t build it into Bugzilla. One of the things we’ve been looking at at the MoFo is a central community “Who I am” system. This can be queried by all sorts of systems – e.g. Bugzilla, Chatzilla, Thunderbird – so that when you come across someone in the community, you can find out who they are and what they do. It would have APIs so e.g. you could hover over a nick in Chatzilla and be told:
“gerv is Gervase Markham, MoFo employee and Bugzilla hacker”
or you could click an icon next to their name in Bugzilla and get a full page of info via http, or whatever.
I want to build this some time this year, but plans for everything are still in flux.
Aza Raskin
@Guy Pyrzak: The biggest problem with jumping to JSON-RPC is that it doesn’t allow someone to quickly mock a new interface/view of the data on a separate site. That is, enable low-cost agile and distributed development. All that would be required to make that possible is a little bit of JSONP — being able to wrap the return of JSON-RPC in a function call.
Aza Raskin
@Sander I hear you. Social structures with the wrong incentives can be quiet harmful. The “team” idea is really about ease of joining groups and following sets of related features. It’s not about drawing lines in the sand and keeping people out, but making it easier to feel included.
Aza Raskin
@Gerv: I wonder if that should be integrated with Blizzard’s whoisi.com.
Gerv
@Aza: could be, if Blizzard added the ability for people to add info about themselves, photos, IRC nicks, Bugzilla IDs etc. But I’m not sure if that’s the direction he’s taking it.
The system could, alternatively, reference your whoisi profile rather than keeping track itself of your blog, twitter etc. I don’t know.
Steven Garrity
* Autocomplete for user names, ordered by social ranking.
Rather than just total social ranking, this could (should?) order by a combination of ranking and relation to you. In a large Bugzilla instance, like Mozilla, I end up working with a small sub-set of all users.
Nice to see this type of discussion underway.
Aza Raskin
@Steven Garrity: Yes, that makes a lot of sense. Autocomplete is meant to help you find the people that matter quickly. That’s a function of the bug, your interactions, social standing, and the alphabet :)
Samuel Sidler
(Sorry for the delayed response, I’ve had this tab open for a while but just got around to it…)
All of these ideas sound worth pursuing to at least see if they pan out well and useful. (fwiw, keyword autocomplete is incredibly annoying for me and a lot of users who constantly use keywords.)
That being said, I think there are fundamental things that still need to be done to the currently implemented features BEFORE adding new ones. We can take what currently exists and make it infinitely more useful for every class of user before implementing new features. And, adding new features will likely only clutter the UI down more instead of improving it.
Anyway, your meeting sounded more like a project meeting than a UI meeting. I’d echo Ryan and ask where future work is taking place? What page can I follow?
Luke Sommer
I think a help system for new users that went into more detail would be appreciated. Some simple things like just explaining how to install a patch would be valuable, as I don’t believe that is in the help system.
A dedicated keyword system for parts of a program would be beneficial. For instance, people refer to the url bar as the awesome bar. For searches, this can make it tricky to look at all the bugs pertaining to this bar. A keyword database could be used instead, even as tags, that could be applied by both the submitter of the bug and the viewers.
Benjamin Smedberg
Bugzilla requires everyone to make too many choices all the time.
Reduce to the absolute minimum the amount of information required/presented by bugzilla. Currently we track all kinds of fields (Os/platform/severity/priority/etc). Most of these fields are only useful occasionally, and often just get in the way or are incorrect. Rather than requiring that everyone try to fill in correct metadata all the time, only submit metadata when it’s actually likely to be useful.
Also my little pet peeve: why are Status and Resolution separate fields? Ideally we’d just have one status field, with a simple set of dropdowns like:
UNCO
NEW
ASSIGNED
FIXED
VERIFIED
INCOMPLETE
WORKSFORME
DUPLICATE
INVALID
Vinod
Bugzilla having all basic feature of bug tracking, I feel, all the bugs must be listed when user selects ‘New’ and the relevant product/project. As this will enable user to have a look at kind of issues logged before entering his bug.
The other option would be to place ‘New’ link above the bug list of desired project/product.
Zayıflama Lida Fx15 Ve Biber Hapı Zlfvbh
All these ideas sound great. Where are the notes located? Is there a project planning wiki or buglist for all these features? I’d love to follow the progress.
porno
One really simple change I’d like to see is how form posts are handled in Bugzilla. Right now, when you make a change of any sort, say add a comment, and submit, the result of the form post is the newly updated bug. That’s convenient. That is, right up until you see an email that someone else has made a change that you want to see. The bug’s still up, so you naturally hit F5/Cmd-R to refresh the bug. The problem is that when you do this, Bugzilla tries to resubmit the last change, which you don’t want to do.
Sex
One really simple change I’d like to see is how form posts are handled in Bugzilla. Right now, when you make a change of any sort, say add a comment, and submit, the result of the form post is the newly updated bug. That’s convenient. That is, right up until you see an email that someone else has made a change that you want to see. The bug’s still up, so you naturally hit F5/Cmd-R to refresh the bug. The problem is that when you do this, Bugzilla tries to resubmit the last change, which you don’t want to do.
göt sikiş
Max Kanat-Alexander, Alex Faaborg, Jennifer Boriss, Madhava Enros, Dave Miller,
بنت الكويت
nice A couple of days I told a friend about this, noting that it probably will be realized on Android first.e.
basur
We have a bug for making the default enter_bug form simpler. It actually requires very little work at this point, but the developer assigned hasn’t done anything about it for a while.
دردشة
this is vere niceee
شات
China wholesale beads store, free shipping, and very good post really