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

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.

On May 12, 2011, at 5:25 AM, Matthew Revell wrote:

> 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.

Excellent.

Thank you very much, Matthew!

Gary

Fixed in db-stable r10604 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10604>.

Marking as qa-ok so the landed stuff doesn't block db-stable deployment.

Landed in r13243, reverted in 13247 (because of some weird merge artefacts which caused test failures), then properly re-landed as r13248.

Fixed in stable r13243 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13243>.

Fixed in stable r13248 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13248>.

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.

William noted a problem for anonymous users: bug 798622. I am getting that fixed asap.

We should not deploy this until everything up to (and including) r13258 is deployable, which holds a fix for 798622.