Diff for "LEP/BetterBugSubscriptionsAndNotifications"

Not logged in - Log In / Register

Differences between revisions 8 and 9
Revision 8 as of 2010-03-16 13:33:39
Size: 2940
Editor: deryck
Comment:
Revision 9 as of 2010-03-16 13:43:34
Size: 3046
Editor: deryck
Comment:
Deletions are marked like this. Additions are marked like this.
Line 41: Line 41:
''Who really cares about this feature? When did you last talk to them?'' === Who will care about this work? ===
Line 55: Line 55:

=== When did we last talk to these stakeholders? ===

Only bdmurray has been consulted so far, and only in preparation for this story.

Bug Notifications and Subscriptions: Less Noise, More Control

We should make subscribing to bugs something people want to do, not dread.

As an Ubuntu developer
I want control over my Launchpad subscriptions
so that I can get less noise and higher qaulity notices from Launchpad.

As an upstream developer
I want control over what information I get from Launchpad
so that I can easily find bugs related to my software.

There are two parts to this story -- less noise and more control.

So:

  • don't tell me about little things
    • some aren't ever useful
    • some are only a little useful
  • don't tell me about my own actions
  • do provide individual control over the kinds of notifications

Rationale

Why now?

This story was taken up after consultation with Brian Murray, representing Ubuntu Platform QA. Launchpad's current focus is Getting Bugs Off Ubuntu. As a feature slot came open for development, we asked Brian what would help Ubuntu best manage the amount of bugs they have. He said, better bug subscribing and notifications.

Brian says, "people subscribe mostly to packages, but still get too much mail"

Stats from DB confirm packages are the most subscribed to: https://pastebin.canonical.com/29229/

What value does this bring?

Fixing bug notifications to be less noisy and bug subscribing to allow finer grained controls will allow people to manage the high volume of bugs against packages. This brings value to both Ubuntu and upstream developers by allowing people to better find bugs that interest them.

Stakeholders

Who will care about this work?

In particular, Ubuntu developers who are subscribed to large numbers of packages. In general, anyone who receives a lot of bug mail.

  • bdmurray
  • leanne
  • cjwatson
  • pitti
  • seb123
  • ubuntu server team
  • ubuntu kernel team
  • keybuk

XXX - someone from an upstream project?

When did we last talk to these stakeholders?

Only bdmurray has been consulted so far, and only in preparation for this story.

Constraints

What MUST the new behaviour provide?

What MUST it not do?

Subfeatures

Other LaunchpadEnhancementProposals that form a part of this one.

Workflows

What are the workflows for this feature? Provide mockups for each workflow.

You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.

Success

How will we know when we are done?

How will we measure how well we have done?

Possibles:

  • less bug mail for pitti, seb123
  • less mail to ubuntu-bugs
  • how much feature is used
  • how many packages lack subscribers

Thoughts?

Put everything else here. Better out than in.

LEP/BetterBugSubscriptionsAndNotifications (last edited 2011-03-21 12:55:00 by danilo)