Improving

Differences between revisions 13 and 14
Revision 13 as of 2011-03-20 02:36:39
Size: 4000
Editor: c-98-243-11-175
Comment: Minor grammar fixes
Revision 14 as of 2019-12-11 08:41:22
Size: 4003
Comment: Grammar
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
Ubuntu doesn't have the resources address every bug, so we want to focus our resources on the bugs we really need to fix. Having tens of thousands of bug reports in the system which we can't and won't get to is not constructive, and it makes the bug fixing we CAN do less efficient. We focus our effort on bugs introduced in the Ubuntu packaging process, or specific to the Ubuntu versions of packages, and bugs which create very significant issues for many users. We also focus attention on bugs which are well-defined and complete, because those are the ones developers have the best chance of addressing in a reasonable time. Ubuntu doesn't have the resources to address every bug, so we want to focus our resources on the bugs we really need to fix. Having tens of thousands of bug reports in the system which we can't and won't get to is not constructive, and it makes the bug fixing we CAN do less efficient. We focus our effort on bugs introduced in the Ubuntu packaging process, or specific to the Ubuntu versions of packages, and bugs which create very significant issues for many users. We also focus attention on bugs which are well-defined and complete, because those are the ones developers have the best chance of addressing in a reasonable time.

information_little.png This page is part of the Bug Squad’s KnowledgeBase - pages with information about how to triage bugs.

Improving a bug report

Part of the bug triaging process involves ensuring that the bug is valid, well described, and contains adequate information for a developer to start working on it.

To be considered complete, a bug report should normally contain:

  • The version of Ubuntu that the reporter is running
  • The version of the package the reporter is using
  • The actions taken to produce the problem
  • Whether or not it is possible for the reporter to reproduce the bug
  • The expected result of these actions
  • The actual result of these actions

Not every bug reported contains all this information though. So as triagers we should ask for all of the above if they are missing. Sometimes a particular piece of information may be clear from the rest of the report, or clearly not needed for a particular report. A good test is to see if you can reproduce the bug yourself on the basis of the available information. If in doubt, it may be better to discuss with the reporter before marking the bug as incomplete.

Additionally, certain classes of bugs and specific packages require more detailed information like configuration and log files. The DebuggingProcedures page contains a list of links to detailed information to gather.

Since most reports probably won't be complete, you'll have to start a conversation with the bug reporter. Ask the reporter for more information by doing the following:

  • Click on the bug task name, which is usually the package name, in the yellow horizontal line.
  • Change the "Status" field to "Incomplete".
  • Ask for the additional information required in the "Comment on this change" field.
  • Click the "E-mail me about changes to this bug report" check box, so that you'll be subscribed to the bug
  • Click "Save changes".

As a subscriber to the bug, you will be e-mailed when the reporter responds.

Even if the bug report is complete it could probably still use some improvement.

  • Is the bug's summary descriptive of the bug? This will help people find bugs easier.
    • consider "no r5xx support in radeon driver (X1300, X1400, X1600, X1800, X1900, X1950)" vs

    • "update-manager" or "Screen Saver Issues" or "Buffer I/O Error"

Incomplete bug expiration

Ubuntu doesn't have the resources to address every bug, so we want to focus our resources on the bugs we really need to fix. Having tens of thousands of bug reports in the system which we can't and won't get to is not constructive, and it makes the bug fixing we CAN do less efficient. We focus our effort on bugs introduced in the Ubuntu packaging process, or specific to the Ubuntu versions of packages, and bugs which create very significant issues for many users. We also focus attention on bugs which are well-defined and complete, because those are the ones developers have the best chance of addressing in a reasonable time.

Also, many bugs are fixed from release to release because they are addressed in new upstream releases which get packaged for the new Ubuntu release. It can be difficult to get the attention of the bug reporter if they have upgraded to a new version. However, it is important to try and establish if an incomplete bug has been addressed in a new version.

Therefore, bugs which are marked Incomplete will eventually be "expired", and drop off the primary reporting lists for developer attention.

If a bug is not fully defined, please set it to Incomplete and ask if it is still valid. If a new release of Ubuntu has been made, it is also reasonable to ask if the bug still manifests in the new release and set the bug to Incomplete. Unless the reporter resets the bug status the bug report will be set to expire.

Bugs/Improving (last edited 2019-12-11 08:41:22 by aurelien-lourot)