LEP/BetterBugSubscriptionsAndNotifications

Not logged in - Log In / Register

Revision 34 as of 2011-01-27 14:55:45

Clear message

Bug Notifications and Subscriptions: Less Noise, More Control

Note: this LEP was approved a long time ago. It is now being submitted for re-approval by the product strategist, so we have a clearer definition of success.

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.

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.

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

Must not

Nice to have (Maybe)

Out of scope

Some of the "Nice to have" elements above may move here.

Subfeatures

(none)

Workflows

Please see the more detailed workflows, including mockups, described in yellow/Subscriptions. The following are the workflows from the original LEP.

Bug page

New subscription:

Existing subscriptions:

Packages, Projects

New subscription:

Existing subscriptions:

Distributions

As mentioned above in the "Nice to have" section, structural subscriptions to a distribution are disallowed except for a team (to allow mailing list subscriptions to all bug notices). We might consider re-opening this, as discussed above.

Mockups

The current mockups can be seen in yellow/Subscriptions.

These are the original 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. These bugs should either be related to the features in the Must or Must Not section, or technical bugs about the implementation of these features.

Features in the "Nice to Have" section may be promoted to "Must" by the Product Strategist at any time, but we are hoping that these will only be promoted when we have delivered, or are about to deliver, the full set of "Must" features. Then the product strategist with the yellow squad can determine if any further increments are desired before the LEP is closed and the squad moves to a bug rotation.

How will we measure how well we have done?

Any other ideas? Other possibilities from the original LEP, which are currently not intended to be used:

Useful info to have:

Thoughts?

Unlimited configuration for notifications?

The following discussion was in an earlier version of the draft. It apparently happened before the team decided that subscription-from-search was out of scope. It seems that the first speaker is Deryck.

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

Dividing filtering

We decided against the following line of thinking, because it led to dividing "filters" off away from "subscriptions". We felt providing a unified interface to what was called was both more understandable and more flexible. In our revised design, you can subscribe multiple times to the notifications on a particular bug target. On each subscription, you can filter based on both the kind of events (which was available on "subscriptions") and on the state of the bug (importances, statuses, and tags, which were available on "filters").

* 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".