Getting bugs done
I believe Bugzilla's workflow can be improved using one of the central ideas from Getting Things Done, the "next action".
Currently, the answer to the question "what is needed to move this bug forward?" is scattered throughout each bug report. Sometimes it's a keyword, sometimes it's a review flag, and sometimes it's the third-to-last comment. It takes me maybe a minute per bug to determine whether I can help, and this wasted time adds up quickly.
Next-actions for bugs
I propose replacing the status field with a next action field, and the assignee field with a next action assignee field. The "next action" field answers the question "what is needed to move this bug forward":
|
|
|
|
Organizing actions by context lets me remember projects when I can move them forward, rather than when they only increase my anxiety. This may be even more important in a community system: who you are is a key context determining whether you can do something.
With a next-action field, it would be easier to find places to put my skills to good use:
- Did Brendan hope to have this patch fuzzed?
- What bugs are waiting for input from the security team?
- What bugs could benefit from extension-space experimentation?
With the addition of a next-action-assignee field, I'd also be able to do searches like:
- What have I been asked to do in Bugzilla?
- What blockers are stuck on me?
- What bugs need someone to volunteer to make a reduced testcase?
Simplifying Bugzilla
I'm asking for new fields, but I think this will actually make Bugzilla less complicated. The "next action" field and its assignee would replace:
- The current "status" field, which is mostly useless because each open state (unconfirmed / new / reopened / assigned) can mean so many different things.
- The current "assignee" field, which is misleading when the next action required is anything other than "write a patch" or "check it in".
- Eleven keywords: uiwanted, qawanted, helpwanted, stackwanted, icon, testtracker, crashreportid, regressionwindow-wanted, testcase-wanted, checkin-needed, push-needed.
- Status whiteboard markers like "[needs review gavin]" and "DUPEME".
- Many comments that are only temporarily meaningful.
It would also make our process more transparent: there is always a first-level answer to "Why hasn't this bug been fixed yet?"
April 20th, 2009 at 12:15 pm
From all my experience with gtd, this is the best proposal to advance things for Mozilla since a long time. Man, do I wish I could flags bugs this way.
April 20th, 2009 at 2:22 pm
That idea is genius, Jesse. File a bug on it? You’ve got my vote.
April 20th, 2009 at 2:43 pm
So i would actually say those fields are great, but it seems that the actual problem is Mozilla is still using Bugzilla like it is an older version of Bugzilla.
The status is now fully customizable. Many of the things you describe could be used as part of the status workflow.
As far as the status whiteboard markers, i don’t understand why flags are not being used that way for example i’d make a flag “is_a_dup” that is specifically request-able from gavin.
The way i decide between what should be a flag and what should be a status is the following:
– Is this the state of the bug that affects where it is going, “its lifecycle”
– Is this a yes no question.
Your suggestions also gave me some other ideas
– next action, is very do-able in 3.2. I’d recommend a drop down, but I’d like to have the ability to have an autocomplete drop down UI but that’s a different story.
– Next assignee, has been implemented where i work. I think in the Mozilla realm, it will need to be a bit different b/c i assume perhaps incorrectly, that Mozilla wants to ask a group not an individual to look at something.
I do wonder if an improved flags UI would help with these sorts of statements/questions, especially since permissions on those can be controlled much more effectively than other fields.
So I would describe the GTD workflow as this What has to happen next for this bug, What subtasks does this bug need to pass before I’m ready to move onto the next task.
April 20th, 2009 at 4:44 pm
I know that the first question I often ask when I visit a bug is “what’s next” followed by “who are we waiting on”.
April 20th, 2009 at 5:14 pm
Are you proposing that table as the literal set of values for next-action?
People hardly use the Status field now, do you expect that they’d actually set a field with that many options? Though granted, you’re right about it eliminating the keywords, and a certain set of people do use those.
-Max
April 20th, 2009 at 5:20 pm
The table is examples. I’d want Bugzilla to nudge users toward using consistent terminology, and make it easy to select the most common actions (perhaps based on the just-finished one), but allow free-form text in that field as well.
People hardly use the Status field now because the Status field is useless. This new field would save time by reducing the need for writing boring comments and jumping between fields.
April 21st, 2009 at 12:08 am
This is a great idea!
April 21st, 2009 at 10:22 am
You should not ignore the social aspects of this. I certainly bloodied my nose on this when I proposed exactly the same thing a few years ago. It seemed then that a commercial software house is much better at determining who the DRI for some needed action is and making that stick. The Mozilla community really seems to like things to be a little looser than that.
I have gotten to the point where I set up a rule engine alongside Bugzilla that points to bugs in the database. It really helps to be able to form a logical inferences, inferences which may relate to othjer inferences in different ways, and test a set of bugs against that inference. Trying to be creative with the whiteboard and such was just getting old.
It is arguable that Bugzilla should be a system, with different front-ends for entering different kinds of bugs and different apps for analyses. A start could be made on this by creating special purpose web apps alongside Bugzilla, and see what refactoring is needed, but the database would have to be more accessible than it is.
April 22nd, 2009 at 4:58 am
Yeah, no, this could be a good idea. We could experiment with it after we upgrade to Bugzilla 3.4, if you can convince IT and the rest of Engineering.
-Max
April 29th, 2009 at 12:42 pm
I linked to this blog post in mozilla.dev.planning, and a discussion started there as well.
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/aa627caed996d9bc