Diff for "LEP/BetterBugSubscriptionsAndNotifications"

Not logged in - Log In / Register

Differences between revisions 2 and 3
Revision 2 as of 2010-03-05 17:24:47
Size: 1712
Editor: jml
Comment: page was renamed from LEP/BetterBugSupscriptionsAndNotifications
Revision 3 as of 2010-03-05 17:29:18
Size: 2008
Editor: jml
Comment:
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
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?

The purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess.

Better Bug Subscriptions and Notifications

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.

note: there is the upstream dev story to consider, too, i.e. making subscribing to my software's package more attractive.

Consider clarifying the feature by describing what it is not?

Rationale

Why are we doing this now?

What value does this give our users? Which users?

Stakeholders

Who really cares about this feature? When did you last talk to them?

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?

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?

Thoughts?

Put everything else here. Better out than in.

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