Closed Bug 136107 Opened 22 years ago Closed 17 years ago

Add NEEDINFO status

Categories

(Bugzilla :: Administration, task, P2)

Product:
Bugzilla
Component:
Administration
Version:
2.15
Type:
task

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: netdragon, Assigned: gregaryh)

References

Details

(Whiteboard: [flow:status][blocker will fix]) 

I saw that bugzilla.redhat.com had a Needinfo resolution. This would be good 
for us to have as it would cut down on the uncomfirms and differentiate 
between uncomfirms that just haven't been looked at or confirmed yet, and 
those that the reporter hasn't given enough information to attempt to confirm, 
etc.
asa has insisted that mozilla.org will not make large modifications to the 
bugzilla installation.

i'm insistant that we not abuse resolutions.
Assignee: asa → myk
Component: Bugzilla: Keyword & Component → Creating/Changing Bugs
Product: mozilla.org → Bugzilla
QA Contact: timeless → matty
Version: other → 2.15
notes and clarifications.
1. in my book needinfo, later, and remind are all inappropriate resolutions
2. bbaetz noted that at some point we will allow custom resolutions
3. that doesn't matter here. if someone allows custom statuses (i have a proposal somewhere) then we can talk.
NEEDINFO should be a resolution, but only if sufficient time has passed in a
NEEDINFO status without info being received.

Customised statuses is bug #101179 and customised resolutions is bug #94534.
Depends on: bz-custstat
No longer depends on: bz-custstat
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18
Note that for Red Hat, NEEDINFO is a status not a resolution.  Personally, I
think that it makes more sense for it to be a status.  If the reporter doesn't
provide the requested information in a timely fashion (however that is defined)
the owner can resolve it WONTFIX.
Depends on: bz-custstat
Yes, the status is the important bit.  I think the resolution should be NOINFO
or something.
Summary: Add Needinfo resolution → Add Needinfo status
This is mine.
Assignee: myk → matty
Component: Creating/Changing Bugs → Administration
QA Contact: matty → jake
BTW hopefully WONTFIX is going away in Bugzilla.  It can mean about 5 different
things and they should all be separate resolutions.
More generally, we need the administrator to be able to provide custom lists of
possible Resolutions and Statusses.

(I need NEEDINFO too, and RTFM.)
Taking Jake's bugs...  his Army Reserve unit has been deployed.
QA Contact: jake → justdave
I've seen the benefit of a NEEDINFO/NMI (Need More Info) in the past. If used 
properly, it is a much better mechanism for resolving non-reproducible bugs in 
that it puts the burden back on the reporter to provide a more well-defined bug 
report so that the triagers aren't having to devine what scenario is needed to 
reproduce the problem. Then, if after a generous waiting period say, 45 days, 
the reporter has not responded, the bug would be closed with a "lack of 
information" status (CL-LOI). Of course, if the reporter were to report back 
after the waiting period with additional information (very, very seldom 
happened) then the bug could be reopened. Mostly what happened was that the 
reporter either provided the needed information within the allotted time or 
simply let the bug languish for any number of reasons.

The real benefit of this method is that it really helps to keep the open bug 
bin in a credible state. Another benefit for the QA folks was that it help them 
with the metrics for defining valid open bugs.

fwiw...
Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Whiteboard: [flow:status]
*** Bug 285573 has been marked as a duplicate of this bug. ***
From duplicated bug 285573:
I would like the bug to auto-resolve into WORKSFORME/INVALID
after a certain time period if there has been no new comment/attachment added
after it was resolved as NEEDINFO. The time period can be global or
be specified individually per bug when resolving as you see fit.
Assignee: mattyt-bugzilla → administration
QA Contact: justdave → default-qa
Target Milestone: Bugzilla 2.22 → ---
bugzilla.novell.com has a working model for this. 
I have also had some requests from interested bugzilla admins.
I will try to put up a patch soon.
Assignee: administration → ghendricks
*** Bug 362601 has been marked as a duplicate of this bug. ***
Apologies for the duplicate, I didn't see this one when I searched, and was apparently looking in the wrong places.

I'm looking into what it will take to implement this, although, I'd say it would be better implemented as either a status or and additional field - it's not a resolution, it's an intermediary step to getting a resolution.

The things I'm specifically looking for:
1) Getting bugs that need more information out of UNCONFIRMED status so that they don't show up when searching for unconfirmed bugs.
2) Ability to search for bugs in need of more info that haven't been touched in a period of time.
3) Status should automatically revert to UNCONFIRMED when a new comment is added, but this can be suppressed (leaving the bug in a needs-info state) by someone with the right permissions (can-confirm?? editbugs??)

The benefits of this are:
Bugs that do not have enough information will not need remain in UNCONFIRMED state for long. For a busy bug database such as b.m.o, this means that the signal/noise should improve significantly, and less bugs should get stuck in UNCONFIRMED status for long periods of time - they will either get confirmed, rejected, or will be passed back to the reporter for the information needed.

I'm not familiar enough with the bugzilla codebase to provide a patch for this quite yet, but there's a significant, tangible benefit to doing this.

Adding a "helpwanted" keyword for now.
Keywords: helpwanted
personally, at this point i'd suggest using a flag. you can easily search for flags, you can easily search for bugs that have flags, you can easily figure out who has been flagged.

some benefits:
i can set 3 flags against 3 people for 1 bug. so if a bug collects duplicates and drive by spammers i can ask each person who might have the information for it.

it also means that when someone does satisfy the request, they can mark it, and they don't have to try to get the bug back to the right assignee.

i've seen a needinfo policy enforced elsewhere, and the results are sucky.
(In reply to comment #18)
> personally, at this point i'd suggest using a flag. you can easily search for
> flags, you can easily search for bugs that have flags, you can easily figure
> out who has been flagged.

I like this approach - it would probably be easier to implement than a new status and all the associated code needed to set and clear it.

> some benefits:
> i can set 3 flags against 3 people for 1 bug. so if a bug collects duplicates
> and drive by spammers i can ask each person who might have the information for
> it.
> it also means that when someone does satisfy the request, they can mark it, and
> they don't have to try to get the bug back to the right assignee.

I like this part also. It's not always the original requester that information has to be obtained from, and anytime you can get a more flexible approach for basically the same amount of work, you are generally better off doing so.

Couple questions here.
Will the average reporter know how to mark a need-info flag done?
Will the average reporter have the access to mark a need-info flag done?
Is it practical to automatically clear these flags on reply?

> i've seen a needinfo policy enforced elsewhere, and the results are sucky.

As far as I can tell this is more about implementation than policy.
I'm not sure that this is needed so much as an enforced policy as a way to track bugs that are missing information and deal with them more effectively. Having bugs that lack information waiting in UNCONFIRMED state without some way to filter those bugs out creates a signifigant signal/noise problem in a large installation such as b.m.o, and makes it very difficult to see what bugs need QA and testing attention, and which bugs need the reporter to wake up and supply more details.

At the very least, some sort of solution to this would make the QA process for bugzilla.mozilla.org more effective, and I think that other large sites would see similar benefits.

> Will the average reporter know how to mark a need-info flag done?

if this is not the case, then we need to fix bugzilla. we rely on flags, and the ui has to be understandable. - bug 362637

> Will the average reporter have the access to mark a need-info flag done?

if you're requested to set a flag, you have to be able to set it. this shouldn't be a problem

> Is it practical to automatically clear these flags on reply?

i'd argue against it and would hope that my proposal A for bug 362637 would satisfy the concern.

--

as to the needinfo implementation/policy, the problem is that the standard way to handle needinfo involves reassigning bugs to the person from whom info is needed, and as a result getting the bug reassigned back to the correct owners (and qa contacts) is very difficult.

note that needinfo need not be "needinfo from reporter" so you can't simple change a bug to NeedInfo and pray the right person will see it.

Which is why I'm proposing flags instead, they're much more flexible.
(In reply to comment #20)
> > Will the average reporter know how to mark a need-info flag done?
> 
> if this is not the case, then we need to fix bugzilla. we rely on flags, and
> the ui has to be understandable. - bug 362637
> 


> > Is it practical to automatically clear these flags on reply?
> 
> i'd argue against it and would hope that my proposal A for bug 362637 would
> satisfy the concern.

How does this address scenarios where multiple users are requested to provide info, and only one of them provides it, but provides everything needed? Would some of the flags remain in a "wanted" state? 

What about if we determine after the additional info is added, we still need more? 

Are we going to have several contradictory flags?

> as to the needinfo implementation/policy, the problem is that the standard way
> to handle needinfo involves reassigning bugs to the person from whom info is
> needed, and as a result getting the bug reassigned back to the correct owners
> (and qa contacts) is very difficult.

How about this workflow, for NEEDINFO as a status:

Missing info is requested in a comment, status is changed to NEEDINFO.
If anyone comments on the bug after that, the default action for the radio buttons below the comment field is to change the bug back to either NEW or UNCONFIRMED (using everconfirmed to determine which). Users with privileges (editbugs/canconfirm) would see additional options to leave the bug in this state when editing it, users without privileges would only have the options to put it back to NEW/UNCONFIRMED or if it was their bug, to resolve it.

Essentially, that means if any unprivileged user comments, it goes back to UNCONFIRMED or NEW as appropriate. The assignee doesn't ever have to change.

This is less flexible than using flags, however:
1) It's straightforward from a user interface perspective - all the user does is comment.
2) If NEEDINFO is used as an "out of sight out of mind" status for bugs with missing info, any comment made on that bug probably needs to be examined, unless it's made by someone qualified to say that the comment doesn't resolve the missing-info. Worst case, we have a few bugs we have to throw back into NEEDINFO after someone comments on them.
3) There's no need to change the assignee on NEEDINFO bugs, it's just interpreted as a general status, which any comment satisfies.
4) This approach probably requires less code, and doesn't rely on bug 362637.
5) This avoids complicated filtering situations with a mix of needinfo+ needinfo? and needinfo- flags on bugs.
6) This could conceivably be used along side, or alternately with flags.

> note that needinfo need not be "needinfo from reporter" so you can't simple
> change a bug to NeedInfo and pray the right person will see it.
> 
> Which is why I'm proposing flags instead, they're much more flexible.

They are, and long term, they are probably the right solution. I think short term though, its a lot easier to implement a status, and a lot less work.

Also, there's enough of a need for this on b.m.o that even if we don't integrate this into the bugzilla cvs right away, it would probably be worth looking at a customization for b.m.o.

> How does this address scenarios where multiple users are requested to provide
> info, and only one of them provides it, but provides everything needed?

it doesn't. humans are sometimes required, it's a fact of life

> Would some of the flags remain in a "wanted" state? 

that depends on who enters the information (specifically how much power they have and how restricted the flags are).

when a request you make is resolved, you're sent a special email (which isn't quite a bugmail), so if you can receive email (i can't) for such changes, you could go and reevaluate the bug. we don't currently include in the email a list of other pending requests. I think we should consider doing so. (bug ...)

> What about if we determine after the additional info is added, we still need
> more? 

again, humans are required. the person who makes this determination will have to set another request. there's nothing wrong with this.

> Are we going to have several contradictory flags?

i'm not sure what you mean by contradictory.

you could easily have:

dejected.user: info- <user explains he stopped caring, or can't reproduce or whatever>
reporter: info+ <reporter provides some information>
qa: info?user2 <reporter of a duplicate is asked for information>
qa: info?user3 <drive by spammer is asked for information>
qa: info?reporter <qa asks for more information from reporter>

there's nothing specifically contradictory in this. it's just a tagged dialog.
(In reply to comment #22)
> > Are we going to have several contradictory flags?
> 
> i'm not sure what you mean by contradictory.
> 
> you could easily have:
> 
> dejected.user: info- <user explains he stopped caring, or can't reproduce or
> whatever>
> reporter: info+ <reporter provides some information>
> qa: info?user2 <reporter of a duplicate is asked for information>
> qa: info?user3 <drive by spammer is asked for information>
> qa: info?reporter <qa asks for more information from reporter>
> 
> there's nothing specifically contradictory in this. it's just a tagged dialog.

Not exactly, but from a standpoint of searching for "bugs that are ready to be triaged again", having info+ and info?/info- make searching very problematic.


(In reply to comment #18)
Personally, I would prefer using Status rather than a flag.
But a flag is better than nothing.

(In reply to comment #21)
Instead of resetting the Status back to NEW/UNCONFIRMED for any new
comment, Bugzilla could ask the user on "Commit", I think we would
get the right answer most of the time.
again, the main problem i have with a status is that if you need information from 2 people (not the reporter) and the current assignee+qa are not the default, then how in the world do you express this? and of course, the 2 people you want info from don't have editbugs, so they couldn't reassign if they knew how.

undoing and managing the state is just *hard*.
(In reply to comment #25)
> again, the main problem i have with a status is that if you need information
> from 2 people

It should be clear from the comment that asks for the information, e.g.
Name1, please tell me...
Name2, please tell me...

In my experience, the common case is that we need info from the reporter,
needing info from two or more people is rare.

> ... (not the reporter) and the current assignee+qa are not the
> default, then how in the world do you express this? and of course, 
> the 2 people you want info from don't have editbugs, so they couldn't
> reassign if they knew how.

Why do you keep bringing up reassignment?
A bug shouldn't be reassigned just because it needs info.

> undoing and managing the state is just *hard*.

Do you mean hard to implement, or hard to use?
I think Status is considerably easier to use than flags targeted
at specific people. Flags would permit more precise tracking of the
outstanding info requests though, I'd give you that.
I simply don't think that level of tracking is needed.
(In reply to comment #25)
> again, the main problem i have with a status is that if you need information
> from 2 people

In the two years that bugilla.novell.com has been using NEEDINFO as a status I am not aware of any place where this has been the case. The VAST majority of the time you need more information from the reporter. The way we have implemented it is NEEDINFO is another open status. When a user sets the NEEDINFO status they also have to specify an info_provider. This is a field that we have added to the bugs table. There is a dropdown next to the NEEDINFO status that defaults to the reporter but also allows the last commentor or someone else to be chosen.

This status has been invaluable for our work flow. It means that people who need to provide the information are included on all bugmail for as long as they are listed as the infoprovider. There is then a checkbox under the comment box that allows them to set the status back once the information has been provided.

This checkbox can be made available only to the infoprovider regardless of whether they have editbugs privileges. Also, if information is required from more than one person, simply stating so in the comment and adding them to the CC usually suffices. 
Some people not commenting/answering questions on their own bugs really don't know where to answer, so a link 'comment on this bug' should be right beneath the link 'Enter new bug' in the top and bottom link lines.
I got two mails from reporters who didn't know, and I myself sent a mail after not knowing where to add comments. Reason: I've read comments for a year before filing my first bug, and I always was scrolling down fast to the comments, ignoring the huge blank space between header and comments area.
FYI, caillon@redhat.com offered to submit a patch for NEEDINFO status within
two months in the recent thread discussing INCOMPLETE resolution in
mozilla.dev.planning
Summary: Add Needinfo status → Add NEEDINFO status
(In reply to comment #29)
> FYI, caillon@redhat.com offered to submit a patch for NEEDINFO status within
> two months in the recent thread discussing INCOMPLETE resolution in
> mozilla.dev.planning

No need. Bug 101179 has a patch and should be checked in within one week. Then no hack of any kind will be required anymore.
Keywords: helpwanted
Whiteboard: [flow:status] → [flow:status][blocker will fix]
You can add this bug status yourself in Bugzilla 3.2, see bug 101179.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.