478467 - b.m.o needs NEEDINFO status or equivalent solution

Status: RESOLVED DUPLICATE of bug 778731

(bugzilla.mozilla.org :: Administration, task)

Description

[Hubert Figuiere [:hub]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009012700 SUSE/3.0.6-0.1.2 Firefox/3.0.6
Build Identifier: 

Bugzilla need a NEEDINFO status in order to mark bugs pending info and to have people being assigned to reply to the question. This is important in the workflow.

Reproducible: Always

Comment 1

[David Lawrence [:dkl]]

We (Red Hat) find having a globally available flag called 'needinfo' and setting it to '?' with optional requestee set to the person you are asking information of works better than a bug status.

Comment 2

[Frédéric Buclin]

You can add this bug status yourself if you have Bugzilla 3.2 or newer.

Comment 3

[Hubert Figuiere [:hub]]

reassign to bugzilla.mozilla.org

Comment 4

[Luis Villa [Outside Counsel; for non-law use [e-mail]]]

dkl: just curious why you think the RH solution works better than a status? I do like that RH's solution allows you to specify who is responsible for seeing who is responsible for the NEEDINFO, but then it still shows up in my bugs, right?

Status, to me, works because if I'm the assignee I can search on bugs that are new or assigned and get bugs I need to work on. As it currently stands in b.m.o I have a ton of bugs that are assigned to me but which I can't work on because they are blocking on other people, making my 'my bugs' search nearly useless (right now more than 3/4 of my bugs are what would be NEEDINFO in b.g.o.) If I had a NEEDINFO status (or something equivalent) My Bugs would be vastly more useful, because it would let me focus only on bugs I can do something about.

Comment 5

[Hubert Figuiere [:hub]]

Also NEEDINFO must be combined to a reassign to whoever shall provide the info, and when resetting to "NEW" or "ASSIGNED" assign back to whoever it was assigned.

That would also allow to have bug for which you are required to provide info to appear in your list.

Comment 6

[Luis Villa [Outside Counsel; for non-law use [e-mail]]]

I wouldn't call that a 'must'; a responsible bug owner will handle that themselves. But I agree that would be a very nice way to handle the implementation.

Comment 7

[David Lawrence [:dkl]]

(In reply to comment #4)
> dkl: just curious why you think the RH solution works better than a status? I
> do like that RH's solution allows you to specify who is responsible for seeing
> who is responsible for the NEEDINFO, but then it still shows up in my bugs,
> right?

We wanted to slim down the list of statuses as far as possible so we decided that we wanted to do away with the NEEDINFO status as well. We had several different NEEDINFO statuses at the time.

NEEDINFO: general need more info from anyone
NEEDINFO_REPORTER: need more info from reporter specifically
NEEDINFO_ENG: need more info from the assignee or engineer

As you can see it could get out of control as different roles are needed. So management decided to get rid of the NEEDINFO* statuses and code in needinfo actor support. Rather than code something custom from scratch, the flag system
seemed like a good fit at the time for several reasons:

1) Can be available for all products/components
2) Can be specifically requestable to a role or individual (actor)
3) Supports multiple states for each flag although we only really use X or ?
at any time.
4) Can be multiple requestable
5) And can work with or without javascript.

We added some simple UI changes to make it more intuitive by hiding the needinfo flag backend work and also to place the UI near the comment field
where it was needed most often. Also you can select either assignee, reporter, qa_contact, etc. without needing to type in the actual email address of those.
Of course this all still works from the normal flags section of show_bug.cgi 
as well.

Originally we had hacks to move the old NEEDINFO* statuses back to the prior bug status automatically when the proper person made a comment since they would
forget to do it themselves if left for them to do manually. With the new flag
method the bug status doesn't need to be changed at all and has worked better.

Managers can now just query on bugs with needinfo? set as well as a particular bug status to see which ones are in need of attention.

Dave

Comment 8

[Luis Villa [Outside Counsel; for non-law use [e-mail]]]

As a note on the way out the door: after a year here, I continue to believe that poor status handling is a critical problem for bugzilla usage at mozilla. For maximum utility, "My Bugs" should always be a list of bugs that *I* am currently, at this moment, responsible for taking the next action on. The lack of a "needinfo" or equivalent status means that, instead, "My Bugs" frequently contains things that I can't do anything about, and that is a huge problem for having an efficient workflow.

I've hacked around this by customizing my searches and putting "needinfo" in whiteboards, but that isn't a reasonable solution for average users.

Again, I'd strongly recommend resolving this issue as part of a larger plan to fix the bugzilla workflow for developers.

Comment 10

[Andrew Overholt [:overholt]]

I'm very much in favour of having a way to know who is responsible for providing requested info.

Comment 11

[Andre Klapper]

(In reply to Andrew Overholt [:overholt] from comment #10)
> I'm very much in favour of having a way to know who is responsible for
> providing requested info.

This is implemented in the Redhat Bugzilla, maybe some code could be borrowed.

Comment 12

[David Lawrence [:dkl]]

(In reply to Andre Klapper from comment #11)
> (In reply to Andrew Overholt [:overholt] from comment #10)
> > I'm very much in favour of having a way to know who is responsible for
> > providing requested info.
> 
> This is implemented in the Redhat Bugzilla, maybe some code could be
> borrowed.

That is my plan. But I will be taking the code and converting it to an extension instead for easier maintainability going forward. At Red Hat when I wrote the feature, I put it in the core code itself and it had to be ported to any new versions.

Also when I addd it to BMO, I will start off with a few select products and work up from there as people see if it is useful or not for the site as a whole.

dkl

Comment 13

[:glob ✱]

this has been addressed by the needinfo flag in bug 778731.