launchpad development|
Size: 1643
Comment:
|
Size: 6862
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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 = |
= Bug Notifications and Subscriptions: Less Noise, More Control = |
| Line 7: | Line 5: |
| ##'''On Launchpad:''' ''hyperlink to a blueprint, normally'' |
|
| Line 11: | Line 7: |
| '''so that ''' I can get less noise and higher qaulity notices from Launchpad.<<BR>> | '''so that ''' I can get less noise and higher quality notices from Launchpad.<<BR>> |
| Line 13: | 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 15: | Line 13: |
| ''Consider clarifying the feature by describing what it is not?'' | 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 (e.g. [[http://launchpad.net/bugs/137408|bug 137408]], [[http://launchpad.net/bugs/164196|bug 164196]], [[http://launchpad.net/bugs/195423|bug 195423]]) * some are only a little useful (e.g. [[http://launchpad.net/bugs/97633|bug 97533]]) * don't tell me about my own actions ([[http://launchpad.net/bugs/548|bug 548]]) * do provide individual control over the kinds of notifications |
| Line 19: | Line 25: |
| ''Why are we doing this now?'' | === Why now? === |
| Line 21: | Line 27: |
| ''What value does this give our users? Which users?'' | 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. |
| Line 25: | Line 41: |
| ''Who really cares about this feature? When did you last talk to them?'' | === 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 * bryce * leanne * cjwatson * pitti * seb128 * ubuntu server team * ubuntu kernel team * keybuk (Note: too much bug mail became a serious problem to the end of 10.04 LTS) * Elliot Murphy (or someone on his team) === When did we last talk to these stakeholders? === Only bdmurray has been consulted so far, and only in preparation for this story. |
| Line 29: | Line 63: |
| ''What MUST the new behaviour provide?'' | === This Feature Provides === |
| Line 31: | Line 65: |
| ''What MUST it not do?'' | * Subscribe to HIGH or CRITICAL bugs for a package, project, distribution, etc. * Subscribe to a tag ([[http://launchpad.net/bugs/151129|bug 151129]]) * Subscribe to search results (related to [[http://launchpad.net/bugs/49752|bug 49752]]) |
| Line 33: | Line 69: |
| == Subfeatures == | ''-- The first two are special cases of the third. -mpt'' |
| Line 35: | Line 71: |
| ''Other LaunchpadEnhancementProposal``s that form a part of this one.'' | * Only subscribe to certain notices, e.g. * "tell me about change in status, importance, or comments, but not linked branches" * "tell me only about bug creation and transitions TO or FROM a final status" * These should be available for both bugs and structural subscriptions === This Features Does Not Provide === I don't think this feature should allow unlimited configuration for notifications. By that, I mean, you could select to be informed of importance changes, but not certain notice changes, i.e. you would not be able to say "tell me when this bug changes from UNDECIDED" or "from WISHLIST to HIGH" or some other very specific choice. We would have a couple of often demanded statuses pre-configured, i.e. HIGH and CRITICAL for structural subscriptions. ''Note from kfogel: we might want to reconsider unlimited configuration. If we can get the UI right, this would be very powerful, because it would enable many different kinds of stakeholders to satisfy their needs. The notification requirements of Ubuntu packagers might be very different from those of, say, hardware manufacturers.'' * ''jml agrees'' * ''deryck, who wrote the original not-unlimited-options proposal, agrees that we should make the subscription system as flexible as possible. As I understand from our design conversations, this is the plan. The original intent of my comment saying we should limit options was to say, let's be opinionated about what options are available in a "subscribe me" widget. We have to make choices there, obviously, and if we offer too many options to cover every possible use case, the widget becomes too complex to be useful for quickly subscribing to individual bugs or project/package bugs. I assumed subscribing to search results would cover the group who wants specific, perhaps uncommon, notifications. ##== Subfeatures == ##''Other LaunchpadEnhancementProposal``s that form a part of this one.'' |
| Line 39: | Line 92: |
| ''What are the workflows for this feature?'' ''Provide mockups for each workflow.'' |
=== Bug page === |
| Line 42: | Line 94: |
| '''''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.''''' | New subscription: * A user clicks "Subscribe" * An overlay appears with the various options * The user makes choices, clicks "subscribe" on the overlay * The user is subscribed to the bug with those options Existing subscriptions: * A user clicks "Edit Subscription" * An overlay appears with the various options * The user changes the choices and clicks "Update subscription" * The changes take effect === Packages, Projects === New subscription: * A user clicks "Subscribe" * An new page is loaded with the various options * The user makes choices, clicks "subscribe" on the form * The user is subscribed to the bug with those options and redirected back to the bugs homepage for the object Existing subscriptions: * A user clicks "Edit Subscription" * An new page is loaded with the various options * The user changes the choices and clicks "Update subscription" * The changes take effect and the user is redirected to the bugs homepage for the object === Distributions === * Structural subscriptions would be disallowed except for a team (to allow mailing list subscriptions to all bug notices) '''''Mockups will be added during the design phase.''''' |
| Line 50: | Line 137: |
| == Thoughts? == | Possibilities: |
| Line 52: | Line 139: |
| ''Put everything else here. Better out than in.'' | * less bug mail for pitti, seb128 * less mail to ubuntu-bugs * how much feature is used * how many packages lack subscribers * On staging, 6818 Ubuntu source packages out of 34423 have subscribers [<<Date(2010-04-21T13:28:16Z)>>] * `SELECT COUNT(DISTINCT sourcepackagename) FROM structuralsubscription WHERE distribution = 1;` * `SELECT COUNT(*) FROM sourcepackagename;` * See also http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/annotate/head:/launchpadlib-scripts/packages-without-subscribers.py Useful info to have: * what filters/options are selected? |
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 quality 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 (e.g. bug 137408, bug 164196, bug 195423)
some are only a little useful (e.g. bug 97533)
don't tell me about my own actions (bug 548)
- 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
- bryce
- leanne
- cjwatson
- pitti
- seb128
- ubuntu server team
- ubuntu kernel team
- keybuk (Note: too much bug mail became a serious problem to the end of 10.04 LTS)
- Elliot Murphy (or someone on his team)
When did we last talk to these stakeholders?
Only bdmurray has been consulted so far, and only in preparation for this story.
Constraints
This Feature Provides
- Subscribe to HIGH or CRITICAL bugs for a package, project, distribution, etc.
Subscribe to a tag (bug 151129)
Subscribe to search results (related to bug 49752)
-- The first two are special cases of the third. -mpt
- Only subscribe to certain notices, e.g.
- "tell me about change in status, importance, or comments, but not linked branches"
- "tell me only about bug creation and transitions TO or FROM a final status"
- These should be available for both bugs and structural subscriptions
This Features Does Not Provide
I don't think this feature should allow unlimited configuration for notifications. By that, I mean, you could select to be informed of importance changes, but not certain notice changes, i.e. you would not be able to say "tell me when this bug changes from UNDECIDED" or "from WISHLIST to HIGH" or some other very specific choice.
We would have a couple of often demanded statuses pre-configured, i.e. HIGH and CRITICAL for structural subscriptions.
Note from kfogel: we might want to reconsider unlimited configuration. If we can get the UI right, this would be very powerful, because it would enable many different kinds of stakeholders to satisfy their needs. The notification requirements of Ubuntu packagers might be very different from those of, say, hardware manufacturers.
jml agrees
deryck, who wrote the original not-unlimited-options proposal, agrees that we should make the subscription system as flexible as possible. As I understand from our design conversations, this is the plan. The original intent of my comment saying we should limit options was to say, let's be opinionated about what options are available in a "subscribe me" widget. We have to make choices there, obviously, and if we offer too many options to cover every possible use case, the widget becomes too complex to be useful for quickly subscribing to individual bugs or project/package bugs. I assumed subscribing to search results would cover the group who wants specific, perhaps uncommon, notifications.
Workflows
Bug page
New subscription:
- A user clicks "Subscribe"
- An overlay appears with the various options
- The user makes choices, clicks "subscribe" on the overlay
- The user is subscribed to the bug with those options
Existing subscriptions:
- A user clicks "Edit Subscription"
- An overlay appears with the various options
- The user changes the choices and clicks "Update subscription"
- The changes take effect
Packages, Projects
New subscription:
- A user clicks "Subscribe"
- An new page is loaded with the various options
- The user makes choices, clicks "subscribe" on the form
- The user is subscribed to the bug with those options and redirected back to the bugs homepage for the object
Existing subscriptions:
- A user clicks "Edit Subscription"
- An new page is loaded with the various options
- The user changes the choices and clicks "Update subscription"
- The changes take effect and the user is redirected to the bugs homepage for the object
Distributions
- Structural subscriptions would be disallowed except for a team (to allow mailing list subscriptions to all bug notices)
Mockups will be added during the design phase.
Success
How will we know when we are done? How will we measure how well we have done? Possibilities: On staging, 6818 Ubuntu source packages out of 34423 have subscribers [2010-04-21] SELECT COUNT(DISTINCT sourcepackagename) FROM structuralsubscription WHERE distribution = 1; SELECT COUNT(*) FROM sourcepackagename; Useful info to have:
