launchpad development
Feature review meeting notes 2011-04-25
This starts with all of the "Must" and "Must not" items from the LEP, ordered roughly from most-to-least complete. Each item first lists the description exactly as it is in the LEP. Then whether the item was presented in the last review (and hasn't significantly changed since). Then the status, instructions on how to review, and the outlook for subsequent work follows. Notes are sometimes added where pertinent.
Please consider all proclamations of a feature to be "done" as including "unless told otherwise."
Important general review notes: To view these changes, you should be in a team that is has the two pertinent feature flags turned on, malone.advanced-structural-subscriptions.enabled and malone.advanced-subscriptions.enabled. See https://launchpad.net/+feature-rules for the current teams. As of this writing ~yellow has the first (see https://launchpad.net/~yellow/+members) and ~malone-alpha has the second (see https://launchpad.net/~malone-alpha/+members#active). As of this writing, all members of the product team are believed to be in the necessary teams on both production and staging (not qastaging; staging is needed for reviewing one feature discussed below).
Please see currently filed bugs here: https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=story-better-bug-notification
Please file new bugs with the "story-better-bug-notification" tag and prioritize as you deem fit. As a reminder, high and critical bugs must be closed before we declare this work done, so any bugs marked with that priority will either need to be closed, retagged, or lowered in priority before we leave.
Users can filter out notifications generated because of a change they made themselves
Description
Users can filter out notifications generated because of a change they made themselves. This will be a global choice for each user. 548
Review
Status: Deployed for all users. Announced.
Presented: Yes
To review: please see the blog post. http://blog.launchpad.net/general/silencing-bug-notifications-for-stuff-you-did
Outlook: Done.
Actions that are done and then quickly undone will not generate notification emails
Description
Actions that are done and then quickly undone will not generate notification emails 164196
Review
Status: Deployed for all users. Announced.
Presented: Yes
To review: Make a change to a bug to which you are subscribed, such as adding a tag or changing a status. Immediately undo that change. You will not receive an email about it. Also see the blog post. http://blog.launchpad.net/notifications/another-bug-email-improvement-no-notification-for-quickly-corrected-mistakes
Outlook: Done.
subscribe to individual bugs, choosing to filter by events
Description
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." Note that we may want to expand the most minimal filter, "bug is opened, closed, or reopened," to include moving to "incomplete," so that people filing bugs can see when more information is requested. (See further discussion on event filtering in "Nice to have.")
Review
Status: Deployed on production for malone-alpha users.
Presented: Yes
To review: Go to a bug, e.g. https://bugs.launchpad.net/launchpad/+bug/674422 . Click "+ Subscribe", from the portlet third down on the right hand side. You will see the option displayed in an overlay.
Outlook: Done.
Notes: This is simply a completion of the plans from the former bugs team, with no changes.
"mute" their notifications on individual bugs
Description
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. 204980
Review
Status: Deployed on production and staging for malone-alpha.
Presented: Yes
To review: Go to a bug, such as https://bugs.launchpad.net/launchpad/+bug/674422 . Click on "- Mute bug mail" from the portlet third down on the right side. You should now no longer receive any email for this bug, whatever the source (tested/qa'd). Click on "Unmute bug mail" in the same location to undo. By the time that you test this on Monday, you should have the option to choose to create/reinstate a direct subscription when unmuting (see notes).
Outlook: Done.
Notes: This is simply a completion of the plans from the former bugs team, with no changes. Graham and I have agreed that the feature's internal design, which is inherited from the bugs team, is not ideal. We feel that a separate mute table would have been a better decision, rather than conflating the ideas of muting email and receiving email, which leads to issues such as the fact that when you stop muting a bug, we can't automatically reinstate the previous direct subscription you had before, because we don't know what level you had. Graham has worked around this nicely, and I think the bang for the buck in changing this is too low to bother with.
At the moment, "Mute bug mail" link will only show up if you are directly set as the bug assignee.
Make filters for structural subscriptions
Description
Users can subscribe to notifications on the bugs of projects, packages, and distributions ("structural subscriptions") with any of the following filters, intersected. 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." Note that we may want to expand the most minimal filter, "bug is opened, closed, or reopened," to include moving to "incomplete," so that people filing bugs can see when more information is requested. (See further discussion on event filtering in "Nice to have.")
Only subscribe to notifications that happen on bugs that are tagged with any of one or more tags or all of one or more tags. Users can include negative assertions about tags--so, for instance, you can subscribe to bugs that have one tag and do not have another. (See further discussion on this in "Nice to have.") 151129
Only subscribe to notifications that happen on bugs that have any of one or more selected statuses.
Only subscribe to notifications that happen on bugs that have any of one or more selected 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.
Review
Status: Done.
Presented: Partially.
To review:
Go to a the overview or bugs page of any thing to which one may be structurally subscribed (project, package, milestone, etc.). Note that the link on the bugs page is lower on the page than the one on the overview page. The placement on the bugs page is related to 412178 and we can address that if the prioritization gets us to it within our two weeks of polish.
After the page loads, look in the right side portlet for a green link labeled "+ Subscribe to bug mail". Click on this link. Note that this link is intended to also be found on the bugs page, https://bugs.launchpad.dev/firefox , but it is not yet there.
- Explore the "add a form subscription" overlay interface, and subscribe one or more times as desired. Subscribe yourself and a team, at least. We are only aware of the following bugs, so please let us know if you encounter any others.
- The help overlays are unattractive, especially as an overlay for an overlay. Huw gave us an idea on how to improve this. I would like to do this, but I am not planning to unless it is prioritized high enough to make it into the punch list.
- You can see and edit your subscriptions to a structural subscription target (project, package, etc.) using the "Edit bug mail" link on the right hand side just beneath the "Subscribe to bug mail" link described above. Click on that link and explore the page.
Outlook: On production, protected by a feature flag.
a X-Launchpad-Subscription-Description header
Description
Email notifications include a X-Launchpad-Subscription-Description header with the (optional, user-defined) names of the subscriptions that caused the notification to be sent. They also include the descriptions names in the email body, so that they can be used for filtering by mail clients such as Gmail that do not expose arbitrary headers for filtering.
Review
Status: Deployed on production. The header is actually "X-Launchpad-Subscription"
Presented: Yes, but has been changed slightly.
To review: X-Launchpad-Subscription is in the header for each email generated by a structural subscription, and "Matching subscriptions: ..." is at the bottom of each email for Gmail-through-the-browser users (previously the text was "Matching filters: ...", but we do not use the "filters" term any longer). To see this in action you would make one of your subscriptions have a name using the interface alluded to in the previous collection of items, and then cause an email to be sent that matched the subscription. You would then look at the email, and see the header and text that I described.
Outlook: Done.
"Unsubscribe in anger"
Description
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. 649252
Review
Status: Deployed on production, but links to it and possibly some features are feature-flagged. Note that we have tweaked the goal to describe why you *will* get emails about the given bug, not the historical reason. The focus is still on presenting actions to the user--things to do to manage the emails about this bug.
The email link to the page cannot be changed until we have exposed this functionality to all Launchpad users; it will be done as one of our last tasks before changing focus.
Presented: No.
To review: Go to a bug page and click on "Edit all of your subscriptions". Depending on the kind of subscriptions you have to the bug, you will potentially see a lot of information and a lot of options. There are many, many reasons why you may be subscribed to a bug, so exploring this can take some time and care. You may be subscribed because you are directly subscribed; structurally subscribed; subscribed via a team; subscribed via a duplicate; an owner of a project without a bug supervisor; assigned; or variants of these. If you are directly subscribed, it may be because you are a bug supervisor or because you reported the bug, or because of other reasons. This page tries to explain it all, and give you at least a couple of things to do about it.
Outlook: Done, except for email as described above.
Notifications will batch attachments
Description
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). 424849
Review
Status: Done before we started.
Presented: No.
To review: Add an attachment to a bug, and then another. Both attachments should be described in the same message. See "Not implemented" section below.
Outlook: Done. See comments about bug 768997 at the bottom of this document.
Disable the display of the list of subscribers
Description
Discussed with Jono, not on the LEP: disable the display of the list of subscribers. As discussed with Jono, trying to give a list of who might receive a notification, given the new filtering functionality, is something that will be very difficult to communicate correctly, since the list would change depending on the kind of change you made, and the precise state of the bug when you did it. Jono and I agreed that we ought to try disabling this for malone alpha users and see if they scream.
Review
Status: Deployed on production, but feature-flagged.
Presented: No.
To review: Go to a bug page and see the changes.
Outlook: We are curious to see what the user feedback will be. People who are concerned will complain; people who don't notice or like it will mostly be quiet.
Mute your emails from team structural subscriptions
Description
For unsubscribe in anger (above), we should allow users to stop emails from team subscriptions if possible. Otherwise, they have no recourse. This will only work if emails are sent directly to users from Launchpad, and not through some team preferred email like a mailing list. In that case, it is out of our hands.
Review
Status: On Staging, because it involves db changes. Ready for deployment at next downtime rollout.
Presented: No.
To review: On staging, go to a bug's subscriptions page ("unsubscribe in anger", described above) or to a project's subscriptions page. View a subscription that a team has. If you are an administrator for that team, you can edit the subscription (for everyone) or just stop your own mails from the subscription. If you are not, stopping your own emails is the only option.
Outlook: Ready for production deploy.
Items not started
A variety of nice-to-have changes were not included as part of this effort. These are listed on the LEP--we only did the must have requirements, along with the "Mute your emails from team structural subscriptions" described above.
In particular, we did not work on 768997. This would make it possible to batch multiple comments (and attachments) from same person (to same bug), as a follow on to "Notifications will batch attachments" above. Launchpad already followed the letter of the law for that bug, but the intent of the law might have been solved by tackling the task listed above. We might slip this in during our two week clean up depending on how hectic fixing bugs for this feature is, but that should be a happy surprise rather than an expected outcome. We will be focusing on bug fixes.
