Malone should provide a guided bug form to reduce duplicate bug reports

All default bug listings include bugs we consider unresolved, which right now means bugs with status NEW and ACCEPTED. If nobody objects, I'll add PENDINGUPLOAD to the unresolved statuses too.

It would be nice to add NeedInfo too.

On Fri, Nov 18, 2005 at 11:43:38AM -0000, Guilherme Salgado wrote:
> All default bug listings include bugs we consider unresolved, which
> right now means bugs with status NEW and ACCEPTED. If nobody objects,
> I'll add PENDINGUPLOAD to the unresolved statuses too.

That's fine for bug reports that potential bug reporters will see -- but you
don't want to show PENDINGUPLOAD bugs to a developer looking at a list of bugs
they need to work on. From a developer's perspective, PENDINGUPLOAD probably
does mean "resolved". We need to cater to both use cases, although probably
with different pages.

--
-Andrew.

salgado, please don't add PENDINGUPLOAD to the list of default statuses (nor NEEDINFO, as mentioned later. :)

The statuses one will want to see will depend on one's goal. Presenting results that are useful filtered WRT status depend on presenting a UI to the user that aligns to those goals. Right now, if you're goal is "I want to find out if my bug has already been reported", you should always be doing that search from the "All bugs ever reported" link:

    https://launchpad.net/products/malone/+bugs-all

Of course, as a user, it's easy to not realize that this is the right place to do this.

I think the real problem as pertains to this specific bug is that there's no good UI to lead the user down the golden path of answering the question "has this bug I'm about to file already been reported?"

Thoughts?

The 5c answer would be adding that link to the file-a-new-bug forms.

The 5000$ answer is implementing the guided bug entry form (with the "keywords" input phase, which is critical here) and offering it as the default file-a-new-bug to the user.

Le 29-Nov-05 à 9:59 AM, Christian Reis a écrit :

> Public bug report changed:
> https://launchpad.net/malone/bugs/3620
>
> Comment:
> The 5c answer would be adding that link to the file-a-new-bug forms.
>
> The 5000$ answer is implementing the guided bug entry form (with the
> "keywords" input phase, which is critical here) and offering it as the
> default file-a-new-bug to the user.

I'd much prefer to just do the user a favour here and go straight for
the guided bug form.

Any objections?

Cheers,

--
Brad Bollenbach

On Tue, Nov 29, 2005 at 08:48:05PM -0000, Brad Bollenbach wrote:
> I'd much prefer to just do the user a favour here and go straight for
> the guided bug form.

Yes, that's long-overdue and will probably benefit users most. Let's
work on that as soon as the migration blockers are finished.

Do you want to mutate this bug or file a new one?

Another point to the discoverability is the concept of "recently closed". In todays case, I reported a bug that had been marked as "fix released", but hadn't actually made it to the archive yet.

Tks,
Jeff Bailey

To address the issue of avoiding duplicates it'd help to have the last 10 open bugs of that product/package on the +filebug page.

I do not agree that the later bug duplicates the earlier one.

There would be partial overlap (and only partial) if and only if
the developer acted on the remark of Daniel Holbach at
2006-03-15 05:18:35 EST (that is, over six months ago) in the
discussion of bug #3620.

By the way, I put in over half hour's effort looking for bugs
about Malone's design prompting duplicates before I filed my
own. The experience bolsters the point that I am trying to make.

From my point of view, the partial overlap acknowledged above is
insufficient to warrant marking the new report a duplicate.
Fixing the problems identified in bug #69157 would not close bug #3620.

I have been using Ubuntu long enough that I no longer remember the precise mechanics of the Debian BTS (bug Tracking System) :-), but I do recall that both the web interface and the CLI script (reportbug) presented the user a long list of bugs on a package before prompting input of a new bug.

Released to the public a while ago. Enjoy +filebug!