New "INCOMPLETE" resolution in Bugzilla

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
https://bugzilla.mozilla.org/show_bug.cgi?id=369544

In a few days, we plan to create a new "INCOMPLETE" resolution in
Bugzilla, taking advantage of the new "custom resolutions" feature.

This is basically for resolving bugs which have insufficient information
in them. Up to now, INVALID has been used, but semantically that's not
quite right, and it is a bit rude.

The name matches a resolution GNOME are already using; consistency is nice.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
Gervase Markham wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=369544
>
> In a few days, we plan to create a new "INCOMPLETE" resolution in
> Bugzilla, taking advantage of the new "custom resolutions" feature.
>
> This is basically for resolving bugs which have insufficient information
> in them. Up to now, INVALID has been used, but semantically that's not
> quite right, and it is a bit rude.
>
> The name matches a resolution GNOME are already using; consistency is nice.

FWIW, Red Hat uses INSUFFICIENT_DATA, which is more accurate and IMO,
less ambiguous.  What's incomplete?  The bug report?  The work on fixing
the bug?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Mike Shaver
On 3/26/07, Christopher Aillon <[hidden email]> wrote:

> Gervase Markham wrote:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=369544
> >
> > In a few days, we plan to create a new "INCOMPLETE" resolution in
> > Bugzilla, taking advantage of the new "custom resolutions" feature.
> >
> > This is basically for resolving bugs which have insufficient information
> > in them. Up to now, INVALID has been used, but semantically that's not
> > quite right, and it is a bit rude.
> >
> > The name matches a resolution GNOME are already using; consistency is nice.
>
> FWIW, Red Hat uses INSUFFICIENT_DATA, which is more accurate and IMO,
> less ambiguous.  What's incomplete?  The bug report?  The work on fixing
> the bug?

I agree, that would be clearer.  "NEEDS INFORMATION" might be clearer still?

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
Mike Shaver wrote:
> On 3/26/07, Christopher Aillon <[hidden email]> wrote:
>> FWIW, Red Hat uses INSUFFICIENT_DATA, which is more accurate and IMO,
>> less ambiguous.  What's incomplete?  The bug report?  The work on fixing
>> the bug?
>
> I agree, that would be clearer.  "NEEDS INFORMATION" might be clearer
> still?

We also have a NEEDINFO state for currently open bugs.  It's a
flag-based state where someone can request info from a given user, e.g.
the reporter, or a module owner, et al.  Typically a bug goes to
NEEDINFO first to request the information be provided, and after a
reasonable time has passed, it gets resolved INSUFFICIENT_DATA.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
In reply to this post by Mike Shaver
Both INSUFFICIENT_DATA and NEEDS INFORMATION are really long though. I
think the idea with any bug being resolved INCOMPLETE is that the
person marking it so would also give a brief explanation why, and
almost always directing the reporter to support avenues to help find
the complete information and refile.  The other problem with NEEDS
INFORMATION is that it implies that more information is desired, which
we want to avoid.

A quick thesaurus search though, isn't providing any better examples
that are short, with the exception of "gremlins" everything short is
pretty insulting.

I personally think the context and the users would make INCOMPLETE
make sense (especially in combination with resolved), but respect the
argument that something more descriptive might be necessary.  I'm not
sure how to get around that though without saying ____ REPORT.


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Dan Mosedale
Banned User
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Mike Connor-4

On 27-Mar-07, at 3:53 PM, Dan Mosedale wrote:

> On 2007-03-26 14:47:57 -0700, [hidden email] said:
>
>> The other problem with NEEDS INFORMATION is that it implies that more
>> information is desired, which we want to avoid.
>
> Why do we want to avoid that?  Isn't that, in fact, exactly what we
> want to express?

This is unclearly stated, but my thinking is that we want to avoid  
reopening that particular bug, instead encouraging the reporter to  
file a clean and detailed report.

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Mike Shaver
Christopher Aillon wrote:
> We also have a NEEDINFO state for currently open bugs.  

Sadly, the particular design and customisation capabilities of Bugzilla
mean that adding a new resolution is easy, whereas adding a new status
is hard. Ideally, technology wouldn't dictate policy, but that's just
the way it is.

Adding a new resolution is easy, and it's still taken us six months.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Mike Shaver
In reply to this post by Mike Connor-4
On 3/27/07, Mike Connor <[hidden email]> wrote:

>
> On 27-Mar-07, at 3:53 PM, Dan Mosedale wrote:
>
> > On 2007-03-26 14:47:57 -0700, [hidden email] said:
> >
> >> The other problem with NEEDS INFORMATION is that it implies that more
> >> information is desired, which we want to avoid.
> >
> > Why do we want to avoid that?  Isn't that, in fact, exactly what we
> > want to express?
>
> This is unclearly stated, but my thinking is that we want to avoid
> reopening that particular bug, instead encouraging the reporter to
> file a clean and detailed report.

If the bug is a bad report, maybe, but telling them that they should
file a new bug because we want them to tell us more about which
version of something they're using, or if they have a given extension
installed, etc. seems like the wrong path.  We lose all the cc: state
and such when the reporter does that, so I think we should generally
avoid it unless the bug is so messed up as to be a significant
impediment to actually fixing it.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Stephanie Daugherty
In reply to this post by Gervase Markham
On Mar 27, 5:12 pm, Gervase Markham <[hidden email]> wrote:

> Christopher Aillon wrote:
> > We also have a NEEDINFO state for currently open bugs.
>
> Sadly, the particular design and customisation capabilities of Bugzilla
> mean that adding a new resolution is easy, whereas adding a new status
> is hard. Ideally, technology wouldn't dictate policy, but that's just
> the way it is.
>
> Adding a new resolution is easy, and it's still taken us six months.
>
> Gerv

A NEEDINFO state is needed much more than a missing info resolution
though. FWIW, a missing info resolution's more a technicality. Once a
bug's appropriately resolved, it tends to stay that way. Tracking what
bugs require action from the reporter (and being able to query or
filter by that) is of critical importance to efficient handling of
bugs, particularly unconfirmed bugs where we have to prod the reporter
for enough details to reproduce.

Given that this has been implemented by several downstream users of
Bugzilla, I still don't see what the difficulty is in having this, but
it's been held off since 2002 for a "perfect" solution, when at this
point, almost any solution would be an improvement, at least as far as
bugzilla.mozilla.org goes.

We have tremendous duplication of effort for the triagers dealing with
unconfirmed bugs for lack of a NEEDINFO state. The same unconfirmed
bugs have to be examined repeatedly only to see that they are waiting
for a reply. This takes time up that could be used confirming bugs for
which there's actually enough information to work with, and
contributes greatly to the frustration of anyone working with
unconfirmed bugs.

--Stephanie

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
I think an important point in this discussion is in the bug, and
that's the stats on how often a "my bookmarks are broken" bug actually
gets the necessary info added, and how useful bugs are that don't have
clear str until comment #8. This is mconnor's area, though so if there
are questions about that, ask him!

Shaver - you're right, and I don't think any of the examples you gave
were intended to be marked INCOMPLETE although definitely fit in the
description of the word. I think for the most part any bugs that would
really get the resolution we're trying to decide on would be support
requests, or people filing a bug that should be seeking support
instead, i.e. something broke and so they're filing, and they've done
nothing to try and reproduce or look to see if there's an answer
somewhere.

This in some ways presents a grey area for valid issues that don't
have steps to reproduce.  Part of what I really liked about the idea
of marking these bugs separately is the idea that they're still there,
and once steps to reproduce are found, those incomplete bugs (if it's
clear they're the same issue) can be duped forward.  If it's not clear
enough, it still gives people a place to track these sorts of issues,
to piece things together, rather than having to sort through what's
invalid because it didn't make sense and what's invalid because it
really isn't a bug or leaving them unconfirmed.  I think we don't want
20 people all saying "I'm having the same issue" in one bug before
it's found that it's actually 3 different issues. That usually gets
messy (ala copy/paste or bookmarks issues).

The only issue I see this raising is how to get people who are cc'ed
to the INCOMPLETE bug aware of the new properly filed bugs to try out
the STR .  I think this can be overcome either by using META bugs to
organize the incomplete bugs by symptom, if the priority is getting
all reporters onto a valid bug (how many care, how many leave after
filing?), or by searching incomplete bugs for similar symptoms and
asking the reporters to check out the new bug if we need confirmation
on the STR (if we're pointing these people to support avenues anyway,
they can stay in touch with those avenues to check up on new bugs.
Even with the current system there's no guarrantee their bug will be
the one that gets the work in it or that their bug will be duped to
the right one.)

-Majken "Lucy" Connor

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
In reply to this post by Stephanie Daugherty
On Mar 28, 1:02 am, "Stephanie" <[hidden email]> wrote:

>
> We have tremendous duplication of effort for the triagers dealing with
> unconfirmed bugs for lack of a NEEDINFO state. The same unconfirmed
> bugs have to be examined repeatedly only to see that they are waiting
> for a reply. This takes time up that could be used confirming bugs for
> which there's actually enough information to work with, and
> contributes greatly to the frustration of anyone working with
> unconfirmed bugs.
>
> --Stephanie

Stephanie - I might not be catching on to what you're meaning, but how
I'm understanding it, I don't see how it makes any difference to how
things are now.  I'm not sure why the bugs have to be examined
repeatedly, and so maybe this is the heart of why I'm not getting it.
Even so, how would NEEDINFO change that?  The way I'm grasping it,
you're watching the bug for more information either way.

The missing info state would mean you do one pass on the bug, see that
you can't simply ask a question like "do you have extensions
installed?" or "what version are you using?"  Mark the bug as
INCOMPLETE (ideally this adds a canned response directing the reporter
to seek support who can either help solve their issue, or help them
troubleshoot the issue so they can file a complete bug) and then move
on.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Vladimir Vukicevic-3
In reply to this post by Stephanie Daugherty
Stephanie wrote:

> Given that this has been implemented by several downstream users of
> Bugzilla, I still don't see what the difficulty is in having this, but
> it's been held off since 2002 for a "perfect" solution, when at this
> point, almost any solution would be an improvement, at least as far as
> bugzilla.mozilla.org goes.
>
> We have tremendous duplication of effort for the triagers dealing with
> unconfirmed bugs for lack of a NEEDINFO state. The same unconfirmed
> bugs have to be examined repeatedly only to see that they are waiting
> for a reply. This takes time up that could be used confirming bugs for
> which there's actually enough information to work with, and
> contributes greatly to the frustration of anyone working with
> unconfirmed bugs.

I very much agree here -- I think that the way the Red Hat bugzilla
works is exactly the functionality that we want here: a bug in the
NEEDINFO state reverts to NEW as soon as a comment is added, without the
commenter explicitly needing to set anything.  If the commenter wants it
to stay in NEEDINFO, they explicitly have to set the state to NEEDINFO
when they submit their comment.

     - Vlad
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
On Mar 28, 2:46 am, Vladimir Vukicevic <[hidden email]> wrote:

>
> I very much agree here -- I think that the way the Red Hat bugzilla
> works is exactly the functionality that we want here: a bug in the
> NEEDINFO state reverts to NEW as soon as a comment is added, without the
> commenter explicitly needing to set anything.  If the commenter wants it
> to stay in NEEDINFO, they explicitly have to set the state to NEEDINFO
> when they submit their comment.
>
>      - Vlad

So is this a case where the bug is confirmed but you need to find out
things like a regression window?  If so, then that's a bit of a
different beast and I would want to avoid letting discussion on it
delay action on this, which deals with unconfirmed bugs.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Vladimir Vukicevic-3
Vladimir Vukicevic wrote:
> I very much agree here -- I think that the way the Red Hat bugzilla
> works is exactly the functionality that we want here: a bug in the
> NEEDINFO state reverts to NEW as soon as a comment is added, without the
> commenter explicitly needing to set anything.

If people are interested in making it easier to have b.m.o. take
functional enhancements of this sort, they need to be aware of how
things work at the moment.

As I understand it, the current way that b.m.o. is maintained is via a
single large patch on top of a particular release of Bugzilla. This
large patch can be obtained on request. It contains all sorts of
different changes, all mixed together.

I'm sure there are several people who would be happy to write custom
improvements for b.m.o. (I certainly include myself in this), but the
above arrangements make it more difficult than it needs to be to obtain
a copy of the current production code which you know is absolutely
correct, write and test a patch against it, and share the results of
that with other people for further testing.

It also seems very difficult to get patches that have been written
applied. I've been waiting for 18 months to get a patch I wrote at
mconnor's request applied:
https://bugzilla.mozilla.org/show_bug.cgi?id=314056

If the code running on b.m.o. were a branch in an SCM instead of a big
tarball patch, people could check it out, get it working for them, write
patches and test them with much greater ease. It would also make it much
easier for b.m.o. to be upgraded (and downgraded again if necessary) to
take safe incremental improvements - because there would not be manual
patching and merging steps involved.

(This is not an attempt to attack anyone; I'm just outlining the facts
as I understand them, and suggesting why we might have the problem we have.)

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
Gervase Markham wrote:
> As I understand it, the current way that b.m.o. is maintained is via a
> single large patch on top of a particular release of Bugzilla. This
> large patch can be obtained on request. It contains all sorts of
> different changes, all mixed together.

My apologies; this is incorrect. There are multiple, distinct patches,
and they can be obtained as a .tar.gz (or .bz2; I forget) - which is why
I originally remembered there being just one file.

Of course, while this is better patch management, it doesn't make it any
easier to create your own version of the b.m.o. code.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Peter Weilbacher
In reply to this post by majken@gmail.com
[hidden email] wrote:
> I think an important point in this discussion is in the bug, and
> that's the stats on how often a "my bookmarks are broken" bug actually
> gets the necessary info added, and how useful bugs are that don't have
> clear str until comment #8.

What's "str" (or "STR" as you use it further down in your post)? If it's
more frequently used, perhaps you can add a definition to the glossary on
MDC?
   Peter.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Peter Weilbacher
In reply to this post by Mike Connor-4
Mike Shaver wrote:

> On 3/27/07, Mike Connor <[hidden email]> wrote:
>> This is unclearly stated, but my thinking is that we want to avoid
>> reopening that particular bug, instead encouraging the reporter to
>> file a clean and detailed report.
>
> If the bug is a bad report, maybe, but telling them that they should
> file a new bug because we want them to tell us more about which
> version of something they're using, or if they have a given extension
> installed, etc. seems like the wrong path.  We lose all the cc: state
> and such when the reporter does that, so I think we should generally
> avoid it unless the bug is so messed up as to be a significant
> impediment to actually fixing it.

Apart from that it would also make it more difficult to find the right bug
in a Bugzilla search. It's already difficult enough now, even for people
who search for bugs on a daily basis.
   Peter.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gijs Kruitbosch ("Hannibal")
In reply to this post by Peter Weilbacher
Peter Weilbacher wrote:

> [hidden email] wrote:
>> I think an important point in this discussion is in the bug, and
>> that's the stats on how often a "my bookmarks are broken" bug actually
>> gets the necessary info added, and how useful bugs are that don't have
>> clear str until comment #8.
>
> What's "str" (or "STR" as you use it further down in your post)? If it's
> more frequently used, perhaps you can add a definition to the glossary on
> MDC?
>    Peter.

Steps to reproduce. I added a Glossary entry.

~ Gijs
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Gervase Markham wrote:
  > My apologies; this is incorrect.

Double apologies; I was right the first time! The huge patch can be
obtained from here:

http://landfill.bugzilla.org/prodpatches/huge-bmo-patch8.diff

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345