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.

Just so I don't forget. Re 3, I've seen some code which checks only if a person is a member of the team before allowing unsubscribe action (and does not require him to be an admin). This might, unfortunately, affect our unsubscribe-in-anger functionality as well.

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.

all-in-one.png is a mockup of my currently preferred approach to addressing this.

Notes:

The first line of the box about the user's subscription should be one of these following. The bracketed words indicate that these words should be links to change the notification level of the direct subscription.

You are subscribed to [all notifications for this bug].
*OR*
You are subscribed to [all notifications except comments for this bug].
*OR*
You are subscribed to [notifications when this bug is closed or reopened].
*OR*
You are not directly subscribed to this bug, but you have other subscriptions that may cause you to receive notifications.
*OR*
You are not subscribed to this bug's notifications.

-----

The box about the user's subscription should have the following links and text, depending on the condition listed. Links are bracketed. "See details" and "Edit bug mail" both go to the bug's +subscriptions page.

[Subscribe to this bug] *IF NOT DIRECTLY SUBSCRIBED*
[Edit bug mail] *IF SUBSCRIBED IN ANY WAY*
[Mute bug mail] *IF SUBSCRIBED IN ANY WAY*
[Unsubscribe] *IF DIRECTLY SUBSCRIBED*
If you unsubscribe, you might still get email from this bug because of other subscriptions. [See details.] *IF DIRECTLY SUBSCRIBED WITH OTHER SUBSCRIPTIONS*

-----

If someone tries to subscribe someone who is already subscribed but at a non-full level, maybe invite them to go to the contact page for that person. Or maybe not.

This is a variation of the mockup from the previous comment. The main point of it is to show that the "Other subscribers" might go to an overlay.

Notes:

* "View other subscribers" displays if there are other subscribers. Otherwise, the text is "No other subscribers" or similar. We do not try to count or approximate subscribers other than this non-zero/zero distinction.
* Other notes from previous comment still hold.

Advantages:

* When a bug has a lot of subscribers, the page does not scroll down as far (though if we really cared about this, we could do a CSS overflow:scroll in a portlet box just as well as the overlay).
* We don't have to load the "other subscribers" information (which can be a lot of database work) unless the user actually wants it.

Challenges:

* A number of the actions in the overlay might normally imply another overlay--in particular changing the subscription level of a team. An overlay on an overlay is unacceptable. We would have to carefully design the UI for this change. The portlet approach does not have this challenge.

Disadvantages:

* Users have to make another action in order to see the subscribers. I have a guess that this has already been rejected in the past when we were trying to optimize the page, but maybe not.
* "Subscribe someone else" goes more naturally in the list of subscribed users, rather than floating off next to the "view" link, IMO. If you put it in the list of subscribed users as an overlay, you may be back to the overlay-of-an-overlay challenge.

My opinion is that the portlet solution from the previous comment has fewer problems at this stage. I will choose it unless someone is a champion for this overlay approach who provides compelling responses to the challenges and disadvantages...or unless someone higher up rejects them both. :-)

As a user of Launchpad, I favour the portlet approach; particularly if you can make a long list scroll inside the portlet.

I don't want Launchpad to make me work to get the information I need. I want to be able to glance around the page and see the information I need to work with this bug. Who will see changes to this bug report ranks pretty highly for me.

I have a couple of wording suggestions.

Under "May be notified", I'd suggest changing "To be sure that some receives notifications" to "[[Subscribe someone directly]] if you want to be sure they'll receive notifications about this bug."

This is an aside: I wonder if "Remove direct subscription" might better describe what actually happens than "Unsubscribe". If you make that change, I'd suggest changing the explanatory text directly below it to read, "Removing your direct subscription may not stop all email about this bug. [[Mute this bug]] to make sure you never receive email about it."

Oh, and I fully support the proposal outlined in the mocked-up bug report.

> As a user of Launchpad, I favour the portlet approach; particularly if
> you can make a long list scroll inside the portlet.
>
> I don't want Launchpad to make me work to get the information I need. I
> want to be able to glance around the page and see the information I need
> to work with this bug. Who will see changes to this bug report ranks
> pretty highly for me.

Cool. Thank you for the vote and explanation.

>
> I have a couple of wording suggestions.
>
> Under "May be notified", I'd suggest changing "To be sure that some
> receives notifications" to "[[Subscribe someone directly]] if you want
> to be sure they'll receive notifications about this bug."

Yes, nice. Thank you.

> This is an aside: I wonder if "Remove direct subscription" might better
> describe what actually happens than "Unsubscribe". If you make that
> change, I'd suggest changing the explanatory text directly below it to
> read, "Removing your direct subscription may not stop all email about
> this bug. [[Mute this bug]] to make sure you never receive email about
> it."

I vacillate on this one. I like "Unsubscribe" for being succinct and easy-to-parse; I like "Remove direct subscription" for its precision and clarity. However, the improvement in the explanatory text that you gave might push me towards the latter.

That said, I have three concerns with the improved explanatory text.

First, it's longer than what I had before. Moreover, I'm about to suggest making it longer still.

Second, while I agree that muting should be encouraged before "see details" (+subscriptions), I think that "see details" might be the right action for some people.

Third, as we've been having to deal with lately in other contexts, if you have a team subscription, and the team has a contact address that will email you (such as a mailing list, in a common case), you will still get emails via the team subscription. We can't provide per-person control in that case because we don't send the pertinent emails. So...it's not quite never. We could check for the problem and only mention it if it is pertinent, but if someone later adds a team subscription with a contact address that is a mailing list to which you are subscribed, that breaks "never". Therefore, I'm thinking we need to clarify this, unfortunately...or go back to the vaguer approach I had before.

Adjusting the text for my second and third concern, I get this: "Removing your direct subscription may not stop all email about this bug. [Mute this bug] to make sure you never receive email about it (except potentially from team mailing lists), or [see details of all your subscriptions to this bug]."

If I had to choose now, I'd choose "Remove direct subscription" and the longer, but clearer, text. I don't have to choose now, but we do have to choose soon. :-)

> Oh, and I fully support the proposal outlined in the mocked-up bug
> report.

Did some preliminary QA, it all seems to work fine (subscribing at different levels, muting, unmuting [restores the subscription as well], subscribing someone else, unsubscribing a team you are a member of, static +subscribe page, etc.). Still keeping as qa-needstesting so we get a bit more testing first.