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/
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
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"? ;)
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
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
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 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
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
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.
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.
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.
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