Complete workflow reorganization
Gervase Markham
try and synthesize where we have got to so far. Mike suggested the
following names and states, with other people's suggested names for each
state in brackets afterwards. This fits pretty well with what Max (who
does this for a living) suggested too. I've made a few tweaks and
expanded it a bit.
UNCONFIRMED
Most bugs go into a single bucket, first pass triage makes sure bug
is actually a bug, not an obvious dupe, and can be reproduced. RFEs
will just get confirmed. Trusted contributors bypass this state.
CONFIRMED (OPEN; formerly NEW)
Bugs that need testcases, regression windows, evaluation against
standards, etc. Basically "yes, this is bug, but it's not clear
whether/how to fix it".
READYTOFIX (READY)
Bugs that have the requirements in place to start work.
INPROGRESS (ACCEPTED, FIXINPROGRESS; created by renaming ASSIGNED)
The bug owner is working on a fix.
RESOLVED
The fix has landed.
VERIFIED
QA has confirmed that the fix has solved the problem.
We also currently have a CLOSED state. Hardly anyone uses it - only 1629
bugs (0.3%), and none in the most recent 150,000, are in that state. We
should move them all back to VERIFIED and eliminate it, along with
REOPENED.
Transitions: transition between all states would be allowed, with the
exception that VERIFIED can only be reached from RESOLVED, and
INPROGRESS and READYTOFIX can't go (directly) back to UNCONFIRMED.
An additional option would be to start using underscores - READY_TO_FIX,
IN_PROGRESS - for readability.
Gerv
Gervase Markham
> READYTOFIX (READY)
> Bugs that have the requirements in place to start work.
>
> INPROGRESS (ACCEPTED, FIXINPROGRESS; created by renaming ASSIGNED)
> The bug owner is working on a fix.
My concern with having both of these states is that we've reproduced,
under another name, the has-an-assignee/is-in-an-assigned-state
repetition. Or to put it another way, what does it mean if a bug is
READY but has an assignee, or INPROGRESS but does not have one?
Should these two states be merged?
Other than that, I think the proposal is excellent. :-P
Gerv
Gervase Markham
> bugs (0.3%), and none in the most recent 150,000, are in that state. We
> should move them all back to VERIFIED and eliminate it, along with
> REOPENED.
Ah - just noticed that it's disabled (in that no transitions to it are
valid) on b.m.o. anyway. I don't know if it's still worth removing it.
And perhaps this is the way to eliminate REOPENED.
Gerv
Martijn
> OK, so let's completely rejig the Bugzilla workflow instead :-)) Let me try
> and synthesize where we have got to so far. Mike suggested the following
> names and states, with other people's suggested names for each state in
> brackets afterwards. This fits pretty well with what Max (who does this for
> a living) suggested too. I've made a few tweaks and expanded it a bit.
>
> UNCONFIRMED
> Most bugs go into a single bucket, first pass triage makes sure bug
> is actually a bug, not an obvious dupe, and can be reproduced. RFEs
> will just get confirmed. Trusted contributors bypass this state.
>
> CONFIRMED (OPEN; formerly NEW)
> Bugs that need testcases, regression windows, evaluation against
> standards, etc. Basically "yes, this is bug, but it's not clear
> whether/how to fix it".
That's not my understanding of what the NEW state is. A NEW bug can
very well have a testcase and a regression window, etc.
And it might also be very well known how it should be fixed.
Regards,
Martijn
> READYTOFIX (READY)
> Bugs that have the requirements in place to start work.
> INPROGRESS (ACCEPTED, FIXINPROGRESS; created by renaming ASSIGNED)
> The bug owner is working on a fix.
>
> RESOLVED
> The fix has landed.
>
> VERIFIED
> QA has confirmed that the fix has solved the problem.
>
> We also currently have a CLOSED state. Hardly anyone uses it - only 1629
> bugs (0.3%), and none in the most recent 150,000, are in that state. We
> should move them all back to VERIFIED and eliminate it, along with REOPENED.
>
> Transitions: transition between all states would be allowed, with the
> exception that VERIFIED can only be reached from RESOLVED, and INPROGRESS
> and READYTOFIX can't go (directly) back to UNCONFIRMED.
>
> An additional option would be to start using underscores - READY_TO_FIX,
> IN_PROGRESS - for readability.
>
> Gerv
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Shawn Wilsher
Cheers,
Shawn
Boris Zbarsky
> Does this do away with INCOMPLETE?
I would hope not!
-Boris
GPHemsley
Now I'm happy again. This is precisely what should be done. (Though
the descriptions may be changed, this is the perfect list of
statuses.) I'm not sure about the underscores, but I won't care, as
long as these new names are used.
Is it possible to disable changing the assignee from nobody@ to
something else without changing the status to INPROGRESS? That would
prevent them from going out of sync when somebody changes the
assignee, and would eliminate the need to worry about it.
Also, I agree with the proposal to disable REOPENED in the way that
CLOSED has been. Then you can take your time in transitioning bugs to
the new workflow system.
Gordon
Michael Connor
On 1-Apr-09, at 10:15 AM, Shawn Wilsher wrote:
> Does this do away with INCOMPLETE?
No, that's a resolution, not a status.
-- Mike
AC
> UNCONFIRMED
> Most bugs go into a single bucket, first pass triage makes sure bug
> is actually a bug, not an obvious dupe, and can be reproduced. RFEs
> will just get confirmed. Trusted contributors bypass this state.
>
> CONFIRMED (OPEN; formerly NEW)
> Bugs that need testcases, regression windows, evaluation against
> standards, etc. Basically "yes, this is bug, but it's not clear
> whether/how to fix it".
>
> READYTOFIX (READY)
> Bugs that have the requirements in place to start work.
1. What percentage of bugs require the 'confirm -> ready' step?
Regression windows are only for regression bugs.
(ask with keyword regressionwindow-wanted)
Testcases are primarily for bugs about parsing or displaying user input
files (xul, html, css, ecmascript, etc.); many bugs are not (UX,
performance, etc.). (ask with keyword testcase-wanted)
'evaluation against standards' is primarily for bugs about parsing or
displaying user input files (standard html, css, ecmascript, etc.); many
bugs are not (UX, performance, etc.).
2. Is 'evaluation against standards' usually something that triage/QA
can do, or does it require developer/manager expertise?
(Similarly, in general RESOLVED INVALID is something triage can do, but
only the lead developer/manager can decide RESOLVED WONTFIX.)
3. Can a triager advance a bug straight to 'READYTOFIX' if it doesn't
have any of the above requirements? Would 'canconfirm' privilege
disallow this?
Shawn Wilsher
> Testcases are primarily for bugs about parsing or displaying user input
> files (xul, html, css, ecmascript, etc.); many bugs are not (UX,
> performance, etc.). (ask with keyword testcase-wanted)
automated test. API bugs (which I see a lot of), need these types of tests.
/sdwilsh
Michael Connor
On 1-Apr-09, at 10:07 AM, Martijn wrote:
> On Wed, Apr 1, 2009 at 3:19 PM, Gervase Markham <ge...@mozilla.org>
> wrote:
>> OK, so let's completely rejig the Bugzilla workflow instead :-))
>> Let me try
>> and synthesize where we have got to so far. Mike suggested the
>> following
>> names and states, with other people's suggested names for each
>> state in
>> brackets afterwards. This fits pretty well with what Max (who does
>> this for
>> a living) suggested too. I've made a few tweaks and expanded it a
>> bit.
>>
>> UNCONFIRMED
>> Most bugs go into a single bucket, first pass triage makes sure bug
>> is actually a bug, not an obvious dupe, and can be reproduced. RFEs
>> will just get confirmed. Trusted contributors bypass this state.
>>
>> CONFIRMED (OPEN; formerly NEW)
>> Bugs that need testcases, regression windows, evaluation against
>> standards, etc. Basically "yes, this is bug, but it's not clear
>> whether/how to fix it".
>
> That's not my understanding of what the NEW state is. A NEW bug can
> very well have a testcase and a regression window, etc.
> And it might also be very well known how it should be fixed.
Yes, that's what I meant all those times I said "NEW is overloaded and
should be split up." We're proposing replacing NEW with CONFIRMED and
READYTOFIX because those are two distinct states that currently both
fall under NEW.
-- Mike
Clint Talbert
> We also currently have a CLOSED state. Hardly anyone uses it - only 1629
> bugs (0.3%), and none in the most recent 150,000, are in that state. We
> should move them all back to VERIFIED and eliminate it, along with
> REOPENED.
Ok, maybe I missed it. But what happens when something is RESOLVED (i.e.
the fix has landed) and then we discover that the fix is incorrect
(tests fail or what have you). Then we'd move it to what state?
That's what we would normally use REOPENED for (which is not a good
name), but it seems that we should have a state for "things that were
attempted but failed to work". Or we should at teh very least call out
what that transition looks like.
THanks,
Clint
Mike Shaver
> Ok, maybe I missed it. But what happens when something is RESOLVED (i.e. the
> fix has landed) and then we discover that the fix is incorrect (tests fail
> or what have you). Then we'd move it to what state?
>
> That's what we would normally use REOPENED for (which is not a good name),
> but it seems that we should have a state for "things that were attempted but
> failed to work". Or we should at teh very least call out what that
> transition looks like.
There are lots of bugs that will have things that failed to work, on
the developer's own machine or on the try server or on a parallel
development clone. I don't think that the case where they've been
committed to m-c and then backed out of there warrants a special
state. I think that transition should look like RESOLVED -> NEW with
a comment detailing the reason.
(I also thing that the single-resolved-state pigeonholing hurts us,
but one miracle at a time. :) )
Mike
Stuart Parmenter
>
Hi,
Things like REOPENED are actually pretty useful to tell when a bug
wasn't actually fixed. I strongly suggest sitting down with some of
the people who live in bugzilla daily, doing triage, before making any
changes. Last time people changed bugzilla pretty much all the
changes made bugzilla harder to use for those who used it most.
stuart
Jonathan Watt
> An additional option would be to start using underscores - READY_TO_FIX,
> IN_PROGRESS - for readability.
Please! Anything to make bugzilla look a little more approachable and user
friendly to the newb.
Gervase Markham
> Does this do away with INCOMPLETE?
No. INCOMPLETE is a resolution, not a status.
Gerv
Gervase Markham
> On 4/1/09 6:19 AM, Gervase Markham wrote:
>> We also currently have a CLOSED state. Hardly anyone uses it - only 1629
>> bugs (0.3%), and none in the most recent 150,000, are in that state. We
>> should move them all back to VERIFIED and eliminate it, along with
>> REOPENED.
>
> Ok, maybe I missed it. But what happens when something is RESOLVED (i.e.
> the fix has landed) and then we discover that the fix is incorrect
> (tests fail or what have you). Then we'd move it to what state?
READYTOFIX, presumably. Or, if it turns out the failure is so bad that
it requires an entirely different approach and a total rethink, CONFIRMED.
> That's what we would normally use REOPENED for (which is not a good
> name), but it seems that we should have a state for "things that were
> attempted but failed to work".
Well, we have the "regression" keyword. And normally this sort of bug is
already on someone's radar - the person who tried to fix it first time.
Gerv
Gervase Markham
> Things like REOPENED are actually pretty useful to tell when a bug
> wasn't actually fixed. I strongly suggest sitting down with some of
> the people who live in bugzilla daily, doing triage, before making any
> changes.
That's what we're doing here, isn't it?
I suggested adding a single new state; the impetus to rejig the entire
workflow came from others, notably mconnor.
I agree that people should temper the forcefulness with which they make
their remarks about how the workflow should work based on how much time
they spend working in or with Bugzilla.
> Last time people changed bugzilla
Bugzilla changes all the time. Can you be more specific as to which
change you mean?
> pretty much all the
> changes made bugzilla harder to use for those who used it most.
Could you give examples?
Gerv
Robert Kaiser
> CONFIRMED (OPEN; formerly NEW)
> Bugs that need testcases, regression windows, evaluation against
> standards, etc. Basically "yes, this is bug, but it's not clear
> whether/how to fix it".
>
> READYTOFIX (READY)
> Bugs that have the requirements in place to start work.
I still don't fully grasp the difference between those two for the vast
number of things I'm working on. Would it make sense for CONFIRMED to
actually mean what READYTOFIX means here and instead have a NEEDINFO
state (like Novell/openSUSE have) which is usually set by developers
(potentially also triagers though) who see they need additional info to
be able to work on this?
Robert Kaiser
Martijn
Personally, I find those states confusing and I think it would make
bugzilla look less user friendly.
Or were you talking about the underscores?
Regards,
Martijn
Jonathan Watt
> On Thu, Apr 2, 2009 at 12:49 PM, Jonathan Watt <jw...@jwatt.org> wrote:
>> On 4/1/09 3:19 PM, Gervase Markham wrote:
>>> An additional option would be to start using underscores - READY_TO_FIX,
>>> IN_PROGRESS - for readability.
>> Please! Anything to make bugzilla look a little more approachable and user
>> friendly to the newb.
>
> Personally, I find those states confusing and I think it would make
> bugzilla look less user friendly.
> Or were you talking about the underscores?
I'm talking about the underscores, as was Gerv in that sentence.
Gervase Markham
> On 02/04/09 04:26, Stuart Parmenter wrote:
>> Things like REOPENED are actually pretty useful to tell when a bug
>> wasn't actually fixed. I strongly suggest sitting down with some of
>> the people who live in bugzilla daily, doing triage, before making any
>> changes.
>
> That's what we're doing here, isn't it?
Goodness, that all sounds rather combative, rereading it. Sorry :-)
Let me try again: I certainly hope to make sure that most (or,
hopefully, all) people using bugzilla.mozilla.org regularly think
changes we make are improvements.
Gerv
Gervase Markham
> I still don't fully grasp the difference between those two for the vast
> number of things I'm working on. Would it make sense for CONFIRMED to
> actually mean what READYTOFIX means here and instead have a NEEDINFO
> state (like Novell/openSUSE have) which is usually set by developers
> (potentially also triagers though) who see they need additional info to
> be able to work on this?
I think the difference between the two workflows is the question of on
whom the responsibility seems to fall to investigate whether the bug is
ready.
In the CONFIRMED/READYTOFIX workflow, QA will make sure a CONFIRMED bug
has everything it needs (testcase, steps to reproduce etc.), and then
push it to READYTOFIX for a developer to pick up.
In the CONFIRMED/NEEDINFO workflow, the bug goes straight to CONFIRMED,
and then a developer has to investigate whether they can actually fix it
and, if not, push it back to NEEDINFO for a QA person to handle.
The former puts more work on QA, the latter on developers.
If I'm right, then if we are attempting to optimize for developer time,
we should prefer a workflow which clearly indicates that the former is
what's wanted.
Gerv
Mike Shaver
> Let me try again: I certainly hope to make sure that most (or, hopefully,
> all) people using bugzilla.mozilla.org regularly think changes we make are
> improvements.
What proportion of changes (weight it however you'd like) are
discussed with b.m.o's heaviest users, such as release-drivers and
full-time developers, before implementation in our system?
Mike
Gervase Markham
Let me rephrase and expand upon that slightly :-) The below is not meant
to be patronizing.
Bugzilla is under development; bugzilla.mozilla.org will, from time to
time, upgrade to a more recent version. This upgrade work is done
generally by justdave and mkanat, under the auspices of Mozilla IT, and
has little to do with me. The changes that this process brings with it
may be viewed in different ways by different users. The Mozilla
community can affect these changes before the fact in the normal open
source way, by getting involved in the Bugzilla development process
(filing bugs, giving feedback etc.). Clearly, as a major user of
Bugzilla, Mozilla community feedback is given weight.
But those aren't the changes I meant. Separately from the above,
Bugzilla can be customised on a per-instance basis. Such a change may
well modify or revert a change from the category above ;-) Some of those
customisations and changes come out of processes instigated by me (e.g.
the recent Bugzilla component and product reorganization). If we change
workflow, that would be another change in this category. For such
changes, I personally hope to make sure that all or most b.m.o. users
consider them improvements. Which is what I was trying to say above.
So the answer to your question, for the changes I was talking about, is
100% - if the aforesaid release drivers and full-time developers are
participating in forums such as mozilla.dev.planning. But that's
obviously not all the changes that might be made, so the other answer
would be a lot less than 100%. Many more changes are made by the
Bugzilla development process than are made by our local customizations.
Sorry if I wasn't clear first time.
Gerv
Robert Kaiser
> If I'm right, then if we are attempting to optimize for developer time,
> we should prefer a workflow which clearly indicates that the former is
> what's wanted.
I just think we are living in utopia if we think we have hordes of
people who understand enough to tell if a bug has all info it needs for
fixing but who are not developers of some kind themselves.
Robert Kaiser
Simon Paquet
> UNCONFIRMED
> Most bugs go into a single bucket, first pass triage makes sure bug
> is actually a bug, not an obvious dupe, and can be reproduced. RFEs
> will just get confirmed. Trusted contributors bypass this state.
>
> CONFIRMED (OPEN; formerly NEW)
> Bugs that need testcases, regression windows, evaluation against
> standards, etc. Basically "yes, this is bug, but it's not clear
> whether/how to fix it".
Agreed.
> READYTOFIX (READY)
> Bugs that have the requirements in place to start work.
>
> INPROGRESS (ACCEPTED, FIXINPROGRESS; created by renaming ASSIGNED)
> The bug owner is working on a fix.
I see two problems with those:
1. No person that is solely working on QA (and therefore not a
developer) can honestly tell in most cases whether a bug is
READYTOFIX or not. So this bug state is entirely useless for most
of the people doing serious triaging work in bugzilla.
2. I see no additional benefit of the INPROGRESS state compared to a
confirmed bug with a bug assignee other than nobody@m.o. Instead
of artificially showing people some progress where there may be none,
be should instead do a better job of cleaning up bug assignees, who
haven't been actively working on the bugs that they are assigned on.
For example, we could do a mass-reassignment of bugs to nobody@m.o
where the bug was assigned to a person more than 6-12 months ago and
it still hasn't been fixed.
Bottom-line: Just having two states for open bugs (UNCONFIRMED and
CONFIRMED) would simplify things without losing us anything.
> We also currently have a CLOSED state. Hardly anyone uses it - only
> 1629 bugs (0.3%), and none in the most recent 150,000, are in that
> state.
That is, because the use of CLOSED was disabled a few years ago. So
this would be the natural followup step. Thumbs up!
Cya
Simon
PS: We should really try to get more QA people (especially people
who are helping out with bug triaging and other QA stuff in their
free time, during bugdays, etc.) involved in this thread. Currently
this thread is way too developer- and MoCo-centric (from a
participation POV) to be of any significant use for the larger
Mozilla world.
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Jean-Marc Desperrier
> For example, we could do a mass-reassignment of bugs to nobody@m.o
> where the bug was assigned to a person more than 6-12 months ago and
> it still hasn't been fixed.
And there has been no comments on the bug from the developer since more
than 4-6 months, or else there would be quite a few false positives.
The reassignment should add a comment on the bug too.
AC
> 2. I see no additional benefit of the INPROGRESS state compared to a
> confirmed bug with a bug assignee other than nobody@m.o. Instead
> of artificially showing people some progress where there may be none,
> be should instead do a better job of cleaning up bug assignees, who
> haven't been actively working on the bugs that they are assigned on.
> For example, we could do a mass-reassignment of bugs to nobody@m.o
> where the bug was assigned to a person more than 6-12 months ago and
> it still hasn't been fixed.
Maybe renaming ASSIGNED to FIXINPROGRESS will discourage people from
changing the state until they submit the first patch. Currently it is
too easy to conclude that they should change the state to ASSIGNED if
the assignee is not 'nobody'. (Though, if "wait until have patch" is
the desired behavior to discourage postponed/abandoned bugs in
FIXINPROGRESS state, then something like PATCHINHAND might be a better
name.)
Robert Kaiser
> 1. No person that is solely working on QA (and therefore not a
> developer) can honestly tell in most cases whether a bug is
> READYTOFIX or not. So this bug state is entirely useless for most
> of the people doing serious triaging work in bugzilla.
I agree with that.
> 2. I see no additional benefit of the INPROGRESS state compared to a
> confirmed bug with a bug assignee other than nobody@m.o. Instead
> of artificially showing people some progress where there may be none,
> be should instead do a better job of cleaning up bug assignees, who
> haven't been actively working on the bugs that they are assigned on.
> For example, we could do a mass-reassignment of bugs to nobody@m.o
> where the bug was assigned to a person more than 6-12 months ago and
> it still hasn't been fixed.
I don't agree here. There a difference between "I'm assigning this to me
because I want to take care about this when I find the time at some
point" and "I have actually started working on this, just not
finished/tested a/the patch yet". Of course, once there is a patch and a
request for review there, it obviously is in progress, no matter what
the officially marked state is.
Robert Kaiser
Gervase Markham
> I just think we are living in utopia if we think we have hordes of
> people who understand enough to tell if a bug has all info it needs for
> fixing but who are not developers of some kind themselves.
I would hope QA people would be able to determine this to a reasonable
level of accuracy. Of course, it depends what you mean by "ready" - is a
bug ready to fix unless someone's found which line of code is the
problem? In one sense, no. Perhaps READY_FOR_DEVELOPER_TO_WORK_ON would
be more accurate, but it's also much longer.
Gerv
Gervase Markham
> Maybe renaming ASSIGNED to FIXINPROGRESS will discourage people from
> changing the state until they submit the first patch. Currently it is
> too easy to conclude that they should change the state to ASSIGNED if
> the assignee is not 'nobody'. (Though, if "wait until have patch" is the
> desired behavior to discourage postponed/abandoned bugs in FIXINPROGRESS
> state, then something like PATCHINHAND might be a better name.)
Not all bugs, that is to say things tracked by Bugzilla, are fixed by
patches.
Gerv
Gervase Markham
> I don't agree here. There a difference between "I'm assigning this to me
> because I want to take care about this when I find the time at some
> point"
And I think there's a strong argument that "I want to take care about
this when I find the time at some point" is a really bad reason for
assigning a bug to yourself. That is to say, you should use one of the
many other methods of marking or tracking bugs (personal tags, keeping
one of the bugmails in a "to fix" folder, whatever) to keep an eye on
bugs like this. If you assign it to yourself, someone who might want to
fix it _now_ may erroneously assume you are working on it in the short term.
Gerv
Michael Connor
On 3-Apr-09, at 4:21 AM, Simon Paquet wrote:
>> READYTOFIX (READY)
>> Bugs that have the requirements in place to start work.
>> INPROGRESS (ACCEPTED, FIXINPROGRESS; created by renaming ASSIGNED)
>> The bug owner is working on a fix.
>
> I see two problems with those:
>
> 1. No person that is solely working on QA (and therefore not a
> developer) can honestly tell in most cases whether a bug is
> READYTOFIX or not. So this bug state is entirely useless for most
> of the people doing serious triaging work in bugzilla.
It depends on what your definition of "serious triaging" means here.
There will certainly be a class of people who will never use it,
because they don't have the QA skills to create minimized testcases,
etc. That's totally fine, and part of my explicit reasoning for
splitting NEW into two states was to separate triage and "pure" QA.
There will be a mix of QA/developer/designer triage on CONFIRMED bugs,
and pure triagers who are non-technical will skew towards the triage
tasks, for sure, but that's the goal.
-- Mike
avatr...@gmail.com
> I would hope QA people would be able to determine this to a reasonable
> level of accuracy. Of course, it depends what you mean by "ready" - is a
> bug ready to fix unless someone's found which line of code is the
> problem? In one sense, no. Perhaps READY_FOR_DEVELOPER_TO_WORK_ON would
> be more accurate, but it's also much longer.
This is why I originally suggested CAUSE_KNOWN instead of
READY_TO_FIX. CAUSE_KNOWN has a very clear meaning. Of course, it may
not be the same meaning that you want for READY_TO_FIX.
-Max
Michael Connor
CAUSE_KNOWN certainly doesn't apply to UX enhancements. Pretty sure I
considered that way way back.
-- Mike
Diederik
I have constructed a dataset of 50.000+ Firefox bugs over the timespan
1998 - 2008 (including all bug characteristics such as life cycle,
quality of initial report, centrality in bug dependency network etc.
etc) to study which factors shorten / lengthen the time needed to
resolve a bug. As you are discussing the possibility of changing the
bug resolution workflow, it might be helpful to have some statistics
on current practices. Of course, I am well aware that you already have
plenty of statistics on a more aggregated level but I could be of
help. My background: I am a post-doc researcher at the University of
Toronto and studying social networks. I would like to make my research
relevant to the community from which I am drawing my data so that this
research will not only be published in an academic journal but maybe
can help you in improving the bug resolution process.
Best,
-- Diederik
Ria
Maybe the term QA_DONE tells more explicitly that no further
pretreatments are needed?
Although the Keywords fields and the Whiteboard should already contain
this information. But the same goes for READY_TO_FIX.
READY_TO_FIX may lead to false expectations of impatient people while
QA_DONE doesn't have this problem.
Ria
and only when it has sufficient data to be fixed, to call it NEW.
So an extra status between UNCONFIRMED and NEW. This way people won't
get illusions when they receive an e-mail with the status change.
Robert Kaiser
> Maybe the term QA_DONE tells more explicitly that no further
> pretreatments are needed?
> Although the Keywords fields and the Whiteboard should already contain
> this information. But the same goes for READY_TO_FIX.
> READY_TO_FIX may lead to false expectations of impatient people while
> QA_DONE doesn't have this problem.
The problem I'm seeing is that I don't believe it makes sense for the
vast amount of bugs not to be QA_DONE/READY_TO_FIX immediately after
being either confirmed or filed by someone with sufficient permissions.
I seriously think that in most cases it will need a look of someone who
understands the code (and who would be able to work on it) to tell if
the info is sufficient or if it needs more info, and that's why I grow
more and more convinced that NEEDINFO is a better model.
Of course, people who triage UNCONFIRMED would still be able to go and
set them to NEEDINFO instead of CONFIRMED but I don't see the value of
the other model regarding every CONFIRMED bug as one that needs more
info before it can be fixed.
Robert Kaiser
Michael Connor
On 4-Apr-09, at 6:55 AM, Ria wrote:
> On Apr 3, 10:32 pm, avatrax...@gmail.com wrote:
>> On Apr 3, 5:50 am, Gervase Markham <g...@mozilla.org> wrote:
>>
>>> I would hope QA people would be able to determine this to a
>>> reasonable
>>> level of accuracy. Of course, it depends what you mean by "ready"
>>> - is a
>>> bug ready to fix unless someone's found which line of code is the
>>> problem? In one sense, no. Perhaps READY_FOR_DEVELOPER_TO_WORK_ON
>>> would
>>> be more accurate, but it's also much longer.
>>
>> This is why I originally suggested CAUSE_KNOWN instead of
>> READY_TO_FIX. CAUSE_KNOWN has a very clear meaning. Of course, it may
>> not be the same meaning that you want for READY_TO_FIX.
>>
>> -Max
>
> Maybe the term QA_DONE tells more explicitly that no further
> pretreatments are needed?
QA_DONE assumes this is only a QA state. That's not the expectation,
it's more general-case than that, see my comments around UX design etc.
> Although the Keywords fields and the Whiteboard should already contain
> this information. But the same goes for READY_TO_FIX.
> READY_TO_FIX may lead to false expectations of impatient people while
> QA_DONE doesn't have this problem.
I don't think status will affect impatient people.
-- Mike
Michael Connor
On 4-Apr-09, at 12:19 PM, Robert Kaiser wrote:
> Ria wrote:
>> Maybe the term QA_DONE tells more explicitly that no further
>> pretreatments are needed?
>> Although the Keywords fields and the Whiteboard should already
>> contain
>> this information. But the same goes for READY_TO_FIX.
>> READY_TO_FIX may lead to false expectations of impatient people while
>> QA_DONE doesn't have this problem.
>
> The problem I'm seeing is that I don't believe it makes sense for
> the vast amount of bugs not to be QA_DONE/READY_TO_FIX immediately
> after being either confirmed or filed by someone with sufficient
> permissions.
People will be able to file directly as READYTOFIX, if they have
privs. But I sure can't reasonably file a layout or DOM bug that's
"READYTOFIX" in most cases. I think I trust myself to file a bug into
the right component. Overloading a single status means a reliance on
secondary notations that add complexity and confusion. If we can only
rely on keywords/whiteboard, we're not saving complexity, we're adding
it.
> I seriously think that in most cases it will need a look of someone
> who understands the code (and who would be able to work on it) to
> tell if the info is sufficient or if it needs more info, and that's
> why I grow more and more convinced that NEEDINFO is a better model.
A developer isn't needed to:
* minimize testcases
* find regression windows
* assess RFEs
* clarify and simplify STR
which is what I expect and want to see happen. You're letting perfect
be the enemy of good here. If a core developer is finding a
regression window themselves, that's probably not the best use of
their time.
Remember that one of the goals is to reduce the overhead on initial
triage. This means confirmation is a lower bar (can reproduce the
bug, not obviously a dupe) and much of the current notion of "triage"
covers CONFIRMED -> READYTOFIX, instead of being conflated with the
first part as with the current UNCO -> NEW transition. If it helps
your mental model, under how many people triage now READYTOFIX is very
similar to how most components use NEW today. We're just splitting it
into two stages, since it makes sense to focus the time of QA on the
set of bugs we can actually reproduce...
(Yes, this means "QA" and "triage" are no longer lumped together. I
think that's a good thing, and provides for a better on-ramp to
contribution.)
> Of course, people who triage UNCONFIRMED would still be able to go
> and set them to NEEDINFO instead of CONFIRMED but I don't see the
> value of the other model regarding every CONFIRMED bug as one that
> needs more info before it can be fixed.
If a bug is READYTOFIX, we should triage it as such. I think people
are overrotating on "how ready is ready?" The objective is to change
the process to maximize developer productivity, by explicitly
separating bugs that have been QAed from the bugs that need QA
attention.
-- Mike
AC
> Gervase Markham wrote:
>> UNCONFIRMED
>> Most bugs go into a single bucket, first pass triage makes sure bug
>> is actually a bug, not an obvious dupe, and can be reproduced. RFEs
>> will just get confirmed. Trusted contributors bypass this state.
>>
>> CONFIRMED (OPEN; formerly NEW)
>> Bugs that need testcases, regression windows, evaluation against
>> standards, etc. Basically "yes, this is bug, but it's not clear
>> whether/how to fix it".
>>
>> Bugs that have the requirements in place to start work.
>
Some quick bugzilla report numbers.
Supposing 'regression' keyword marks bugs which need regression window,
and 'testcase' keyword or 'in-testsuite+' flag marks bugs for which a
testcase was written either before or after the patch (so a testcase was
possible and practical), querying bugzilla produces the following results:
Of 1672 FIXED bugs modified in past WEEK,
153 (9.1%) have 'regression' keyword
112 (6.7%) have 'testcase' keyword
238 (14.%) have 'in-testsuite+' flag
- 48 have 'regression' and 'testcase'
- 42 have 'regression' and 'in-testsuite+'
+ 24 have 'regression' and 'testcase' and 'in-testsuite+'
------
437 (26.%) have 'regression' and/or 'testcase' and/or 'in-testsuite+'
Of 49004 FIXED bugs modified in past YEAR,
4474 (9.1%) have 'regression' keyword
2171 (4.4%) have 'testcase' keyword
2650 (5.4%) have 'in-testsuite+' flag
- 771 have 'regression' and 'testcase'
- 591 have 'regression' and 'in-testsuite+'
+ 353 have 'regression' and 'testcase' and 'in-testsuite+'
-----
8286 (17%) have 'regression' and/or 'testcase' and/or 'in-testsuite+'
By this measure, it looks like about 1/6 to 1/4 bugs might have used the
workflow
UNCONFIRMED -> CONFIRMED -> READYTOFIX -> FIXINPROGRESS
For the rest, the extra step may have no benefit, so the workflow
UNCONFIRMED -> CONFIRMED -> FIXINPROGRESS
may be sufficient.
(If someone has a better way to estimate the fraction of bugs where the
confirm->ready transition is a useful step, please propose it.)
Testcases are not used uniformly across all components. Rather than
impose an extra step across all components, maybe the 'readytofix' state
would be optional, only used by those component teams that want it, and
have people able and willing to take the test-writing role.
- Developers in teams which use the 'ready' state would assign
themselves bugs from the 'readytofix' state.
- People working with components which do not use the 'ready' state
would assign themselves bugs directly from the 'confirmed' state. (Can
bugzilla document or restrict states available for a component?)
(Another alternative has been proposed:
UNCONFIRMED -> CONFIRMED -> NEEDINFO -> CONFIRMED -> FIXINPROGRESS.
This has the problem that, for component teams who do have test-writers,
it is not obvious whether a bug in 'confirmed' state is before or after
the testwriting 'needs-info' state. In this case developers might still
have to query with the 'testcase' keyword anyway, so the needinfo state
doesn't help developers query. It may be slightly easier for a
developer to select the needinfo state rather than typing the
'testcase-wanted' keyword, but they still have to specify what info they
need, so again the benefit to developers is not clear. For test
writers, it may be slightly easier to select 'needsinfo' rather than
select 'any' and type 'testcase-wanted', 'regressionwindow-wanted' for a
query, but for common queries the query is only set up once and saved.)
Boris Zbarsky
> Supposing 'regression' keyword marks bugs which need regression window,
> and 'testcase' keyword or 'in-testsuite+' flag marks bugs for which a
> testcase was written either before or after the patch (so a testcase was
> possible and practical), querying bugzilla produces the following results:
I'd be interested in two things here:
1) What if you also count bugs with "in-testsuite?" as bugs that could
have testcases (even if they can't be automated yet)?
2) How does this breakdown look by product (e.g. for Core and Firefox)?
> Testcases are not used uniformly across all components.
Indeed; hence question 2 above.
-Boris
Michael Connor
Even more important, there's a number of bugs that have testcases, but
don't have the testcase keyword, so we're talking a floor, and the
ceiling is higher.
So, starting with Core/Toolkit/Firefox (which is 50% of bugzilla by
volume, with ops/releng/website bugs making up another 35% or so):
First, I only counted bugs actually marked FIXED in the last 30 days,
not just "touched":
This is 708 bugs (there's some security bugs in there that haven't
been opened yet.
Taking bugs with in-testsuite +/?, testcase, and regression
That's 266, or about 37.5%, just using the AC's approach.
There's certainly a lot of bugs that will exist in bmo that won't
benefit from READYTOFIX. That's fine, it's not required, and
shouldn't impose a requirement on any project. I'm seeing lots of
"but we don't need it" comments, but I don't think anyone's really
describing how it will hurt the cases where people don't need it, or
why the benefits aren't there for the projects that will greatly
benefit from a more obvious workflow.
-- Mike
Ria
doubt about that.
The problem I'm having with the new status is the name READYTOFIX. It
raises expectations.
READYTOFIX inplies that work has been done (READY) and that the bug
will be fixed soon (READYTOFIX). So it's only a matter of time and all
the hard work of filing his bug and making his testcase will be
rewarded. The bug will be fixed. No need to fix his website or to
adjust his extension. So the reporter will start waiting, and there's
a big chance, in vain, but he doesn't know yet.
All this happened because the bug had to much info to stay in the
CONFIRMED box. There was a testcase, the cause was clear; it was
really a bug. Developers confirmed that the bug was not intentional.
Maybe it will be fixed before the next release. Then after a half year
of waiting another developer takes another look and finds it not a
good idea to fix it, but maybe it will be fixed the next following
release.
So I'd still vote for another, more neutral status name which
expresses the state (it is a bug, all info is present to fix it but
not sure yet if it will be fixed), and keep READYTOFIX for bugs which
definitely will be fixed.
timeless
Robert Kaiser
> Remember that one of the goals is to reduce the overhead on initial
> triage. This means confirmation is a lower bar (can reproduce the bug,
> not obviously a dupe) and much of the current notion of "triage" covers
> CONFIRMED -> READYTOFIX, instead of being conflated with the first part
> as with the current UNCO -> NEW transition. If it helps your mental
> model, under how many people triage now READYTOFIX is very similar to
> how most components use NEW today. We're just splitting it into two
> stages, since it makes sense to focus the time of QA on the set of bugs
> we can actually reproduce...
>
> (Yes, this means "QA" and "triage" are no longer lumped together. I
> think that's a good thing, and provides for a better on-ramp to
> contribution.)
It's becoming clear here that we are sitting in different corners of the
project and therefore Bugzilla. ;-)
In my corner, people who do triage and QA are even more sparse than the
already sparse volunteer development force, and often people are doing
all three of those just so that we get progress on all fronts. That of
course makes the lines between the things you describe very unclear from
the beginning.
If a majority of the project has good enough triage _and_ QA forces
separate from people who actually work on code, then it surely makes
sense to take that into account when redesigning the Bugzilla process.
Robert Kaiser
Philip Chee
> NEEDSENGINEER
[OT] NEEDSBOBTHEBUILDER
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
AC
The 'pre' part associates it with beginnings, not endings.
Being prepared for disaster doesn't mean disaster will happen.
Being prepared to answer a question doesn't mean it will be asked.
Being prepared for FIXING doesn't mean fixing will happen.
(FIXING could be a shorter name for FIXINPROGRESS)
In contrast, 'ready' is used more often at endings.
After a repair, say "your car is ready", not "your car is prepared".
It is ready for pickup, and pickup almost always happens.
UNCONFIRMED->CONFIRMED->PREPARED->FIXING->RESOLVED:FIXED->VERIFIED
Michael Connor
Yes, absolutely. I think I spoke to that earlier in one of these
threads, where I said that small projects with a handful of people
wouldn't really benefit from anything finer-grained than open/closed.
Even UNCO isn't especially useful if single people are doing triage/QA/
bugfixing by themselves.
> If a majority of the project has good enough triage _and_ QA forces
> separate from people who actually work on code, then it surely makes
> sense to take that into account when redesigning the Bugzilla process.
Right now, Core/Toolkit/Firefox make up about 50% of bug volume.
Website and IT components make up another 30%, so all of the remaining
projects are splitting up 20% of volume. Of course, the key thing is,
projects like Seamonkey can ignore READYTOFIX at their leisure. It
isn't _required_ but it is significantly beneficial for a lot of our
bugs.
-- Mike
Michael Connor
On 5-Apr-09, at 5:14 AM, Ria wrote:
> There's definitely a status needed between UNCONFIRMED and NEW; no
> doubt about that.
> The problem I'm having with the new status is the name READYTOFIX. It
> raises expectations.
The reality is that if people are frustrated by a bug, they'll
continue to be frustrated until it's fixed. Regardless of what stage
the bug is at. I've been getting "how the hell is this not
fixed?!?!?!" bugmails for six years, I don't think this will result in
any significant change in expectations.
I'm also not really interested in trying to manage end-user
expectations at the expense of having a level of abstraction in how we
describe the status of a bug. Massaging the truth (we have what we
need to try to fix the bug, but we haven't done it yet) will not
change the end result, which is that the bug isn't fixed yet.
-- Mike
GPHemsley
This sounds like an excellent idea. Someone is actually thinking about
the issue at hand instead of coming up with new issues. Well done.
Gervase Markham
> I have constructed a dataset of 50.000+ Firefox bugs over the timespan
> 1998 - 2008 (including all bug characteristics such as life cycle,
> quality of initial report, centrality in bug dependency network etc.
> etc) to study which factors shorten / lengthen the time needed to
> resolve a bug.
Hi Diederik,
Thank you very much for your offer. We would be very interested in your
help. I've commented on your initial statistics at another point in the
thread, suggesting ways you can make them more useful. I look forward to
seeing the update :-)
Gerv
fantasai
>
> 'evaluation against standards' is primarily for bugs about parsing or
> displaying user input files (standard html, css, ecmascript, etc.); many
> bugs are not (UX, performance, etc.).
>
> 2. Is 'evaluation against standards' usually something that triage/QA
> can do, or does it require developer/manager expertise?
Depends on the QA person and the trickiness of the evaluation.
We have had QA people specializing in this kind of thing, and
their evaluation would be as competent if not better than the
relevant developer/manager.
~fantasai
Frédéric Buclin
>> UNCONFIRMED->CONFIRMED->PREPARED->FIXING->RESOLVED:FIXED->VERIFIED
I stopped reading all comments for several days now, but I much prefer
IN_PROGRESS than FIXING. FIXING makes me thing something is broken, and
you don't always fix things.
LpSolit
avatr...@gmail.com
> Yes, absolutely. I think I spoke to that earlier in one of these
> threads, where I said that small projects with a handful of people
> wouldn't really benefit from anything finer-grained than open/closed.
> Even UNCO isn't especially useful if single people are doing triage/QA/
> bugfixing by themselves.
I do a lot of work for one of those smaller projects (Bugzilla), and
it wouldn't bother me to have READYTOFIX in there at all.
-Max
Ria
I agree fully. When a bug is READYTOFIX, fixing the bug is the next
expected action, while this is not at all what necessarily will
happen.
Michael Connor
It's not? What other actions are you expecting here?
-- Mike
Ria
> On 5-Apr-09, at 5:14 AM, Ria wrote:
>
> > There's definitely a status needed between UNCONFIRMED and NEW; no
> > doubt about that.
> > The problem I'm having with the new status is the name READYTOFIX. It
> > raises expectations.
>
> The reality is that if people are frustrated by a bug, they'll
> continue to be frustrated until it's fixed. Regardless of what stage
> the bug is at. I've been getting "how the hell is this not
> fixed?!?!?!" bugmails for six years, I don't think this will result in
> any significant change in expectations.
>
It's always nice if people can control themselves and behave, but
really problematic would it be if no-one cared.
Michael Connor
On 6-Apr-09, at 1:43 PM, Ria wrote:
> On Apr 5, 8:21 pm, Michael Connor <mcon...@mozilla.com> wrote:
>> On 5-Apr-09, at 5:14 AM, Ria wrote:
>>
>>> There's definitely a status needed between UNCONFIRMED and NEW; no
>>> doubt about that.
>>> The problem I'm having with the new status is the name READYTOFIX.
>>> It
>>> raises expectations.
>>
>> The reality is that if people are frustrated by a bug, they'll
>> continue to be frustrated until it's fixed. Regardless of what stage
>> the bug is at. I've been getting "how the hell is this not
>> fixed?!?!?!" bugmails for six years, I don't think this will result
>> in
>> any significant change in expectations.
>
> It's always nice if people can control themselves and behave, but
> really problematic would it be if no-one cared.
Not arguing that at all. I'm simply saying that people will be
frustrated by any status other than "RESOLVED FIXED, and backported to
current stable" so we shouldn't over-rotate on whether any particular
status name will inflame the situation.
-- Mike
Ria
Other possibilies: delay, setback, lack of time, lack of knowledge,
change of judgement, other unforeseen problems, change of goal,
obsolescense -> cancellation.
Ria
For a large part Mozilla relies on feedback of the public. This is
even largely the reason of the browser's success. Just like you people
don't want to waste their time and want information as realistic as
possible.
Michael Connor
On 6-Apr-09, at 3:37 PM, Ria wrote:
>>> I agree fully. When a bug is READYTOFIX, fixing the bug is the next
>>> expected action, while this is not at all what necessarily will
>>> happen.
>>
>> It's not? What other actions are you expecting here?
>>
>> -- Mike
>
> Other possibilies: delay, setback, lack of time, lack of knowledge,
> change of judgement, other unforeseen problems, change of goal,
> obsolescense -> cancellation.
Okay, so how does PREPARED change this?
If we have a status which means in general that the next step is to
fix it, whether we are explicit or obfuscate that, anyone with a
minimum of awareness will feel jerked around if we WONTFIX or
deprioritize. My primary argument is that if the reality of the bug
is the same, mitigation of this isn't worth the loss of clarity of
status. A bug that makes it to READYTOFIX should be something we want
to fix (i.e. it's a real bug or and it's an RFE that the module owner
has approved), so obscuring the actual state feels like we're being
less than honest.
I respect that you're trying to mitigate negative reactions, but I
honestly don't believe that the naming choice will have any impact on
these reactions.
-- Mike
Ria
The assumption that READYTOFIX gives the most clarity is wrong,
because it contains a promise or at least an announcement (to fix the
bug) which in many cases can't be fulfilled.
PREPARED gives the same certainty that everything needed has been done
so that the bug can proceed, but the word contains only a possibility
but no obligation, that the bug will be fixed.
And that is the reality. It's not more than that.
Michael Connor
> The assumption that READYTOFIX gives the most clarity is wrong,
> because it contains a promise or at least an announcement (to fix the
> bug) which in many cases can't be fulfilled.
> PREPARED gives the same certainty that everything needed has been done
> so that the bug can proceed, but the word contains only a possibility
> but no obligation, that the bug will be fixed.
> And that is the reality. It's not more than that.
I don't read any promise or announcement into something being ready to
be fixed.
If dinner is ready, or dinner has been prepared, those both mean "I
can eat now."
I think these are semantically equivalent, except that PREPARED has
the same imprecision that made READY not quite good enough. (PREPARED
for what?)
-- Mike
Ria
> On 6-Apr-09, at 5:38 PM, Ria wrote:
>
> > The assumption that READYTOFIX gives the most clarity is wrong,
> > because it contains a promise or at least an announcement (to fix the
> > bug) which in many cases can't be fulfilled.
> > PREPARED gives the same certainty that everything needed has been done
> > so that the bug can proceed, but the word contains only a possibility
> > but no obligation, that the bug will be fixed.
> > And that is the reality. It's not more than that.
>
> I don't read any promise or announcement into something being ready to
> be fixed.
>
> If dinner is ready, or dinner has been prepared, those both mean "I
> can eat now."
>
> I think these are semantically equivalent,
No, not equivalent. Dinner ready means mostly that it will soon be
served, dinner prepared had another meaning and connotation; the
prepared food can also be divided into portions and put into the
freezer, or given to the birds outside. In case the birds were
impatiently waiting outside for the food that you were preparing for
them, ready is more appropriate I think.
> except that PREPARED has
> the same imprecision that made READY not quite good enough. (PREPARED
> for what?)
>
> -- Mike
I really think PREPARED is the best status name proposal until now,
and if Mozilla were a democracy, I'd vote for it.
Ria
maybe a layer of QA people who do this for them. Would cost something
I think, for at least one, two or even more people would have a
fulltime job testing all those bugs and hearing those requests and
filing bugs for them eventually.
But then at least a lot of problems will be gone, for UNCONFIRMED
won't exist anymore. All bugs filed are valid then. No superfluous
comments in lengthy bugs, no nuisances, rude behaviour, moaning. This
saves time, especially if the QA people are skillful and make no
mistakes. Maybe something to consider?
timeless
I'm basically asking for something like that. although, i'm fine with
doing it in a way where people are able to sign up for bugzilla but
can only use an end user product until we give them a special bit.
Philip Chee
> Maybe it should not be possible for public to file bugs directly,
> maybe a layer of QA people who do this for them. Would cost something
> I think, for at least one, two or even more people would have a
> fulltime job testing all those bugs and hearing those requests and
> filing bugs for them eventually.
And where will smaller projects like SeaMonkey and Lightning find this
"layer of QA people" unless you are volunteering?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]WARNING: Do not attempt this at home.
* TagZilla 0.066.6
Ria
> On Tue, 7 Apr 2009 07:31:25 -0700 (PDT), Ria wrote:
> > Maybe it should not be possible for public to file bugs directly,
> > maybe a layer of QA people who do this for them. Would cost something
> > I think, for at least one, two or even more people would have a
> > fulltime job testing all those bugs and hearing those requests and
> > filing bugs for them eventually.
>
> And where will smaller projects like SeaMonkey and Lightning find this
> "layer of QA people" unless you are volunteering?
>
> Phil
>
> --
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> [ ]WARNING: Do not attempt this at home.
> * TagZilla 0.066.6
Seamonkey/Lighting fans/volunteers will continue to work on the
project as long as the projects are popular enough of course.
Before I forget, what would be really handy using the bugzilla
software is a "Edit my comments" possibility. Then you can wipe out
all superfluous things you said before you really knew what the core
of the problem was, it saves you from posting corrective comments, so
you can make everything clear in one comment, comment 0. With a note
of course in the margin with the time you edited it for the last time
("edited by ..in reply to .. on 2009-04-08 01:59 PDT").
This way you can reduce everything to the core of the problem.
Another possibility is not to send a flow of e-mails after every Edit
action or Additional Reply, but only once per 60 minutes or so (if a
comment has been edited of course). Until then you can edit your
Edits, correct other actions etc.
Ria
way to edit comments would be great (although hard to implement
because of the notifications), but also the Version field could be
improved. At the moment not everyone does it the same way. When a bug
is found in 1.9.1 and in 1.9.2, some developers/triagers choose 1.9.1
and some 1.9.2 from the select box. And what to do when it is also in
1.9.0? In that case you can only choose for Unspecified or Trunk.
So maybe it would be an improvement if this field shows clearly in
what versions the bug can be found (if tested of course).