launchpad development|
Size: 2940
Comment:
|
Size: 10733
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| ''We should make subscribing to bugs something people want to do, not dread.'' | '''''Note: this LEP was approved a long time ago. It is now being updated, and the updates are in draft form at this time.''''' We should make subscribing to bugs something people want to do, not dread. '''Contact:''' GaryPoster and [[yellow|the Yellow squad]]<<BR>> '''Originally Drafter:''' Deryck Hodge <deryck.hodge@canonical.com> <<BR>> '''On Launchpad:''' The [[https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=story-better-bug-notification|story-better-bug-notification tag]]. |
| Line 7: | Line 13: |
| '''so that ''' I can get less noise and higher qaulity notices from Launchpad.<<BR>> | '''so that ''' I can have an easier time following exactly what I care about in Launchpad.<<BR>> |
| Line 13: | Line 19: |
| There are two parts to this story -- '''less noise''' and '''more control'''. | We are taking two primary approaches to these goals. |
| Line 15: | Line 21: |
| 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 |
* ''Forward-looking action'': Provide more control over subscriptions, so you get fewer unwanted notifications. * ''Experience-based reaction'': Provide a way to understand why you got a particular notification, and a way to react to it so you don't get notifications like it again. |
| Line 22: | Line 24: |
| In addition, we will make a small effort to do better batching of notifications. If people get fewer Launchpad notifications that do not interest them, they will have an easier time finding and following the bugs and other events that they do care about. |
|
| Line 35: | Line 40: |
| 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. |
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 and follow bugs that interest them. |
| Line 41: | Line 44: |
| ''Who really cares about this feature? When did you last talk to them?'' | === Who will care about this work? === |
| Line 46: | Line 49: |
| * bryce | |
| Line 49: | Line 53: |
| * seb123 | * seb128 |
| Line 52: | Line 56: |
| * keybuk | * keybuk (Note: too much bug mail became a serious problem to the end of 10.04 LTS) * Elliot Murphy (or someone on his team) |
| Line 54: | Line 59: |
| XXX - someone from an upstream project? | === When did we last talk to these stakeholders? === |
| Line 56: | Line 61: |
| == Constraints == | Only bdmurray has been consulted so far, and only in preparation for this story. |
| Line 58: | Line 63: |
| ''What MUST the new behaviour provide?'' | We hope to use iterative user interface testing to get early input into the work from selected stakeholders, and alpha testing for later input. The alpha testing group is [[https://launchpad.net/~malone-alpha|malone-alpha]]. |
| Line 60: | Line 65: |
| ''What MUST it not do?'' | == Constraints and Requirements == === Must === * Users can subscribe to '''individual bugs''', choosing to filter by '''events'''. They can receive all notifications as they do now ("the bug receives any change"), or to only receive notifications if the "bug is opened, closed, or reopened," or to only receive notifications if the "bug is changed in any way other than a simple comment." (See further discussion on this in "Nice to have.") * Users can subscribe to notifications on the bugs of projects, packages, and distributions ('''"structural subscriptions"''') with any of the following '''filters''', intersected. [[Bug 674422]] * Only subscribe to certain '''events''' that trigger a notification. Choose one among these options: "bug is opened, closed, or reopened", "the bug is changed in any way other than a simple comment", or "the bug receives any change." (See further discussion on this in "Nice to have.") * Only subscribe to notifications that happen on bugs that are tagged with any of one or more '''tags''' (or gain or lose these tags). (See further discussion on this in "Nice to have.") [[Bug 151129]] * Only subscribe to notifications that happen on bugs that have any of one or more selected '''statuses''' (or move to or from these statuses). * Only subscribe to notifications that happen on bugs that have any of one or more selected '''importances''' (or move to or from these importances). * '''Users can make multiple bug notification subscriptions for the same project, package, or distribution'''. Each can have different fliters as described above. Multiple subscriptions that overlap result in only a single notification. This means that, for instance, you can subscribe to all bug notifications in the Launchpad project that have the UI tag, and also bug notifications in the Launchpad project that show when a bug is opened or closed with the tag "bugjam2011". If a notification matches both subscriptions, you only get one copy of the notification. * Users can '''edit and delete these subscriptions'''. * Users can '''"mute" their notifications on individual bugs''', so even if they would normally get a notification for it because of a subscription on a package, for instance, they will not hear notifications about that particular bug. [[Bug 204980]] * '''Each email notification will include a link to a page with all subscriptions that led to the receipt of that email.''' You can mute notifications from that particular bug, or edit or delete the subscriptions that made you receive the email. [[Bug 649252]] * '''Notifications will batch attachments''' that are added to the same bug by the same person within a certain amount of time (five minutes now, AIUI). [[Bug 424849]] === Must not === * Actions that are done and then quickly undone will not generate notification emails [[Bug 164196]] ---------- XXX GaryPoster is working on this and has gotten this far. The "Nice to have" and "Out of scope" sections are only slightly modified, and the rest not at all. ---------- === Nice to have === * 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 === Out of scope === * Subscribe to search results (related to [[http://launchpad.net/bugs/49752|bug 49752]]) 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. * Ahh, ok. That makes sense -- jml |
| Line 64: | Line 111: |
| ''Other LaunchpadEnhancementProposal``s that form a part of this one.'' | (none) |
| Line 68: | Line 115: |
| ''What are the workflows for this feature?'' ''Provide mockups for each workflow.'' |
=== Bug page === |
| Line 71: | Line 117: |
| '''''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 === lp:~gmb/+junk/subscription-widget-mockups/ |
| Line 75: | Line 159: |
| ''How will we know when we are done?'' | === How will we know when we are done? === |
| Line 77: | Line 161: |
| ''How will we measure how well we have done?'' | All critical and high bugs for the [[https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=story-better-bug-notification|story-better-bug-notification tag]] are closed. |
| Line 79: | Line 163: |
| Possibles: | === How will we measure how well we have done? === |
| Line 81: | Line 165: |
| * less bug mail for pitti, seb123 | Possibilities: * less bug mail for pitti, seb128 |
| Line 85: | Line 171: |
| * 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 |
|
| Line 86: | Line 176: |
| Useful info to have: * what filters/options are selected? |
|
| Line 89: | Line 182: |
| ''Put everything else here. Better out than in.'' | * There are at least two axes here. One is "bugs I get told about" and the other is "actions on a bug that I get told about". |
Bug Notifications and Subscriptions: Less Noise, More Control
Note: this LEP was approved a long time ago. It is now being updated, and the updates are in draft form at this time.
We should make subscribing to bugs something people want to do, not dread.
Contact: GaryPoster and the Yellow squad
Originally Drafter: Deryck Hodge <deryck.hodge@canonical.com>
On Launchpad: The story-better-bug-notification tag.
As an Ubuntu developer
I want control over my Launchpad subscriptions
so that I can have an easier time following exactly what I care about in 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.
We are taking two primary approaches to these goals.
Forward-looking action: Provide more control over subscriptions, so you get fewer unwanted notifications.
Experience-based reaction: Provide a way to understand why you got a particular notification, and a way to react to it so you don't get notifications like it again.
In addition, we will make a small effort to do better batching of notifications.
If people get fewer Launchpad notifications that do not interest them, they will have an easier time finding and following the bugs and other events that they do care about.
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 and follow 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.
We hope to use iterative user interface testing to get early input into the work from selected stakeholders, and alpha testing for later input. The alpha testing group is malone-alpha.
Constraints and Requirements
Must
Users can subscribe to individual bugs, choosing to filter by events. They can receive all notifications as they do now ("the bug receives any change"), or to only receive notifications if the "bug is opened, closed, or reopened," or to only receive notifications if the "bug is changed in any way other than a simple comment." (See further discussion on this in "Nice to have.")
Users can subscribe to notifications on the bugs of projects, packages, and distributions ("structural subscriptions") with any of the following filters, intersected. Bug 674422
Only subscribe to certain events that trigger a notification. Choose one among these options: "bug is opened, closed, or reopened", "the bug is changed in any way other than a simple comment", or "the bug receives any change." (See further discussion on this in "Nice to have.")
Only subscribe to notifications that happen on bugs that are tagged with any of one or more tags (or gain or lose these tags). (See further discussion on this in "Nice to have.") Bug 151129
Only subscribe to notifications that happen on bugs that have any of one or more selected statuses (or move to or from these statuses).
Only subscribe to notifications that happen on bugs that have any of one or more selected importances (or move to or from these importances).
Users can make multiple bug notification subscriptions for the same project, package, or distribution. Each can have different fliters as described above. Multiple subscriptions that overlap result in only a single notification. This means that, for instance, you can subscribe to all bug notifications in the Launchpad project that have the UI tag, and also bug notifications in the Launchpad project that show when a bug is opened or closed with the tag "bugjam2011". If a notification matches both subscriptions, you only get one copy of the notification.
Users can edit and delete these subscriptions.
Users can "mute" their notifications on individual bugs, so even if they would normally get a notification for it because of a subscription on a package, for instance, they will not hear notifications about that particular bug. Bug 204980
Each email notification will include a link to a page with all subscriptions that led to the receipt of that email. You can mute notifications from that particular bug, or edit or delete the subscriptions that made you receive the email. Bug 649252
Notifications will batch attachments that are added to the same bug by the same person within a certain amount of time (five minutes now, AIUI). Bug 424849
Must not
Actions that are done and then quickly undone will not generate notification emails Bug 164196
XXX GaryPoster is working on this and has gotten this far. The "Nice to have" and "Out of scope" sections are only slightly modified, and the rest not at all.
Nice to have
- 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
Out of scope
Subscribe to search results (related to bug 49752)
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.
- Ahh, ok. That makes sense -- jml
Subfeatures
(none)
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
lp:~gmb/+junk/subscription-widget-mockups/
Success
How will we know when we are done?
All critical and high bugs for the story-better-bug-notification tag are closed.
How will we measure how well we have done?
Possibilities:
- 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 [2010-04-21]
SELECT COUNT(DISTINCT sourcepackagename) FROM structuralsubscription WHERE distribution = 1;
SELECT COUNT(*) FROM sourcepackagename;
Useful info to have:
- what filters/options are selected?
Thoughts?
- There are at least two axes here. One is "bugs I get told about" and the other is "actions on a bug that I get told about".
