+reportedbugs does not include bugs where the user has added the second or subsequent bug task

[Gavin Panella]

Colin Watson added the grub2 in Ubuntu task to bug 430333, but this bug does not appear in <https://bugs.launchpad.net/~cjwatson/+reportedbugs>. He was not the first to report the symptoms, but he did identify the bug and report it in a new place, which I think should qualify as "filing the bug", at least for the purpose of search.

[Matthew Paul Thomas (mpt)]

How about if someone moves a bug report from the wrong package to the right package? Should +reportedbugs show that they "reported" that bug too?

[Gavin Panella (allenap)]

That's a good question. I don't know the answer.

It makes me think that the concept of bug reporter is not that useful. Currently it's something like "the first person to report the specified symptoms anywhere". For bugs with more than one task it doesn't tell us much; the reporter of each task is more interesting.

If bug tasks could not be re-targeted (but deleted, or is Invalid enough?) then the bug reporter could be "the first person to observe and report the symptoms in a specific piece of software". To me that seems like a useful piece of information.

But preventing change to the target is a different can of worms again.

[Matthew Paul Thomas (mpt)]

Knowing the reporter seems mainly useful for QA people, as an informal guide to how reliable the report is likely to be (and how responsive the reporter will be to requests for further information); and for the reporter themselves, when trying to find a bug they reported. But sometimes I get confused and remember reporting a bug, when what actually happened was that I was going to report it but found someone else had reported already -- especially if I then updated the description. So I would be much more interested in a list of bug reports I've either created or resummarized, than in a list of bug reports I've either created or added a project/package to! And I expect that is true for other QA volunteers. Some of them will have added projects/packages to hundreds of bug reports (linking Ubuntu bug reports to their bugzilla.gnome.org equivalents, for example), but that doesn't mean they want them intermingled with the bugs they actually reported.

There seems to be a lack of a use case here -- you were inspired by bug 449785, but this wouldn't solve any of the problems that came up in that bug report (which are a nasty combination of bug 1357 and bug 5977). Did Colin Watson actually wonder why bug 430333 didn't show up in his +reportedbugs? Has anyone else?

[Gavin Panella (allenap)]

> Knowing the reporter seems mainly useful for QA people, as an informal
> guide to how reliable the report is likely to be (and how responsive
> the reporter will be to requests for further information); and for the
> reporter themselves, when trying to find a bug they reported.

I agree. That information is similarly useful on a per-task basis too,
no?

> But sometimes I get confused and remember reporting a bug, when what
> actually happened was that I was going to report it but found
> someone else had reported already -- especially if I then updated
> the description.

I have the same problem :) It's interesting to imagine recording the
fact that I am a would-be reporter of a bug. I think +subscribedbugs
is a superset of this.

> So I would be much more interested in a list of bug reports I've
> either created or resummarized, than in a list of bug reports I've
> either created or added a project/package to! And I expect that is
> true for other QA volunteers.

That's fair. To me, those activities - create, resummarize, add target
- would be roughly as interesting as one another, but the QA workflow
is not my workflow.

> Some of them will have added projects/packages to hundreds of bug
> reports (linking Ubuntu bug reports to their bugzilla.gnome.org
> equivalents, for example), but that doesn't mean they want them
> intermingled with the bugs they actually reported.

Certainly this kind of activity is not something I would do, and it's
now obvious why an "add target" action appearing as a "reported bug"
would be wrong for a QA person.

To me, adding a target to a bug primarily reveals the bug to a new
audience, especially by way of new subscribers (and even more so if
it's a private bug). It's the task reporter not the bug reporter who
has recommended/reported this bug to that audience.

> There seems to be a lack of a use case here -- you were inspired by
> bug 449785, but this wouldn't solve any of the problems that came up
> in that bug report (which are a nasty combination of bug 1357 and
> bug 5977). Did Colin Watson actually wonder why bug 430333 didn't
> show up in his +reportedbugs? Has anyone else?

Ehrm, no, not to my knowledge :)

*I* expected it to show up in Colin's +reportedbugs, and I would want
bugs to which I had added a target to appear in my +reportedbugs. It
makes sense to me, and for me, because I don't regularly add targets
to bugs. I /guess/ it would make sense for Colin too. But I can see
that it wouldn't make sense for someone who primarily does QA.

[Matthew Paul Thomas (mpt)]

Based on the previous discussion, I think this bug is invalid, and "fixing" it would annoy contributors to Launchpad-hosted projects.

[Deryck Hodge (deryck)]

I don't think it's invalid. My take away from the conversation here is that some people expect that adding a task will make the bug show up in their +reportedbugs and some people would not like this. A proper fix for this problem would be figuring out a way to deal with this dilemma and given we are focusing on helping Ubuntu with the bug load the next six months, these kinds of questions are important.

[Robert Collins (lifeless)]

FWIW I agree that this is a valid bug - it uncovers some confusion that occurs for our users. Its not currently in our roadmap though, but if someone wants to think through it more I suggest having a discussion on the launchpad-developers mailing list; from consensus there we could look at how to get it implemented (e.g. mentoring the person doing the thinking :))