Allow users to restrict who can send them notifications
Closed, ResolvedPublic

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
TheDJ added a comment.May 4 2017, 10:10 AM

Which also reminds me, we need to create a better distinction between 'event' and 'notification' when we talk about Echo.

I'm a little confused, I may be missing something here?

Notifications are a courtesy for the receiver more than they are a tool for the sender. No one is talking about blocking a user's actual contribution from being seen by anyone else - but the notification about that contribution, whatever it may be, is not a tool for the contributing user, but for the user who cared to follow whatever event was done.

In cases of articles, we let users choose what they "follow" with their watchlist; if they care about an article, they'll watch it and see the changes. If they don't, they stop following it. No one can actually control whether a person does that, because it is their choice to do so, to actively listen and watch for changes in whatever context.

I don't quite see how notifications are any different. We let people decide whether they receive a notification about most events, except for mentions and system events, and even those we don't really have the power to enforce a "listening". The "sender" of the notification - the user who initiated whatever-action, including a mention, has absolutely no expectation of the other person having noticed, read, or cared about the notification.

A user may choose to open and close their Notification popup without looking at it. A user may choose to sign up with an email they never look at. A user may choose to ignore the notification even if they've seen it. Any number of reasons and actions can be taken by the receiving user that are the de-facto equivalent of "not having sent a notification"; there's no promise being made to the initiating user that the receiver intercepted their notifications at all.

The only byproduct here, is that if the receiving user did not get the notification, they may miss the action. If this was a technical issue, we fix it. If this is a conscious choice by the receiving user, they are aware of the reprecussions of missing these messages, and clearly made the choice to accept that. I don't understand how expecting any sort of responsibility towards the sender in explaining (or even telling someone whether the notification has arrived) is valid here.

So, that said, I don't quite understand this issue?

How different are talk page access or the use of Special:EmailUser? We've traditionally treated MediaWiki as an "all or none" model, where users can edit and e-mail anyone or not. If we shift toward more granulated permissions, we ought to be thinking about how these will adapt throughout and jive with the rest of MediaWiki, in my opinion.

Yes this part of the interaction also has me rather concerned and deserve much more consideration I think. We should seriously consider all the possible ways in which this will affect everyone. This task is not just about "i don't want to receive pings", it's also about:

  1. what happens if someone doesn't want to receive my pings
  2. If we remove the equal playing field in communication, will that create new user levels.
  3. how does a sysop notify someone of something important
  4. what does this mean for blacklists between sysops

What would happen is that they don't see the notification; the same way as if they were an anonymous user who had a changing IP address, or a user who didn't look at their email, or, as you pointed out below, someone who sets "send to spam" all messages from Person A.

If something important happened and the receiver missed the notification, it will be exactly the same as if they've missed it because they didn't open their email, or looked at their notification panel, or just cleared it immediately in general. If the receiver blocks a sysop, they should be aware they might miss the notification about things done. The actual action is still there, and the receiver will either have to proactively check whatever they think is important, or risk missing important notifications. Or they can still get notifications from their own talk page, which is usually the place for specific relevant announcements about their own account anyways.

The point is -- It's their choice, and not only is it their choice, we as senders have absolutely no way of controlling for it as it is. A user can simply ignore our notifications for them already, and we have nothing we can do about it -- if they, by ignoring the notification, missed an important event, then it is something they'll have to deal with, and I'm sure they're as aware of this fact as someone who actively chooses to put all emails from their bank account in the spam folder.

Gmail doesn't tell you you can't delete a thread without looking at it if it came from your bank, or from the government, or if it has "urgent" on it. It's your choice, because email (and notifications) are a tool for the receiver, who has control over what they choose to interact with.

We already know that harassment happens in notifications, and we know people ask for the ability to block notifications by other people. The actions taken by those other people will still be visible to all, but the notification itself will not be.

For the sender, it is as much an annoyance as if the user didn't see (or didn't care, or ignored actively) their notification for a number of other reasons. For the receiver, it can help avoid anxiety related to even looking at notifications they really don't want to look at or deal with.

Gmail does not send me a note if someone put my email in spam, or deleted it without looking. It also doesn't send me a note if I'm blocked at the other person's server level. It only sends me a note if my email didn't reach the receiver due to a technical issue. Same goes to real life mail service, by the way. If I just dump my envelopes in the trash, the sender will never know I haven't seen any of them. I may even have not seen the fact they sent me a letter. It's my choice (and my responsibility) to decide what I choose to see and interact with. Why is this different for notifications on wiki?

I am not sure I quite see how the notification blacklist (or who/what is on it) has any responsibility towards the sender?

We let people decide whether they receive a notification about most events, except for mentions and system events

Small correction here: while users can't opt out of receiving system notifications (at all) or user talk notifications (web only), they can in fact opt out of receiving mentions by going to their preferences and unchecking both the "web "and "email" checkboxes for the "Mention" category.

We should consider how this task relates to sent ping notification: if a receiving user is on a block/ignore list, will we tell the ping sender that the ping was sent successfully, will we say it was blocked, will we say nothing at all, or something else?

mention-success and mention-failure indicate the sender met or didn't meet the requirements (all of which can be determined from public info) for sending a ping/mention. Both are optional, opt-in, and sent to the sender.

mention-success is sent if they met the requirements for sending a mention (e.g. not too many pings per edit, recipient username exists). mention-failure is sent if they did not meet these requirements.

Whether the recipient has mentions turned on is private and not considered. The same will be true here.

How different are talk page access or the use of Special:EmailUser? We've traditionally treated MediaWiki as an "all or none" model, where users can edit and e-mail anyone or not.

After this and T138166: Allow users to restrict who can send them emails are fixed, there should also be a "block everything from user". But there is a use case to just block private email while still allowing the rest (and maybe just block notifications).

Regarding @TheDJ's point, I agree with @Mooeypoo. The only substantive thing new here is that it's granular. You can already block all pings and almost all other notifications. As always, to leave an important message, you'll post on someone's talk page (that goes if the sender is a sysop too).

We should also take a step back and consider if this is the right solution

You cite both Facebook and Twitter as examples. Both of those allow you to block users, which blocks (almost) all interaction on the platform. Although our situation is not 100% the same (since most of our content is public, though actually that applies to Twitter too), I do think we should allow blocking users, including both blocking notifications and a general block (T164542: General user mute/block feature).

(I don't necessarily object to a "view blocked notifications" (like you suggested) button if there is an appropriate click-through so you don't accidentally see them. But it should be up the recipient (I think there should be a "full block" where it doesn't go to the archive/hidden area), we would have to consider the ramifications, and it shouldn't block the initial feature.)

Nemo_bis updated the task description. (Show Details)May 16 2017, 2:33 PM

Change 354695 had a related patch set uploaded (by MtDu; owner: MtDu):
[mediawiki/extensions/Echo@master] Improve UI for blacklist preference

https://gerrit.wikimedia.org/r/354695

Change 351699 abandoned by Catrope:
[experimental] Implement per-user notification blacklist with preference

https://gerrit.wikimedia.org/r/351699

Someone should audit all the notification types, and confirm that they should be blocked by default (for senders that are blocked). Most are straightforward, but some like 'revert' may need further consideration.

Nirmos removed a subscriber: Nirmos.May 23 2017, 6:15 AM

Change 320718 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Implement per-user notification blacklists

https://gerrit.wikimedia.org/r/320718

Change 355567 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable $wgEchoPerUserBlacklist in beta labs

https://gerrit.wikimedia.org/r/355567

Change 355567 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable $wgEchoPerUserBlacklist in beta labs

https://gerrit.wikimedia.org/r/355567

Change 356320 had a related patch set uploaded (by Mattflaschen; owner: Mattflaschen):
[mediawiki/extensions/Echo@master] Fix user talk exception for blacklist

https://gerrit.wikimedia.org/r/356320

Change 356320 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Fix user talk exception for blacklist

https://gerrit.wikimedia.org/r/356320

Checked in betalabs - the functionality works as expected:

  • a user name entered in the Preferences-Notifications-Block list (one name per row) becomes blocked from sending notifications
  • notifications from blocked users will be sent if changes are made to User talk page
  • cross-wiki notifications will be coming from users that are blocked on a local wiki; so, the Block list works per user and per wiki.
He7d3r added a subscriber: He7d3r.Jun 5 2017, 12:49 AM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Mass-moving all items tagged for MediaWiki 1.30.0-wmf.3, as that was never released; instead, we're using -wmf.4.

From a recent email discussion:

Roan Kattouw
Jun 1 (7 days ago)

My understanding is that what remains to be fixed about the UI is some tricky MW core debugging that really only Matt and Bartosz have enough knowledge to do.

We're still discussing some minor details with folks on meta, but it seems like this will be safe to release in the coming weeks. I really think the UI improvements are a requirement to this being successful. Any update on when the blocker will be resolved?

I'm also clarifying with Elena in an email how cross-wiki notifications work so we can properly document it.

Still-open Gerrit changes for this:

Also: https://gerrit.wikimedia.org/r/#/c/358499/ (in OOjs UI) fixes a bug where, if you click a suggestion, then start typing again (to enter the next user name), no suggestions appear.

Change 359121 had a related patch set uploaded (by Trizek; owner: Trizek):
[mediawiki/extensions/Echo@master] More clear label for the textarea

https://gerrit.wikimedia.org/r/359121

Change 354695 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Improve UI for blacklist preference

https://gerrit.wikimedia.org/r/354695

This is now ready, except that @Mattflaschen-WMF points out there's something that's not implemented yet or not quite right yet around exempting user talk pages.

This is now ready, except that @Mattflaschen-WMF points out there's something that's not implemented yet or not quite right yet around exempting user talk pages.

Sorry, I was wrong.

It should be fine after rECHO813ab5b54e4b: Fix user talk exception for blacklist.

Etonkovidova added a comment.EditedSat, Jul 1, 1:28 AM

The following notification will not be received if they are initiated by a user who was blocked:

edit-thank
emailuser
ep-campus-add-notification
ep-course-talk-notification
ep-instructor-add-notification
ep-online-add-notification
ep-student-add-notification
flow-mention
flow-new-topic
flow-post-edited
flow-post-reply
flow-summary-edited
flow-description-edited
flow-thank
flow-topic-renamed
flow-topic-resolved
mention
page-linked
pagetriage-add-maintenance-tag
reverted
user-rights

The following notifications will be received even if they were initiated by a blocked user:

edit-user-talk
flowusertalk-description-edited
flowusertalk-new-topic
flowusertalk-post-edited
flowusertalk-post-reply
flowusertalk-summary-edited
flowusertalk-topic-renamed
flowusertalk-topic-resolved
flow-thank (if the action happened on the user talk page)
mention (if the action happened on user talk pages)
pagetriage-add-deletion-tag
pagetriage-mark-as-reviewed
reverted (if reverts happened on the user talk page)

QA Recommendation: Resolve

@TBolliger Per the above, Elena thinks this is ready to go. If you agree, the earliest this could be turned on on a production wiki is after our latest fixes for it have rolled out, which will be on July 12th or 13th depending on the wiki (normally it'd be a week earlier, but next week's deployment will be skipped because of the 4th of July holiday). Let us know what you want to do and when. The code is already on the beta labs wikis for testing, if you want to take a look.

Thanks, @Catrope and @Etonkovidova !

Can we enable this on meta on the 12th/13th? There are a few minor sub-tasks I'd like to have @dbarratt investigate before a wider release.

@TBolliger Just a question: Restricting notifications from anon users - has it ever be discussed?

Change 363049 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable Echo per-user blacklist on meta

https://gerrit.wikimedia.org/r/363049

Thanks, @Catrope and @Etonkovidova !

Can we enable this on meta on the 12th/13th? There are a few minor sub-tasks I'd like to have @dbarratt investigate before a wider release.

I have created a config patch for this (see above) and scheduled it for deployment during the evening SWAT on Wednesday (at 23:00 UTC / 4pm PDT).

@TBolliger Just a question: Restricting notifications from anon users - has it ever be discussed?

@Etonkovidova — Great idea! and yes. This would fall under a different project we're considering (no Phab ticket yet): https://meta.wikimedia.org/wiki/Community_health_initiative/User_and_User_talk_page_protection_tools

It would essentially allow users to wall off entire groups of users, as opposed to a blacklist.

This idea is still brewing. How our users react to this blacklist will certainly inform our decisions.

Thanks, @Catrope and @Etonkovidova !

Can we enable this on meta on the 12th/13th? There are a few minor sub-tasks I'd like to have @dbarratt investigate before a wider release.

I have created a config patch for this (see above) and scheduled it for deployment during the evening SWAT on Wednesday (at 23:00 UTC / 4pm PDT).

Please document first! T169606: Document how to restrict notifications received

I've checked on Meta and I haven't seen anything there. Normal?

Roan and I agreed to pull it from Wednesday's release.

Sorry for not communicating that earlier. Some annoying bugs in the feature were fixed this week, and we probably want to wait for the next train to roll out next week with those fixes before we enable this on a real wiki.

jmatazzoni closed this task as Resolved.Fri, Jul 14, 12:54 AM
jmatazzoni claimed this task.

Sorry for not communicating that earlier. Some annoying bugs in the feature were fixed this week, and we probably want to wait for the next train to roll out next week with those fixes before we enable this on a real wiki.

We are next week. What's new?

@Catrope — I just tested the UI and the mute functionality on beta, looks good to me. I say we release it on Meta with the next release.

@Catrope — I just tested the UI and the mute functionality on beta, looks good to me. I say we release it on Meta with the next release.

Alright, scheduled for Wednesday at 4pm Pacific.

Announced in Tech/News and the Collaboration team newsletter.