After better-bug-notification changes, list of bug subscribers is confusing
Recently, for https:/
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:/
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.
|Gary Poster (gary) wrote : Re: [Yellow] [Bug 772754] Re: After better-bug-notification changes, list of bug subscribers is confusing||#6|
|Changed in launchpad:|
|status:||Triaged → In Progress|
|assignee:||Launchpad Yellow Squad (yellow) → Gary Poster (gary)|
|Changed in launchpad:|
|status:||Fix Committed → In Progress|
|Changed in launchpad:|
|status:||Fix Committed → Fix Released|