Improving Bugzilla: People, Bugs, Search, and Planning

1. Curtis Bartley 12.29.08 / 3pm

   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.
2. Aza Raskin 12.29.08 / 3pm

   @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.
3. picardo 12.29.08 / 4pm

   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?
4. Max Kanat-Alexander 12.29.08 / 4pm

   * 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
5. Max Kanat-Alexander 12.29.08 / 4pm

   @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
6. Max Kanat-Alexander 12.29.08 / 4pm

   @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
7. Axel Hecht 12.29.08 / 5pm

   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.
8. Aza Raskin 12.29.08 / 5pm

   @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.
9. Guy Pyrzak 12.29.08 / 6pm

   @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.
10. Smokey Ardisson 12.29.08 / 6pm

    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). :-(
11. Ryan Doherty 12.29.08 / 8pm

    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.
12. Prakash 12.30.08 / 1am

    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 :-(
13. Archaeopteryx 12.30.08 / 4am

    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.
14. Philip Ganchev 12.30.08 / 7am

    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.
15. Sander 12.30.08 / 7am

    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.
16. Ted Mielczarek 12.30.08 / 11am

    * 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.
17. Philip 12.30.08 / 6pm

    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
18. Gerv 1.1.09 / 3pm

    “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.
19. Aza Raskin 1.3.09 / 3pm

    @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.
20. Aza Raskin 1.3.09 / 3pm

    @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.
21. Aza Raskin 1.3.09 / 3pm

    @Gerv: I wonder if that should be integrated with Blizzard’s whoisi.com.
22. Gerv 1.3.09 / 4pm

    @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.
23. Steven Garrity 1.3.09 / 8pm

    * 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.
24. Aza Raskin 1.3.09 / 9pm

    @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 :)
25. Samuel Sidler 1.5.09 / 9am

    (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?
26. Luke Sommer 1.12.09 / 4am

    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.
27. Benjamin Smedberg 1.15.09 / 12pm

    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
28. Vinod 5.14.09 / 6am

    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.

All material copyright Aza Raskin. But you can have the color magenta.

Entries RSS Comments RSS