launchpad development|
Size: 2512
Comment:
|
Size: 2276
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from LEP/BetterBugSupscriptionsAndNotifications The purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess. |
|
| Line 7: | Line 4: |
##'''On Launchpad:''' ''hyperlink to a blueprint, normally'' |
|
| Line 14: | Line 9: |
| '''note:''' there is the upstream dev story to consider, too, i.e. making subscribing to my software's package more attractive. | '''As an ''' upstream developer<<BR>> '''I want ''' control over what information I get from Launchpad<<BR>> '''so that ''' I can easily find bugs related to my software.<<BR>> |
| Line 16: | Line 13: |
| ''Consider clarifying the feature by describing what it is not?'' | There are two parts to this story -- '''less noise''' and '''more control'''. |
| Line 18: | Line 15: |
| less email in general | So: |
| Line 23: | Line 20: |
| * individual control over the kinds of notifications | * do provide individual control over the kinds of notifications |
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.
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 are we doing this now?
What value does this give our users? Which users?
bdmurray says, "people subscribe mostly to packages, but still get too much mail"
XXX: confirm this with database queries
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?
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.
