yellow team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

We discussed another variation of solutions 3 and 4 (and a but of 5)
this morning.  We could show only the subscribers who are signed up to
receive all emails about a bug.  Then if someone tries to sign someone
else up for a direct subscription to a bug, and they are already
directly subscribed at a filtered level (metadata or lifecycle) then we
inform the person who wanted to subscribe them that the person is
already subscribed at X level, and maybe even give them a link to the
"contact this user" page if they want to ask the person to increase
their subscription level.

This would need to be done in combination with some mechanism to let the
person know what their own subscription level is to the bug, like
solution 1 (which, by the way, would need to include a description of
the kind of subscription the person has, like metadata or lifecycle or
comment, and maybe generally whether it is a filtered subscription).

I'm in favor of pursuing something, and this all sounds somewhat
reasonable, but Brad counseled a bit of patience, so I'm going to wait a
bit.

-- 
You received this bug notification because you are a member of Launchpad
Yellow Squad, which is a bug assignee.
https://bugs.launchpad.net/bugs/772754

Title:
  After better-bug-notification changes, list of bug subscribers is
  confusing

Status in Launchpad itself:
  Triaged

Bug description:
  Recently, for
  https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications ,
  we removed the "also notified" subscribers from the list of bug
  subscribers on each bug.  This is not a good UI.  We need to improve
  this presentation.  It is one of the two most critical issues
  identified by the product team reviewers
  (https://dev.launchpad.net/QA/ExploratoryTesting/BetterBugSubscriptionsAndNotifications#Summary).

  I will now describe the list's use cases and the reason why we made
  the change.  I'll then list the possible solutions discussed so far.

  = Concerns =

  Prior to our work on better bug notifications, the list of bug
  subscribers was supposed to address the following use cases.  They are
  numbered so I can refer to them later.

   1. People can see whether they are directly subscribed.
   2. People can remove their direct subscriptions (they can "unsubscribe" themselves, ignoring all the other possible ways they might be subscribed to the bug).
   3. People can remove the direct subscriptions of the teams they administer (again, they can "unsubscribe," ignoring all other possible non-direct subscriptions).
   4. People can see confirmation that people they subscribe have been subscribed.
   5. People can see who won't receive emails about this bug...if you know the membership of all subscribed teams.
   6. People can see who will receive emails about this bug.

  After our changes, it's the last use case that is the real kicker.
  There's no longer any real way to know who will get an email for a
  change (metadata, comment, etc.) that you are about to make.  Why?

   - A person or team who is subscribed, directly or via structural subscriptions, might only be subscribed for lifecycle events or for metadata events, so unless you are closing the bug, there's no way to know for sure that the person or team will see that particular change.
   - A person who is subscribed via a team's structural subscription may have individually opted out of these emails (this feature is on staging, and will be rolled out in the upcoming downtime deploy).
   - A person or team who is subscribed via a structural subscription might only get the changes for a certain status or importance or tag.  Depending on what you do, the bug might no longer be "interesting" to their subscriptions.

  After our changes, just seeing a name of a principal or a team as a
  subscriber is now an attractive nuisance--an invitation to believe
  that a person or team will know about a change you make, when in fact
  there is no guarantee of it.

  You could argue that there was no guarantee before--sadly, there is
  plenty of bug mail I receive that I do not read--but at least someone
  could be reasonably confident that a notification was sent to the
  user.

  = Solutions =

  In the face of these challenges, we've had three responses so far.

  First, we proposed simply removing the list of users entirely.  That
  removes the lie, but there are other use cases listed above that would
  be ignored.

  Next, we actually implemented the change of simply removing the "also
  notified" subscribers.  This continues to support the other use cases,
  but it continues to be a confusing lie.  See, for instance, Matthew's
  bug description in https://bugs.launchpad.net/launchpad/+bug/770345 ,
  and my aside in comment 1.

  Finally, we have this response: filing a bug.  We need a better
  solution, and I am not sure what it is.

  In closing, I'll list a few thoughts toward a solution.

   - The new bug +subscriptions page tells you all about your own current subscriptions, and those of the teams you administer, much more clearly and comprehensively than what we had before.  The reason why it is regarded as insufficient for the first three use cases I listed above is that it is not as convenient as seeing the information on the bug page itself.
   - You can see confirmation that people have been subscribed using another kind of notification.  A list of subscribers is not necessary for that purpose.
   - Seeing who *won't* receive emails was problematic at best before, because of team subscriptions.
   - Francis tells me that it's a very important use case to let people be sure that a given person will see a particular bug.  His suggestion is that we show direct subscriptions, so if someone does not see a particular person, they can add them and be confident.  If that's a very important use case, then I think we need a better story.  The problem is again that it is deceptive: a direct subscription might be at a "lifecycle" level, so seeing that a person has a direct subscription does not show that they will necessarily receive a notification of a given change.  Another problem is that it will be difficult to concisely and clearly communicate the meaning of the subscriber list.
   - For the use case of "people can see who will receive emails about this bug," and you really want/need this person to see the change, what happens if you discover that someone is directly subscribed to a bug, but at a level that means that will not receive the notification?  It is interesting that we allow subscribing someone, but not changing their notification level.  In any case, the answer is presumably that you will simply contact the person out of Launchpad.  If the person does not publish their email address, It Would Be Nice If Launchpad offered its "I will email this person for you" functionality, but I expect we can ignore that until our users prove otherwise.

  Here are some straw-man solutions.  Some are mix-and-match, and some
  are exclusive.

   1. We could replace the "Edit all your subscriptions" link to
  +subscriptions with text that says one of these three choices, as
  appropriate: "You have no subscriptions to this bug," or "You have
  subscriptions to this bug.  Click here to view and manage them," or
  "You have muted notifications to this bug.  Click here to view and
  manage them."  That addresses use cases 1, 2 and 3, by making what is
  arguably the question people will be most interested in immediately
  answered, and pushing off the rarer questions to another page.

   2. To give confirmation of when you have successfully subscribed
  someone to a bug, we could simply show a notification.  We don't need
  a list for that.  This addresses use case 4.

   3. We could continue to have a list of direct subscribers, but only
  list direct subscribers who will receive all emails (including
  comments).  The list would have a header of "Direct Subscribers" and
  it would include text at the top of the list that said something like
  "others people may also be subscribed via projects, milestones,
  packages, etc." This is a variation of Francis' suggestion, above.
  This addresses use cases 4 and 6.

   4. We could continue to have a list of direct subscribers, and have
  icons or other indications for the level at which the person is
  subscribed.  As with #3, the list would have a header of "Direct
  Subscribers" and it would include text at the top of the list that
  said something like "others people may also be subscribed via
  projects, milestones, packages, etc."  This is another variation of
  Francis' suggestion.  This addresses use cases 4 and 6.

   5. We could provide an AJAX query mechanism, so you can choose a
  person and see the level of their subscription, taking all
  subscriptions (structural, etc.) into account.  We would have to
  summarize the information about status, information, and tag
  filtering, because unions and intersections could make a precise
  listing very complex.  Note that this is the only way I see to address
  the use case "People can see who won't receive emails about this
  bug...if you know the membership of all subscribed teams."  That said,
  I'm skeptical of that use case.  It also is the only way to know for
  sure that someone will get an email without creating a new
  subscription...but from a UI perspective, just making a direct
  subscription for the other person is of equivalent weight/annoyance,
  and happens to already be implemented.  This addresses use cases 4 and
  6.

  I lean towards implementing solutions #1 and #4 (and ignoring use case
  5).  It's not perfect, but I think it's an improvement.