• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Disable Filebug Duplicate Search

Users are not always able to tell if a bug is really a dupe, and the dupe finder encourages user to mark bugs as duplicates.

As a maintainer of complex pieces of Ubuntu
I want to disable the file bug dupe finder on my package
so that users do not incorrectly mark their bug a duplicate of another bug.

This request is tracked as Bug 596944.

Rationale

Why now?

This has been requested through the stakeholders process and it is the next item for the Launchpad bugs team. Also, noise in bugs continues to be a problem and we need to begin taking steps to correct this problem.

What value does this bring to users?

Users will have a better chance of getting their bugs fixed and/or getting better feedback from maintainers and developers of Ubuntu if their bugs are not incorrectly marked as a duplicate of a bug that seems similar but in fact is not the same bug.

Stakeholders

• JFo
• bryceh
• marjo

Constraints and Requirements

Must

It must be possible for project or package maintainers to turn off the dupe finder that suggests possible duplicates when filing a bug.

Must not

This must not be turned off by default. Projects and packages need to opt in to this behavior. Configuring this must not be overly complex.

Subfeatures

This feature also includes discussion on:

• Enable Bug Supervisor ACL for Mark As Duplicate

Workflows

1. A project maintainer will have a "Disable duplicate detection when users file bugs" switch in the configure bug tracker page.
2. Users who file bugs on projects with this enabled will be take directly to the file bug form, without being prompted to search.

Success

How will we know when we are done?

We will be done once we can turn of the filebug dupe finder for projects and packages that want this.

How will we measure how well we have done?

We will have done well if maintainers and triagers who work on hardware-related or complex pieces of software spend less time than they currently do marking or un-marking a bug a duplicate.

Thoughts?

When this was discussed at UDS, this topic got mixed in heavily with general noise in bugs. It might be worth distinguishing what these changes can do versus what they can't in terms of this noise.