VersionThreeDotO/Bugs/StoryCards

Not logged in - Log In / Register

Revision 10 as of 2009-02-11 18:29:04

Clear message

Story cards for the Launchpad Bugs team.

HWDB

The Hardware Database is used to help triagers and developers to see which devices aren't working well, decide whether there are enough users with a device to warrant support, get more debug information, etc.

Get number of affected users by a bug tied to a device

    As a kernel developer,
    I want to know how many users are using a certain PCI or USB device,
    so that I know how how well we need to support the device.

Story Points:

Bug Tag: story-hwdb-affected-users

Notes
  • Needs to be able to filter on distro series, since a bug fix may be needed in a stable series, if there are many users being affected by that bug using an older series.

Include DMI and lspci information in HWDB submissions

    As a kernel developer,
    I want to know the DMI and lspci data,
    so that I can easier debug a problem reported by a user.

Story Points:

Notes
  • Needs DMI and lspci data
  • Access to raw submission via API OK

Find out which computers have a certain device

    As a QA team member,
    I want to know which of the machines in our certification lab has device X
    installed,
    so that i can run tests with the most recent version of package Y.

Story Points:

Notes
  • How do you specify the set of computers you're interested in?

Correlate hardware configurations with bug reports

    As a kernel developer,
    I want to see if a bug correlates with certain hardware configurations
    or drivers,
    so that I can get a better clue where to look for the cause of the bug.

Story Points:

Notes
  • Should the correlation be made by a human by looking from the HWDB submissions manually, or should it be done automatically somehow?

Upstreaming

Being able to forward and link bugs in Launchpad to upstream bug trackers is vital for Ubuntu. The stories here aim to improve that workflow, making it easier to connect bugs that have been reported in Launchpad to bugs in other bug trackers.

    As a bug triager,
    I want to follow a link from Launchpad to file a bug in the upstream bug
    tracker,
    so that I can forward a bug in LP upstream without having to copy and paste
    the description

Story Points:

Notes
  • The links should point to the upstream's filebug page with the description and summary fields pre-filled.
  • The user will need to have an account in the upstream bug tracker
  • Having the link leave LP is OK
  • The link should appear when adding an upstream task

    As a bug triager,
    I want to follow a link from Launchpad to search bugs in the upstream bug
    tracker,
    so that I can find possible duplicates upstream without having to copy and
    paste the summary of the bug in LP

Story Points:

Notes
  • The link should perform a search using the bug summary
  • Having the link leave LP is OK
  • The link should appear when adding an upstream task

    As a project maintainer or bug triager,
    I want to set the remote product in the upstream bug tracker,
    so that users can easily search and file upstream bugs from Launchpad

Story Points:

Notes
  • The triager doesn't have to be able to set it himself. He can file a question to have it done.
  • This feature is useful for correcting links that are wrong.

    As a bug triager,
    I want to get links for filing and searching bugs for projects where no one
    has set the remote product manually,
    so that I don't have to spend time updating all projects I'm interested in.

Story Points:

Notes
  • The script that does it should only set the remote product if it hasn't been set already.

AJAX

AJAX can be used in a number of locations to improve the workflows, and making pages quicker to load.

Inline editing of bug description and summary

    As a bug triager,
    I want to edit both the summary and description inline,
    so that I don't have to wait for the page to load before starting to
    write the new text.

Story Points:

Notes
  • Most of the work will be done by the Foundations team.
  • Should be finished at the AJAX sprint.