Comments on: Improving Bugzilla: People, Bugs, Search, and Planning http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/ -- aza | ɐzɐ -- Sat, 20 Mar 2010 03:01:43 +0000 http://wordpress.org/?v=2.6.5 By: Vinod http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-5346 Vinod Thu, 14 May 2009 11:40:41 +0000 http://www.azarask.in/blog/?p=212#comment-5346 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. 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.

]]> By: Benjamin Smedberg http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3478 Benjamin Smedberg Thu, 15 Jan 2009 17:31:29 +0000 http://www.azarask.in/blog/?p=212#comment-3478 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 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

]]> By: Luke Sommer http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3389 Luke Sommer Mon, 12 Jan 2009 09:07:40 +0000 http://www.azarask.in/blog/?p=212#comment-3389 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. 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.

]]> By: Samuel Sidler http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3285 Samuel Sidler Mon, 05 Jan 2009 14:29:44 +0000 http://www.azarask.in/blog/?p=212#comment-3285 (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? (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?

]]> By: Aza Raskin http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3258 Aza Raskin Sun, 04 Jan 2009 02:22:35 +0000 http://www.azarask.in/blog/?p=212#comment-3258 @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 :) @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 :)

]]> By: Steven Garrity http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3256 Steven Garrity Sun, 04 Jan 2009 01:27:34 +0000 http://www.azarask.in/blog/?p=212#comment-3256 * 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. * 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.

]]> By: Gerv http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3253 Gerv Sat, 03 Jan 2009 21:33:36 +0000 http://www.azarask.in/blog/?p=212#comment-3253 @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. @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.

]]> By: Aza Raskin http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3249 Aza Raskin Sat, 03 Jan 2009 20:24:46 +0000 http://www.azarask.in/blog/?p=212#comment-3249 @Gerv: I wonder if that should be integrated with Blizzard's whoisi.com. @Gerv: I wonder if that should be integrated with Blizzard’s whoisi.com.

]]> By: Aza Raskin http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3248 Aza Raskin Sat, 03 Jan 2009 20:22:51 +0000 http://www.azarask.in/blog/?p=212#comment-3248 @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. @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.

]]> By: Aza Raskin http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/#comment-3247 Aza Raskin Sat, 03 Jan 2009 20:00:46 +0000 http://www.azarask.in/blog/?p=212#comment-3247 @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. @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.

]]>