Incomplete status is used inconsistently

Bug 4201 discusses what we should do with the "Needs Info" status.

Bug 4201 is about how Needs Info bugs are displayed on reports. This bug came from a discussion yesterday with SteveA, confirming that we'll move Needs Info into being a flag, rather than a status.

On Thu, Dec 15, 2005 at 08:30:18AM -0000, Brad Bollenbach wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5786
>
> Comment:
> Bug 4201 is about how Needs Info bugs are displayed on reports. This bug
> came from a discussion yesterday with SteveA, confirming that we'll move
> Needs Info into being a flag, rather than a status.

Well, the discussion in bug 4201 is about what "Needs Info" really
means. For example, it discusses if it means just that bug needs info
from just the reporter, or if it can be from an arbitrary person. I'd
say it's better to keep the discussion in one bug, and then open up a
new bug if necessary later. Or do you see a value in having two parallel
discussions about the same status?

On 12/15/05, Björn Tillenius <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5786
>
> Comment:
> On Thu, Dec 15, 2005 at 08:30:18AM -0000, Brad Bollenbach wrote:
> > Public bug report changed:
> > https://launchpad.net/malone/bugs/5786
> >
> > Comment:
> > Bug 4201 is about how Needs Info bugs are displayed on reports. This bug
> > came from a discussion yesterday with SteveA, confirming that we'll move
> > Needs Info into being a flag, rather than a status.
>
> Well, the discussion in bug 4201 is about what "Needs Info" really
> means. For example, it discusses if it means just that bug needs info
> from just the reporter, or if it can be from an arbitrary person. I'd
> say it's better to keep the discussion in one bug, and then open up a
> new bug if necessary later. Or do you see a value in having two parallel
> discussions about the same status?
>
> --
> Launchpad-bugs mailing list
> <email address hidden>
> http://lists.canonical.com/mailman/listinfo/launchpad-bugs
>

--
Cheers,

--
Brad Bollenbach

On 12/15/05, Björn Tillenius <email address hidden> wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5786
>
> Comment:
> On Thu, Dec 15, 2005 at 08:30:18AM -0000, Brad Bollenbach wrote:
> > Public bug report changed:
> > https://launchpad.net/malone/bugs/5786
> >
> > Comment:
> > Bug 4201 is about how Needs Info bugs are displayed on reports. This bug
> > came from a discussion yesterday with SteveA, confirming that we'll move
> > Needs Info into being a flag, rather than a status.
>
> Well, the discussion in bug 4201 is about what "Needs Info" really
> means. For example, it discusses if it means just that bug needs info
> from just the reporter, or if it can be from an arbitrary person. I'd
> say it's better to keep the discussion in one bug, and then open up a
> new bug if necessary later. Or do you see a value in having two parallel
> discussions about the same status?

(Argh, the gmail web UI just froze in my browser and a blank reply got
sent to this bug. Anyway...)

There are two separate issues here:

bug 4201 - on what report should "Needs Info" bugs be shown

bug 5786 - "Needs Info" should be turned into a flag separate from bug
status (including some UI issues about the ways in which the behaviour
of the Needs Info changes for the user in terms of setting it in the
UI)

I think it's best to track these issues separately.

Cheers,

--
Brad Bollenbach

On Thu, Dec 15, 2005 at 09:00:04AM -0000, Brad Bollenbach wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5786
>
> Comment:
> On 12/15/05, Björn Tillenius <email address hidden> wrote:
> > Public bug report changed:
> > https://launchpad.net/malone/bugs/5786
> >
> > Comment:
> > On Thu, Dec 15, 2005 at 08:30:18AM -0000, Brad Bollenbach wrote:
> > > Public bug report changed:
> > > https://launchpad.net/malone/bugs/5786
> > >
> > > Comment:
> > > Bug 4201 is about how Needs Info bugs are displayed on reports. This bug
> > > came from a discussion yesterday with SteveA, confirming that we'll move
> > > Needs Info into being a flag, rather than a status.
> >
> > Well, the discussion in bug 4201 is about what "Needs Info" really
> > means. For example, it discusses if it means just that bug needs info
> > from just the reporter, or if it can be from an arbitrary person. I'd
> > say it's better to keep the discussion in one bug, and then open up a
> > new bug if necessary later. Or do you see a value in having two parallel
> > discussions about the same status?
>
> (Argh, the gmail web UI just froze in my browser and a blank reply got
> sent to this bug. Anyway...)
>
> There are two separate issues here:
>
> bug 4201 - on what report should "Needs Info" bugs be shown
>
> bug 5786 - "Needs Info" should be turned into a flag separate from bug
> status (including some UI issues about the ways in which the behaviour
> of the Needs Info changes for the user in terms of setting it in the
> UI)

Yes, the title for 4201 doesn't tell much, when I meant it was a
duplicate I was referring to the discussion. But if you want a new bug,
you should take into account the discussion in 4201 in this bug. I
personally think that Malone is complex as it is, the extra complexity
you propose isn't worth it.

A bug that needs design work should be assigned to the designer. Do you have any other examples?

Why should it be assigned to the designer? What if it were just a simple bit of design input required? How do I make sure that I don't lose track of ultimately being responsible for fixing the bug?

On Thu, Dec 22, 2005 at 12:53:08AM -0000, Brad Bollenbach wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5786
>
> Comment:
> Why should it be assigned to the designer? What if it were just a simple
> bit of design input required? How do I make sure that I don't lose track
> of ultimately being responsible for fixing the bug?

If it's just a simple bit of design, maybe you could ask him directly?
I'm not totally against having it as a flag, where you can specify from
which person you need input, I'm just questioning if it's worth the
extra complexity.

Anyway. Needing input from a developer is different from needing input
from the reporter. The former probably means that the bug is accepted,
the latter should mean that the bug report lacks information. I think
it's worth keeping these two use cases separated.

I think it was Steve who suggested that NeedInfo is used for two things:

 * needs info from original bug reporter
 * needs info from another source

So perhaps this should be a tristate field:

 * report incomplete
 * fix unknown
 * happy

"Why should it be assigned to the designer?" Because that's who needs to work on it next.

"What if it were just a simple bit of design input required?" As Bjorn said, just ask them directly.

"How do I make sure that I don't lose track of ultimately being responsible for fixing the bug?" If you're really possessive about a bug, wanting nobody else to fix it, then (a) ask for it to be reassigned back to you once the preliminary work is done, or (b) keep it assigned to you and create a dependent bug assigned to the other person (using the Description to note the dependency until proper dependencies are implemented).

In summary, I think using Needs Info for anything other than "the bug is not yet described in an understandable and reproducible manner" is bogus. If what you really want is a way to say "this bug needs input from multiple people", then extend the assignee field to allow multiple values. But if a bug is blocked on input from one specific person, it should be assigned to that person.

Changing assignees is somewhat problematic in that the person who is primarily or ultimately reponsible for "solving the problem" -- at least in terms of managerial responsibility -- loses track of the bug. It will, for instance, disappear from their +assignedbugs report.

That's a good point. During the Launchpad-Bazaar sprint we discussed the general case of this problem: "For issue X I need person Y to do Z, which should show up on Y's to-do list, and when Z is done X should automatically return to my unblocked to-do list". Examples of this include branches that need review, as well as bugs/specs that need preliminary work from designers/writers/drivers/lawyers.

With the introduction of the Triaged state this point is less important. Needs Info can be used when you need info from a user, Confirmed when you have that info. It can stay Confirmed while you wait for input from a team member (e.g. designer) and move to Triaged when the developer has what is needed to start fixing at which point it moves to In Progress.

Closing as invalid since we no longer have a NeedsInfo status.

Needs Info was renamed to Incomplete (see for example bug 32528), and Incomplete is still misused in the same way, even by Launchpad developers (for example, bug 422946, bug 178307, bug 603109, bug 518385, and bug 556059 are all currently marked as Incomplete and shouldn't be).

That doesn't necessarily mean that Incomplete "should" be a separate flag; there may be other, better solutions, or it may turn out that there is no solution at all. But the basic problem remains: bugs get marked as Incomplete as if it means one thing, and then get ignored or expired as if Incomplete means a different thing.

Thanks for pointing this out, mpt. I'll update the summary and description to clarify and reopen the bug.

Cheers,
deryck