#Bugzilla bug status workflow Patch#

This new field would save time by reducing the need for writing boring comments and jumping between fields. People hardly use the Status field now because the Status field is useless. 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, 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. 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”.Īre you proposing that table as the literal set of values for next-action? 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. 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. 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. – Next assignee, has been implemented where i work. 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. Your suggestions also gave me some other ideas – Is this the state of the bug that affects where it is going, “its lifecycle” The way i decide between what should be a flag and what should be a status is the following: Many of the things you describe could be used as part of the status workflow.Īs 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.

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. Man, do I wish I could flags bugs this way. You can follow any responses to this entry through the RSS 2.0 feed.īoth comments and pings are currently closed.įrom all my experience with gtd, this is the best proposal to advance things for Mozilla since a long time. On Monday, April 20th, 2009 at 11:18 am and is filed under Bug tracking, GTD, Mozilla. It would also make our process more transparent: there is always a first-level answer to 'Why hasn't this bug been fixed yet?'

Many comments that are only temporarily meaningful.

Status whiteboard markers like '' and 'DUPEME'.

Eleven keywords: uiwanted, qawanted, helpwanted, stackwanted, icon, testtracker, crashreportid, regressionwindow-wanted, testcase-wanted, checkin-needed, push-needed.

The current 'assignee' field, which is misleading when the next action required is anything other than 'write a patch' or 'check it in'.The current 'status' field, which is mostly useless because each open state (unconfirmed / new / reopened / assigned) can mean so many different things.The 'next action' field and its assignee would replace: I'm asking for new fields, but I think this will actually make Bugzilla less complicated. What bugs need someone to volunteer to make a reduced testcase?.What have I been asked to do in Bugzilla?.With the addition of a next-action-assignee field, I'd also be able to do searches like: What bugs could benefit from extension-space experimentation?.What bugs are waiting for input from the security team?.

#Bugzilla bug status workflow Patch#

Did Brendan hope to have this patch fuzzed?.

With a next-action field, it would be easier to find places to put my skills to good use: This may be even more important in a community system: who you are is a key context determining whether you can do something. Organizing actions by context lets me remember projects when I can move them forward, rather than when they only increase my anxiety. The 'next action' field answers the question 'what is needed to move this bug forward': All bugs I propose replacing the status field with a next action field, and the assignee field with a next action assignee field. It takes me maybe a minute per bug to determine whether I can help, and this wasted time adds up quickly. Sometimes it's a keyword, sometimes it's a review flag, and sometimes it's the third-to-last comment. I believe Bugzilla's workflow can be improved using one of the central ideas from Getting Things Done, the 'next action'.Ĭurrently, the answer to the question 'what is needed to move this bug forward?' is scattered throughout each bug report.