Allow project-/package-specific bug-reporting guidelines

The same applies to products, projects (possibly), and distributions (possibly).

See also bug 3383.

I agree that this is useful.

I think there is a use case for having either a textarea inside LP to enter this, or an external link to a document that's already written and kept up-to-date.

Maybe we should allow either possibility when specifying reporting guidelines? It's true that even in a textarea you could simply say:

Please see http://...

but that seems somewhat undiscoverable.

On the other hand, making it a link to an external page would make it much less likely to be read; better for the isntructions to be included in the bug reporting page itself. (This would also encourage maintainers to keep the instructions short, whereas wiki pages invite longwindedness.)

I'd like to see this too. My particular case is the new live CD installer in Dapper, /distros/ubuntu/+source/ubiquity. To increase the quality of crash reports beyond "the installer disappeared and I don't know why", I included a crash dialog that directs users to /distros/ubuntu/+source/ubiquity/+filebug and gives them a traceback to copy and paste into the report. This has meant I caught a lot of bugs before release that I otherwise wouldn't have caught due to time wasted in back-and-forth with reporters; on the other hand, it does result in a lot of duplicate bugs, because my experience is that non-developers can't reliably tell apart similar-but-different tracebacks and so I actively don't want Ubiquity users searching for duplicates.

On the other hand, it's possible to collect a higher-level list of known issues that's orders of magnitude easier for users to deal with than searching for duplicate bugs, and won't get harder to use over the three-year lifetime of Dapper on the desktop in which I expect to close rather a lot of the currently-outstanding bugs that affect Dapper users. I've made a start on this at https://wiki.ubuntu.com/DapperReleaseNotes/UbiquityKnownIssues, and I'd very much like that to be linked from ubiquity's +filebug page. Although I've already linked to it from the main release notes and releases.ubuntu.com, extrapolating from my current inbox load suggests that I will be spending approximately the next three years of elapsed time just dealing with ubiquity/dapper bug reports if I can't make the list of known issues more prominent somehow on the path currently followed by users. The nature of the live CD means that that path is now unfortunately rather difficult to change, and updates are difficult to publish in a way that the majority of users will see them without help.

I take Matthew's point that users won't necessarily follow external links, although I think perhaps bug reporting instructions and condensed lists of known issues are slightly different use cases for similar underlying functionality. In the case of a list of known issues, it would be very easy for the list to become inaccurate if it had to be maintained in two places, and the list is liable to grow reasonably lengthy just due to the number of items without necessarily being longwinded as well.

This issue was brought up by the Python infrastructure committee while discussing features they'd like for their bug tracker. Perhaps we could bump the priority up a bit?

I think the use case of wanting to explain good bug filing practices via a wiki page or text field in LP is a good idea, so I'll mark this confirmed, at least, with more thought required later about how to address the underlying issues.

For example, I've noticed that many of the bug reports linked in the Ubiquity known issues doc would score very highly with "bug heat", a score based on things like number of subscribers, number of dupes, and other signs of a bug's gravitational pull.

The work I'm doing on a guided bug workflow will show, at least initially, only the "most common" (i.e. most duped) bugs, because a heat query could be too expensive for our current db model, since this is not yet a score cached in the Bug table.

So this solution could help address the "Known Issues" use case when reporting a bug (except for those who would actively avoid the guided bug workflow. :P)

Brad: the guided bug workflow will no doubt help with bug submission, but it seems orthogonal to the issue of providing product/source package specific instructions.

Seeing existing bug reports isn't really a substitute for being told to attach the output of "dmesg" to new kernel bug reports, or include the OOPS ID in Launchpad bug reports.

As I say, the "Most Common Bugs" aspect of the guided bug workflow can help address the part of this use case that Colin mentioned earlier, where he gave an example of a "Known Issues" document he wanted to link to.

(Anyway, I meant only to mention in passing some other changes going on that will help solve the underlying issues around this use case, not to spawn a subthread of discussion on the guided filebug workflow. :)

I agree that this is very important. Some key information to the submitter early on might several round trips of bug triage.

I've made such a guide to attaching ubiquity logs: https://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs (which for that particular package is a key message to get across)

I also agree that this is very important. It plays a rather important role for the distro team, Elliot's team, and other projects in Launchpad. Perhaps we can have Gavin work on this?

Yeah, I think it Gavin could take this one.

I'm a little unsure as to why bug #3383 was forward duped on this one. That bug allows you to date the age of this request a little bit better and the discussion here was not dramatically greater...

Just to put it in the report, there is a great collection of per-package information in the wiki:
https://wiki.ubuntu.com/KernelTeamBugPolicies?action=fullsearch&context=180&value=debugging&titlesearch=Titles

Just moving the information from those pages into Malone would be a great start.

Gavin, can this be scheduled for an upcoming release? I think this will need some further discussion with the distro team to agree upon a usable design.

Joey, the relevant spec (https://launchpad.net/malone/+spec/custom-bug-filing-instructions) is already targeted to 1.1.12, so I've done the same for this bug. I spoke with Bjorn and he felt that there had been enough discussion already, so I'll implement current thinking for 1.1.12.

We're going to start with adding bug filing guidelines for only projects and distributions and see how it goes. Doing the same for packages is covered in https://blueprints.edge.launchpad.net/malone/+spec/custom-bug-filing-instructions, which is scheduled for later.

A single set of instructions will be shown both on the front +filebug page and by the description field on subsequent pages. For the guided +filebug, the instructions will only appear when "No, I'd like to report a new bug" is selected. The instructions themselves will be editable via Change Details.

Am I missing something, or has the original point of this bug been ignored? Distribution source packages were what this was originally filed for, and what it would be very useful for, but they have been left out of the implementation.

William Grant, you're right. The title is misleading, but guidelines for packages is scheduled to be done too. See Björn's most recent comment for more details.

Reopening based on the last four comments. The initial use case reported in this bug was guidelines specific to the kernel package, and that has not been implemented.

Recently Ubuntu bugs are quite often mistakenly reported against ubuntu-website.
A description shown on a +reportbug page would help to prevent it.

Package-specific guidelines landed in r7300.

Package specific bug-reporting guidelines have landed on the production server now so I am setting this bug's status to Fix Released.

I don't see any UI, nor is it exposed in the API.

<https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+filebug#form-start> contains package-specific guidelines, so presumably it's possible for someone to enter them. If the ability is restricted to too few people, perhaps report that as a separate bug with specific examples.

On Mon, 2008-12-01 at 18:40 +0000, Brian Murray wrote:
> Package specific bug-reporting guidelines have landed on the production
> server now so I am setting this bug's status to Fix Released.

Should we file a new bug then, for project-specific bug reporting guidelines?

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

2009/1/6 Robert Collins <email address hidden>:
> On Mon, 2008-12-01 at 18:40 +0000, Brian Murray wrote:
>> Package specific bug-reporting guidelines have landed on the production
>> server now so I am setting this bug's status to Fix Released.
>
> Should we file a new bug then, for project-specific bug reporting
> guidelines?

We've had those for ages. With packages, now all bug targets can have
guidelines.

Robert: you got those long ago - see https://bugs.launchpad.net/malone/+bug/43893/comments/16 and subsequent comments.

On Tue, 2009-01-06 at 00:37 +0000, Colin Watson wrote:
> Robert: you got those long ago - see
> https://bugs.launchpad.net/malone/+bug/43893/comments/16 and subsequent
> comments.

Oh, thanks :). I'm embarassed to have missed that.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

As for setting bug_reporting_guidelines, it is exposed in the API, but currently broken: see bug 309056.

Although I've been unable to test it, it looks like working code should be something like this (given launchpad as an appropriately-credentialled launchpadlib client instance; code for that is elsewhere, e.g. https://help.launchpad.net/API/launchpadlib):

  src = launchpad.distributions['ubuntu'].getSourcePackage(name='whatever')
  src.bug_reporting_guidelines = 'foo\n'
  src.lp_save()

On Tue, 06 Jan 2009 01:19:40 -0000
Colin Watson <email address hidden> wrote:

> As for setting bug_reporting_guidelines, it is exposed in the API, but
> currently broken: see bug 309056.

Fwiw, the fix for this is committed, but because edge is not updating at
the moment (dependency issue) this has not made it, which is pretty
annoying! As soon as edge updates this fix will be released. Sorry for
the delay.