Bugs with Needs Info status should be displayed on open bugs query

I´m not sure about this, because NEEDINFO means the bug report wasn't accurate
enough. As soon as enough information is provided, the status should be
changed to whatever suits.

What do you guys think?

As I see it, something needing more information, shouldn't be hidden in
a search.

Well, NEEDINFO is an interesting status. It means that progress on the bug is blocked on input from someone (usually someone /else/, but not always :-). It's not always the bug reporter either, I suspect.

People triaging or fixing bugs like to have this off their list because it essentially means that they can't do any work on it until someone else has replied. On the other hand, it may be that the person that needs to give input is /the current user/, in which case it definitely /should/ be on their list.

The right thing to do is probably:
 - For now, display NEEDINFO bugs. People can sort them or Advance search them out if they want.
 - For the future, attach the NEEDINFO status to a /person/ so you can say "These bugs need information from you:".

How does that sound?

On Tue, Dec 06, 2005 at 08:43:06PM -0000, Christian Reis wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/4201
>
> Comment:
> Well, NEEDINFO is an interesting status. It means that progress on the
> bug is blocked on input from someone (usually someone /else/, but not
> always :-). It's not always the bug reporter either, I suspect.
>
> People triaging or fixing bugs like to have this off their list because
> it essentially means that they can't do any work on it until someone
> else has replied. On the other hand, it may be that the person that
> needs to give input is /the current user/, in which case it definitely
> /should/ be on their list.
>
> The right thing to do is probably:
> - For now, display NEEDINFO bugs. People can sort them or Advance search them out if they want.
> - For the future, attach the NEEDINFO status to a /person/ so you can say "These bugs need information from you:".
>
> How does that sound?

Another solution would be to define NEEDINFO (and possibly renaming it to
make it clearer) as needing information from the reporter, which should
be the common case. If you need information from someone else, simply
assign the bug to that person or something, telling him what to do.

I like this suggestion, Bjorn. It solves the tricky issue "when to display bugs in this status". It could be BlockedOnReporter or NeedsReporterInput or PendingReporter or ReporterNeeded.

Note that this implies people may use reassignment more, which intensifies my concern with making subs explicit.

(CanWeStopWithTheInterCapsStatusesPlease?) I think it's fine as "Needs Info", because while the reporter is the most likely person to supply the necessary info, it might well come from someone else who experiences the same bug and is willing and able to do the necessary debugging. Anyway, that doesn't resolve this bug, which is that triagers and reporters should see "Needs Info" bugs by default, while developers probably should not.

On Thu, Dec 08, 2005 at 07:23:48PM -0000, Matthew Paul Thomas wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/4201
>
> Comment:
> (CanWeStopWithTheInterCapsStatusesPlease?) I think it's fine as "Needs
> Info", because while the reporter is the most likely person to supply
> the necessary info, it might well come from someone else who experiences
> the same bug and is willing and able to do the necessary debugging.
> Anyway, that doesn't resolve this bug, which is that triagers and
> reporters should see "Needs Info" bugs by default, while developers
> probably should not.

I'm not clear exactly how you think that "Needs Info" should mean. I
think it should mean that the bug needs info from the reporter, or
someone like the reporter (i.e. not a developer). Do you agree with
that? If so, how do we make that clear, so that a developer or triager
doesn't think "Oh, this needs input from Stuart as a DBA", leaves a
comment indicating this, sets it to "Needs Info", and thus removing the
bug from Stuart's default list? I've already seen this happen,
developers asking other developers how to solve a bug and changing the
status to NeedInfo. They aren't expecting the reporter or someone with
the same problem to give more information.

BTW, why do you say that triagers should see "Needs Info" bugs by
default? My guess is that triagers would be the ones that would set the
bugs to this status. Although I might understand how you think, the
reporter isn't likely to change the status from "Needs Info" after
giving the information, someone else has to do it. To solve that, maybe
we could do something like showing all the "Needs Info" bugs that
someone has commented on after the status was set. But I'm not quite
sure how that would work.

On 9-Dec-05, at 2:09 AM, Björn Tillenius wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/4201
>
> Comment:
> On Thu, Dec 08, 2005 at 07:23:48PM -0000, Matthew Paul Thomas wrote:
>> Public bug report changed:
>> https://launchpad.net/malone/bugs/4201
>>
>> Comment:
>> (CanWeStopWithTheInterCapsStatusesPlease?) I think it's fine as
>> "Needs
>> Info", because while the reporter is the most likely person to supply
>> the necessary info, it might well come from someone else who
>> experiences
>> the same bug and is willing and able to do the necessary debugging.
>> Anyway, that doesn't resolve this bug, which is that triagers and
>> reporters should see "Needs Info" bugs by default, while developers
>> probably should not.
>
> I'm not clear exactly how you think that "Needs Info" should mean. I
> think it should mean that the bug needs info from the reporter, or
> someone like the reporter (i.e. not a developer). Do you agree with
> that? If so, how do we make that clear, so that a developer or triager
> doesn't think "Oh, this needs input from Stuart as a DBA", leaves a
> comment indicating this, sets it to "Needs Info", and thus removing
> the
> bug from Stuart's default list? I've already seen this happen,
> developers asking other developers how to solve a bug and changing the
> status to NeedInfo. They aren't expecting the reporter or someone with
> the same problem to give more information.
>
> BTW, why do you say that triagers should see "Needs Info" bugs by
> default? My guess is that triagers would be the ones that would set
> the
> bugs to this status. Although I might understand how you think, the
> reporter isn't likely to change the status from "Needs Info" after
> giving the information, someone else has to do it. To solve that,
> maybe
> we could do something like showing all the "Needs Info" bugs that
> someone has commented on after the status was set. But I'm not quite
> sure how that would work.

In practice, I've seen reporters change the status back to New from
time to time.

A few questions:

If we were to rely on using reassignment to designate from whom
action is required to make progress on this bug, might that risk
losing track of the bugs for which we were responsible?

mpt, you said triagers should see Needs Info bugs "by default". To
what "default" are you referring, and in what way will triagers
benefit from seeing Needs Info bugs "by default", given that they
probably the ones that set this status to begin with?

As a solution for right now, what do you guys think of automatically
flipping the status back to what it was before being set to "Needs
Info" when a comment is added to a Needs Info bug?

  affects /products/malone status needinfo

Cheers,

--
Brad Bollenbach

On Thu, Dec 22, 2005 at 12:00:05AM -0000, Brad Bollenbach wrote:
> In practice, I've seen reporters change the status back to New from
> time to time.

I interpret 'time to time' that this usually doesn't happen, so we need
to deal this this somehow.

> A few questions:
>
> If we were to rely on using reassignment to designate from whom
> action is required to make progress on this bug, might that risk
> losing track of the bugs for which we were responsible?

Maybe. Although I would say that if you only need some small input from
someone, that it's easier to ask the person directly. If you need
someone to do actual work on the bug, assign the bug to him, and if you
need to finish the work, tell him to reassign it back to you when he's
done.

> As a solution for right now, what do you guys think of automatically
> flipping the status back to what it was before being set to "Needs
> Info" when a comment is added to a Needs Info bug?

That would be confusing. Seeing how you set NeedInfo while adding your
comment, I would say you use it as "this bug is under discussion". We
could flip the status back if we define NeedInfo as "needs info from
the reporter". Of course, the status should only be flipped back when
the reporter commented. I'm not sure if it's useful to actually flip it
back, though, since the status should probably be New, given that most
likely information was lacking from the bug report, and the bug triagers
should decide if the information is enough or not.

I agree, though, that changing the status automatically when the
relevant person has comment could be a good idea. This all depends on
how we want to use the NeedInfo status. We should talk to the distro
people, the ones who requested this status in the first place, and see
how they use it. Brad, maybe you could brain dump a short spec about it?
It feels that we're not going to solve this in a bug discussion. A small
spec, phone calls and mailing list discussions is probably the way to
go.

#5320 claims that this isn't being fixed because it would break some reports. Can anyone explain what reports would be broken, so we can make a value judgement about what is worse? This bug is preventing users from finding their own bugs, for example.

After wasting 10 minutes searching an old bug of mine (finally found it via the read-only bugzilla.u.c site) because I was relying on the default search options that didn't included needinfo thus didn't see the bug in Malone, I'm also of the opinion that this is not a very user friendly feature of Malone.

Kiko has agreed that we should flip the switch on this now, so that at least people can see their own bug reports. Then we can work out which listings shouldn't include Needs Info bugs later (probably as part of MaloneFrontPages design work).