launchpad development
Feature review meeting notes 2011-03-21
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 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."
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.
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. Not yet announced.
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.
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.
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 for malone-alpha with known bugs in the user interface; should be deployed by Monday on qastaging for malone-alpha with most/all known bugs fixed.
To review: Go to a bug on qastaging, such as https://bugs.qastaging.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: Coding done. Needs a nodowntime deploy sometime week of March 21 for bug fixes from qastaging. Needs to be released to all users, not just malone-alpha.
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.
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: We are polishing on a separate integration branch. It looks good, and it is worthy of review.
To review: Get the branch lp:~yellow/launchpad/accordionoverlay, build it, and run it. The email filtering functionality itself works on the server side, per our tests, and my instructions here do not demonstrate it. However, I do suggest that you explore the associated user interface to add, edit, and delete these subscriptions. The following steps are a reasonable starting point to do so.
Log in as foo.bar@canonical.com:test.
After the page loads, look in the right side top 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 an a team, at least. We are only aware of the following bugs, so please let us know if you encounter any others.
- If something goes wrong on the server, we don't handle it properly yet.
- We don't yet validate tag names as is necessary for the database (lowercase, no special characters).
- 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 you and Francis request it (which will affect our final delivery date).
There is not yet a link to an edit page for your subscriptions as I write these instructions. It is intended to be on the same pages as "Add" (https://launchpad.dev/firefox and https://bugs.launchpad.dev/firefox). Go here for the edit page: https://bugs.launchpad.dev/firefox/+subscriptions . Explore the page. There is one problem that I hope to have resolved by the time you look at this: you should not be able to change the subscriber, and right now it looks like you can. We could make it possible to edit the subscriber, but I am not planning to unless you and Francis request it (which will affect our final delivery date).
Outlook: Integration branch expected to land week of March 21, with the UI hidden via feature flags. (Server side changes will go into review March 22; client side changes will go into code review March 23. We will then have a UI review on production, via feature flags.) I expect polish work on it to trickle into the following week. When we open the feature to the public, we'll probably then have yet a bit more to do, as discovered by our users. I'm optimistically viewing the "clean up things from our users feedback" phase as one week, though it will quite possibly bleed into our time on bugs rotation, depending on what we discover.
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 staging, ready for the next downtime deploy to production. The header is actually "X-Launchpad-Subscription-Filter" at this time; I am going to advocate returning it to the spec, which I prefer, before we release.
To review: X-Launchpad-Subscription-Filter is in the header for each filter, and "Matching filters: ..." is at the bottom of each email for Gmail-through-the-browser users (I again believe that we should not use the word "filter," and so intend to suggest to the squad that we change this to "Matching subscriptions: ..."). I do not give instructions on actually seeing this in practice, but I can do so, after a fashion, if desired. If the necessary code were on production, 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, with text tweaks as described above.
"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: Far along but not yet ready for review. 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.
To review: Despite the fact that this is not ready for review, there are two artifacts available if desired. First, https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/DirectSubscriptionsOnBug gives details on the kinds of messages and actions that we intend to display, though it may be a bit hard to follow. The code to gather this information has been written, but we do not yet display it. Second, you can see some of the progress on https://bugs.launchpad.dev/firefox/+bug/1/+subscriptions : this currently shows all structural subscriptions pertinent to all bug tasks of the bug in context. For instance, if you add a subscription to both Firefox and the Ubuntu Firefox package in launchpad.dev, you will see them on this edit page.
Outlook: I think we can do the remaining parts of this in about a week. Practically, with the other tasks on our plate, I expect us to have this landed by April 1.
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: Not started.
To review: N/A
Outlook: We currently expect this to take about a day, barring unpleasant surprises.
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: Not started.
To review: N/A
Outlook: Simply doing the described experiment should be trivial, under a day to get everything done. If we can agree to either remove them, or keep the very inaccurate and likely unhelpful display that we have now, then this should be easy enough to do. Any other decision will have to be evaluated later.
Nice to have
The following are notes on "nice to have" items either from the LEP or from work described above. For what it is worth, I have ordered them in my own feeling of decreasing benefit to cost-ratio, though the only one I'm really not interested in is the last one.
- We may want to expand the most minimal subscription event filter, "bug is opened, closed, or reopened," to include moving to "incomplete," so that people filing bugs can see when more information is requested. This sounds like a good idea to me. We are using some shared definitions of "opened, closed, or reopened" so changing this is a bit trickier than it sounds. I have no concrete time estimate right now, though I would certainly hope it would not be an effort larger than a day or so.
The help overlays are ugly right now. It would be nice to do them the way that Huw showed us. This could conceivably take under a day to pull off, but our relative inexperience with JavaScript sometimes causes unexpected costs.
- UI interviews, as well as the opinions of people briefed with the plans such as Julian Edwards, indicated that a number of people wanted a bit more flexibility in their structural subscription filters. In particular, people wanted to be able to subscribe to comments and *not* anything else. We experimented with some user designs for this in user testing. On the basis of the results we got, for the user interface I would simply expand the one checkbox "[ ] Don't send mail about comments" to the three shown below (the "(?)" indicates a help link that would explain what "other changes" means). This would require some significant restructuring on the server side, including database changes. For time estimates, I'd say a week is a bit optimistic, and two weeks is a bit pessimistic.
[ ] Don't send mail about comments [ ] Don't send mail about new branches or patches [ ] Don't send mail about other changes (?)
- Jono commissioned an investigation of warning people about how much more mail they'll get when they subscribe to something structurally. We think we can do a useful approximation of the task in about six days for one engineer. User testing showed that people liked having canned subscriptions available, that they can customize. We could be prepared to answer questions about these canned subscriptions ("About how many emails would I get for this subscription to all notifications, based on last week? How many emails for this subscription to all notifications except comments? How many for only when bugs open and close?") in about six days for one engineer. That would be useful by itself. We might be able to usefully tweak that further to give rough of fully dynamic subscriptions, based on broad Launchpad statistics, but that is not included in the time estimate. Jono thought this sounded interesting.
- We might want to make it possible to edit the subscriber of a structural subscription filter. That's a bit tricky. I have no concrete time estimate right now, though I expect this might take a few days at the least.
