Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bugzilla workflow proposal: "getting bugs done"

8 views
Skip to first unread message

Jesse Ruderman

unread,
Apr 20, 2009, 2:28:02 PM4/20/09
to
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.

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 answer the question "what is needed to move this bug forward?".


Read more: http://www.squarefree.com/2009/04/20/getting-bugs-done/

Boris Zbarsky

unread,
Apr 20, 2009, 3:11:52 PM4/20/09
to
Jesse Ruderman wrote:
> 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 answer the question "what is needed to move this bug forward?".

This was recently proposed in .governance. How does this work when
multiple things that can happen in parallel need to happen "next" (e.g.
reviews)?

-Boris

Jesse Ruderman

unread,
Apr 20, 2009, 4:10:00 PM4/20/09
to
On Apr 20, 12:11 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Jesse Ruderman wrote:
> > 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 answer the question "what is needed to move this bug forward?".
>
> This was recently proposed in .governance.  

Can you point me to the earlier proposal? I'm having trouble finding
it.

> How does this work when
> multiple things that can happen in parallel need to happen "next" (e.g.
> reviews)?

We'll probably need a way to have multiple next-actions, and be
careful not to abuse it. "Currently actionable actions"? ;)

Boris Zbarsky

unread,
Apr 20, 2009, 5:22:21 PM4/20/09
to
Jesse Ruderman wrote:
> Can you point me to the earlier proposal? I'm having trouble finding
> it.

It's in the "Re: Moving patches from posted-to-bug to in-the-tree: a
process discussion" thread. In particular, the "3/30/09 9:28 AM"
message from "mkristo...@mozilla.com".

-Boris

Mike Connor

unread,
Apr 20, 2009, 6:30:36 PM4/20/09
to Jesse Ruderman, dev-pl...@lists.mozilla.org

So, I think this is useful as a concept. Aside from the multiple next
actions piece, we can actually do most of this today, especially with
the status changes I've proposed previously, if we get more
comfortable with assigning bugs to the person or group which is
blocking forward progress. Needs some more generic group-like
assignees, but those are trivial to add.

For your examples from your blog post:

• Did Brendan hope to have this patch fuzzed?

assigned-to fuzzer...@mozilla.bugs

• What bugs are waiting for input from the security team?

assigned-to securi...@mozilla.bugs

• What bugs could benefit from extension-space experimentation?

assigned-to explorati...@mozilla.bugs


IMO, aside from the patch review cases (which are already equally
queryable, just not as obvious in buglists) this is mostly viable
simply by using the assignee field for more than just the developer
who's going to fix the bug. In some cases this will be a team, in
others this will be individuals, but we should really just start
assigning bugs based on who needs to do the next action. If you have
a bug to fix, a patch to fuzz, and a testcase to reduce, the
absolutely critical piece is identifying that you own the next
action. Actually having a crisp status accompanying that assignment
is a bonus, but isn't the biggest win, IMO.

-- Mike

-- Mike

Boris Zbarsky

unread,
Apr 20, 2009, 9:47:08 PM4/20/09
to
Mike Connor wrote:
> • Did Brendan hope to have this patch fuzzed?
>
> assigned-to fuzzer...@mozilla.bugs

This could (maybe even should?) be happening in parallel with reviews, I
would think.

> IMO, aside from the patch review cases (which are already equally
> queryable, just not as obvious in buglists) this is mostly viable simply
> by using the assignee field for more than just the developer who's going
> to fix the bug.

In practice this loses track of bugs. Unless the person who's working
on the bug can somehow easily keep track of it?

Put another way, if the bugs I request review on got assigned to the
reviewer, that would significantly reduce my ability to go and hassle
the reviewers every so often, leading to some of the fixes pretty much
never landing...

If we could have multiple assignees or something, such that for each of
them the bug looked like it's something they have to deal with, that
would address all of the above rather neatly...

-Boris

Mike Connor

unread,
Apr 20, 2009, 10:27:09 PM4/20/09
to Boris Zbarsky, dev-pl...@lists.mozilla.org

On 20-Apr-09, at 9:47 PM, Boris Zbarsky wrote:

> Mike Connor wrote:
>> • Did Brendan hope to have this patch fuzzed?
>> assigned-to fuzzer...@mozilla.bugs
>
> This could (maybe even should?) be happening in parallel with
> reviews, I would think.

Possibly, yeah. Not sure it ever does, or if that makes sense as a
part of getting a patch into the tree. Maybe it does.

>> IMO, aside from the patch review cases (which are already equally
>> queryable, just not as obvious in buglists) this is mostly viable
>> simply by using the assignee field for more than just the developer
>> who's going to fix the bug.
>
> In practice this loses track of bugs. Unless the person who's
> working on the bug can somehow easily keep track of it?

Really, it depends on who we're assigning to, and at what point the
developer takes the bug. In cases like "needs module owner decision"
and "needs reduced testcase" it's not obvious that we should assign a
developer until we're through that point.

> Put another way, if the bugs I request review on got assigned to the
> reviewer, that would significantly reduce my ability to go and
> hassle the reviewers every so often, leading to some of the fixes
> pretty much never landing...

I don't think we change the assignee for reviews, in what I'm saying.
I think I mean for the steps before we get into patch/review/land
endgame.

> If we could have multiple assignees or something, such that for each
> of them the bug looked like it's something they have to deal with,
> that would address all of the above rather neatly...

I do agree, though I imagine this is something that will require some
significant development work for Bugzilla, and should be viewed as a
longer-term change (6 months or more to design, implement and test
something that handles this sanely. Look at the per-branch stuff, I
don't see that as especially viable, and there are things we can do in
the meantime within the existing system to improve this for others.

-- Mike

Boris Zbarsky

unread,
Apr 20, 2009, 11:01:39 PM4/20/09
to
Mike Connor wrote:
>> This could (maybe even should?) be happening in parallel with reviews,
>> I would think.
>
> Possibly, yeah. Not sure it ever does, or if that makes sense as a part
> of getting a patch into the tree. Maybe it does.

Depends on the patch. For something that changes fundamental invariants
of existing code (e.g. upvar2, interruptible reflow, reflow branch, that
sort of thing) up-front fuzz-testing is pretty useful, I think. It
certainly caught a number of bugs in the upvar2 and interruptible reflow
cases. Because the issues fuzz testing can bring up here might involve
nontrivial changes to the patch, it's worth doing it before or alongside
review.

In general, post-checkin fuzzing is fine.

>> In practice this loses track of bugs. Unless the person who's working
>> on the bug can somehow easily keep track of it?
>
> Really, it depends on who we're assigning to, and at what point the
> developer takes the bug. In cases like "needs module owner decision"
> and "needs reduced testcase" it's not obvious that we should assign a
> developer until we're through that point.

Agreed. I guess I was focusing on the part that I interact with the
most, which is from the time when someone starts working on a patch
until the last regression is fixed. ;)

> I don't think we change the assignee for reviews, in what I'm saying. I
> think I mean for the steps before we get into patch/review/land endgame.

OK. Makes sense.

>> If we could have multiple assignees or something, such that for each
>> of them the bug looked like it's something they have to deal with,
>> that would address all of the above rather neatly...
>
> I do agree, though I imagine this is something that will require some
> significant development work for Bugzilla, and should be viewed as a
> longer-term change

Yeah, and if we're talking about the part before work on a patch starts
then I don't think it's quite as necessary, if necessary at all.

-Boris

avatr...@gmail.com

unread,
Apr 21, 2009, 4:32:04 AM4/21/09
to
You know, I think this whole thread presupposes that the problem that
Mozilla has with Bugzilla is that bugs don't accurately and simply
reflect what needs to be done next. Is that really the problem? I've
never had that problem. But then again, my project isn't the same size
as Core.

I mean, I'm not saying that bugs accurately and easily reflect what
needs to be done next--they don't, really, unless you read the
comments, as Jesse says. But I think that no matter how easy you make
it to see what's going on with a bug, the biggest problem will still
be getting somebody to triage all of this. Somebody will still have to
read the comments, to set the field, unless they're experts. And if
they're experts, then usually their time is (a) spent on a very
limited set of bugs (b) valuable enough that they shouldn't be doing
triage.

I think that no matter what, it will come down to a people problem,
not a tool problem. Presupposing a dedicated triage team that can
actually SET this field on bugs BEFORE they're looked at by developers
(as most reporters certainly won't know how to set it), then the field
could be useful. But without the manpower, it doesn't seem that likely
to be effective.

Also, the level of granularity of the field means that it's likely to
be wrong on any given bug, as many people will forget to set it to the
correct next value.

All that said, the "next-action" field would be very easy to set up as
two fields once we upgrade bmo to Bugzilla 3.4 (since it supports
custom fields whose list values depend on the value of another field).

-Max

P.S. Do we have any metrics on how many confirmed, non-INVALID bugs
are filed by users new to Bugzilla who use the guided form? And then
how important those bugs end up being? A lot of workflow proposals
become possible when you don't allow public bug reporting, because you
have a much smaller number of incoming reports to deal with. I'm not
saying I'm in favor of disabling public bug reporting (It's fine for
Bugzilla), I'm just curious as to what the actual metrics are.

Jean-Marc Desperrier

unread,
Apr 21, 2009, 12:06:17 PM4/21/09
to
avatr...@gmail.com wrote:
> A lot of workflow proposals
> become possible when you don't allow public bug reporting, because you
> have a much smaller number of incoming reports to deal with

It's a long, long time since I'd thought the process would work much
better by having bugs reporter post their bug to a newsgroup, and bugs
be inserted inside bugzilla only after they have been streamlined.

My FAI has a support canal that works this way, it's every effective
because problem reporter naturally end up helping each other for simple
problems, as well as all the early, obvious steps of analyzing what
happens, and only the real issues need to be handled by the FAI team.

Hendrix fails in this regard, because it doesn't require the reporters
to subscribe to the newsgroup and see the other message, failing the
chance to build such a community.

Jesse Ruderman

unread,
Apr 21, 2009, 1:43:28 PM4/21/09
to
Max --

This proposal won't eliminate the need for our triage team, but it
will make them more effective, because they won't be looking at the
same bugs without changing them over and over. It will be possible
for a set of bugs to "be triaged", which isn't possible now.

John J. Barton

unread,
Apr 22, 2009, 12:04:08 AM4/22/09
to
Jean-Marc Desperrier wrote:
> avatr...@gmail.com wrote:
>> A lot of workflow proposals
>> become possible when you don't allow public bug reporting, because you
>> have a much smaller number of incoming reports to deal with
>
> It's a long, long time since I'd thought the process would work much
> better by having bugs reporter post their bug to a newsgroup, and bugs
> be inserted inside bugzilla only after they have been streamlined.
>
> My FAI has a support canal that works this way, it's every effective
> because problem reporter naturally end up helping each other for simple
> problems, as well as all the early, obvious steps of analyzing what
> happens, and only the real issues need to be handled by the FAI team.

While hardly on the same scale as mozilla, my experience on Firebug has
been similar. Seemingly wacky bug reports slowly evolve, then one day
someone posts just the right info to know the problem. In this regard
bugzilla is a negative: it drains community energy by creating the
illusion that the bug has been reported. In practice bug reports most
end user reports falling in the forest unheard.

jjb

0 new messages