Talk:Community health initiative/User Mute features

Discuss if user talk page notifications should be exempt from Notifications Blacklist

With the current Notification blacklist feature, all notification types are blocked except user talk page edits. Should user talk page notifications be exempt from this blacklist?

• Comments

Yes, otherwise, what's the point of having user talk page notifications? The only thing that this prevents is if you have a user where you and them don't really get along well, and their presence causes you stress and anxiety, where you aren't consistently notified that they are pinging you to a discussion you're already aware of. Talk page notifications--deliberate attempts to reach you, and not just random pinging should of course be exempted. Though I do think it SHOULD be an option to allow blacklisting of it, simply for user control. If the user wants to take responsibility for not getting messages from X user they aren't fond of, they will have to deal with the consequences of that. But I want them to enable it specifically, first. Tutelary (talk) 01:58, 2 June 2017 (UTC)

Hello Tutelary, if I understand you correctly, you think that as an additional step an user should be able to add the option of stopping notifications on their own talk page, too. So, the rest of the notifications would be stopped if you add someone to the blacklist but you would need to check an extra box to stop talk page notifications, right? SPoore (WMF) (talk) , Community Advocate, Community health initiative (talk) 16:03, 2 June 2017 (UTC)

User:SPoore (WMF) Yes, though honestly, now that I think about it, I think all of that should be toggable. For example, one might enable to see the notification when they are reverted by editor X, but not when they are simply pinged by editor X. Though now I'm getting into semantics and scenarios about why they would want to be notified when they are reverted, but not when they are pinged by the user. Similar to how it is in this image: So, let's say I want to enable only reverts, and talk page messages, so I'm not missing out on pages where we simply buttheads, but am missing out on the harassment-esque excessive pinging. I think that would be ultimately in the user's control and would be in their best interest to lay out exactly which notifications they'd like to receive from the user they are blacklisting. Tutelary (talk) 20:59, 2 June 2017 (UTC)

Thank you Tutelary for giving a more detailed response. I'll take note of your idea that users have more control over each type of notification. SPoore (WMF) (talk) , Community Advocate, Community health initiative (talk) 21:12, 2 June 2017 (UTC)

Discuss if there are other types of notifications that should be exempt from Notifications Blacklist

Are there other types of notifications that should be exempt from this blacklist?

• Comments

Reply To template

What about notifications triggered by the Reply to (alias Ping) template ? Are they suppressed already ? -- Kaartic ^{correct me, if i'm wrong} 11:11, 27 May 2017 (UTC)

Hi Kaartic, thank you for your question. Yes, the blacklist will also prevent Mention notifications. Mention notifications are triggered when a link is created to your userpage, either via manual wikitext (e.g. [[User:Foobar]]) or via a template (such as {{Reply_to|Foobar}}). For example, if User:Apples blacklists User:Bananas and User:Bananas includes {{Reply_to|Apples}} on an article talk page, Apples will not receive the notification. — Trevor Bolliger, WMF Product Manager 🗨 22:12, 31 May 2017 (UTC)

That's good to hear. Thanks! - - Kaartic ^{correct me, if i'm wrong} 04:01, 14 June 2017 (UTC)

Reverts and others

I think users should be given options to allow separate types of notification from blocked users (e.g. only blocking thanks notifications from the users in the list), as information such as reverts or even mentions might be helpful. Otherwise, it's pointless to block almost all notifications if no one is actually abusing reverts to spam notifications. Would it be possible to add support for something like this to the blacklist? Jc86035 (talk) 11:00, 7 June 2017 (UTC)

Hello @Jc86035:, thank you for your question. Yes, it would be possible to add this functionality but I personally think this type of change would be better suited as a follow-up enhancement at a later date. In general I agree that the more granular of control we can give to users the better, but I believe we still need to understand if this feature will have a positive impact before we add in additional complexity. — Trevor Bolliger, WMF Product Manager 🗨 21:19, 12 June 2017 (UTC)

@TBolliger (WMF): I don't think this would work as a follow-up. The lack of granularity is likely to be a hindrance to collaboration, as evidenced by the hewiki discussion mentioned below (since it's not possible to be notified for e.g. reverts but not thanks), and so might not be very useful, as editors who are irritating or who send thanks for every edit can still be good contributors. In any case, without this blacklist the existing functionality to block all thanks notifications would suffice for thanks-spamming, and most WMF wikis AFAIK have competent admins who can press the block button. Finally, this feature request was tied for 122nd by number of support votes in the Community Wishlist survey last year (with only 58% supporting), which suggests Wikimedia users might have other priorities. Jc86035 (talk) 11:30, 13 June 2017 (UTC)

@Jc86035: My biggest concern with building in blacklist per-notification type options is the complexity required to design, implement, and test this feature. This feature was fast-tracked because it was completed by volunteer developers, and we just wanted to shepherd it through to completion.

One quick option would be to have the blacklist only cover Thanks and Mentions, but I believe this diminishes the blacklists' efficacy. Your thoughts? — Trevor Bolliger, WMF Product Manager 🗨 22:22, 13 June 2017 (UTC)

@TBolliger (WMF): I think that would be a better solution than having it block all notifications except talk page messages, unless editors are actually trying to abuse the revert button to send notifications (I don't know whether this has ever happened). Jc86035 (talk) 14:54, 14 June 2017 (UTC)

@Jc86035: The blacklist should be comprehensive and have as few exceptions as possible. The more exceptions it has, the less impactful it becomes.

Reverts can be used to harass a user, potentially goading them into an edit war. (The blacklist is currently only for Echo notifications, so users could still be notified of edits to pages of interest via the watchlist or email.) I believe the best course of action is to proceed with the current functionality and evaluate how it is helping (or not helping) users. — Trevor Bolliger, WMF Product Manager 🗨 23:02, 14 June 2017 (UTC)

Discuss cross-wiki notifications

How will this work for cross-wiki notifications? Should the blacklist prevent notifications trigged from other wikis? What should happen when users visit other wikis?

• Comments
• If User:Apples has blacklisted user:Bananas on e.g. en.wp then user:Apples should not see notifications from user:Bananas relating to en.wp anywhere. There should be some mechanism to block notifications from other wikis as well. The { and } characters are not allowed in usernames a syntax such as

  User:Bananas  {frwiki,wikidata}

  would prevent user:Apples seeing notifications from user:Bananas relating to the wiki that it it was written on as well as the French Wiktipedia and Wikidata.

  User:Bananas {*,-dewiki}

  would prevent apples seeing notifications generated by user:Bananas on any wiki except the German Wikipedia. I haven't a clue how easy this would be to implement though. Thryduulf (talk: meta · en.wp · wikidata) 17:11, 11 June 2017 (UTC)

• If User:Apples has blacklisted user:Bananas on e.g. en.wp then user:Apples should not see notifications from user:Bananas relating to en.wp anywhere. This is how the current implementation works. I like the idea of supporting both local and global blacklists but it feels like a follow-up enhancement and not an initial requirement. — Trevor Bolliger, WMF Product Manager 🗨 18:56, 12 June 2017 (UTC)
  • Thinking more about this, I agree global watchlists are a version 2.0 feature. A button to "copy blacklist from Meta" would be useful before then (in the initial release if simple to code, in version 1.small-number if less easy. In later versions this could become "copy blacklist from <wiki selected from drop-down list>"). In the first version I think that if Apples has blacklistsed Bananas on en.wp then they shouldn't see, on en.wp, any notifications generated by Bananas anywhere, but those notifications would still be seen on wikis where Apples has not blacklisted Bananas. Thryduulf (talk: meta · en.wp · wikidata) 00:02, 14 June 2017 (UTC)
    • @Thryduulf: I agree that there is still too much of an obvious work-around for cross-wiki harassment. I've created T167902 to track this proposal. — Trevor Bolliger, WMF Product Manager 🗨 17:38, 14 June 2017 (UTC)

• Update: There is an open discussion on task T167902 about how cross-wiki notifications should be handled in this Mute feature. — Trevor Bolliger, WMF Product Manager 🗨 20:06, 25 July 2017 (UTC)

Discuss if the current implementation is understandable

Is the current implementation understandable? Should we improve the User Interface or copy?

• Comments

UI Suggestions

The user interface seems good but I would like to give the following suggestions :

1. A hint about how to separate the list of user names would be more helpful (though it would be naturally be a comma, mentioning it explicitly would erase the doubts a few users would have)
2. The section seems to be named Block list while in the description it's mentioned blacklist. It seems unsymmetrical.

-- Kaartic ^{correct me, if i'm wrong} 11:11, 27 May 2017 (UTC)

I absolutely agree 100% — We want to make both of these changes before this feature goes live on wiki. Because ‘block’ already has a definition in MediaWiki we’ll most likely will go with ‘blacklist.’ What do you think?

Also of note, at the Wikimedia Hack-a-thon a few weeks back some developers built a more intuitive interface, made of different text boxes for each user name and error checking if the provided username contained a typo. We believe this will make the feature more straightforward to use, and we hope to have it available for testing very soon. — Trevor Bolliger, WMF Product Manager 🗨 22:12, 31 May 2017 (UTC)

@Kaartic: We don't have the latest version on beta yet, but I wanted to provide a screenshot of the new UI: view it here. I propose we title the section Blacklist and the description text be Prevent these users from sending me notifications, except when they write on my user talk page — Trevor Bolliger, WMF Product Manager 🗨 22:27, 13 June 2017 (UTC)

• That screenshot looks good, and I agree with the suggested description. Thryduulf (talk: meta · en.wp · wikidata) 23:41, 13 June 2017 (UTC)

@TBolliger (WMF): It looks great ! It would be better with your suggested wordings in place !! I would like to suggest a small change for the description. What about Prevent these users from notifying me... instead of Prevent these users from sending me notifications... as the users don't send notifications by themselves? - - Kaartic ^{correct me, if i'm wrong} 04:01, 14 June 2017 (UTC)

@Kaartic: Good suggestion. I updated T166626 to include your suggestion. — Trevor Bolliger, WMF Product Manager 🗨 17:41, 14 June 2017 (UTC)

Discuss any other considerations about the Notification Blacklist

Are there any other considerations about how this will impact an user's ability to manage their on-wiki communications?

hewiki

Hi. I published this at hewiki village pump, and asked the community opinions. A lot of users answered. About 1/3 said it's OK. About 2/3 said that this will be the end of Wikipedia as collaboration project. Or worse. IKhitron (talk) 23:46, 29 May 2017 (UTC)

Hi IKhitron, thank you for sharing information about the Notifications blacklist on hewiki. I'm interested in reading more about the concerns raised in the discussion on hewiki. Could you share a link to the village pump discussion? Cheers SPoore (WMF) (talk) , Community Advocate, Community health initiative (talk) 18:04, 30 May 2017 (UTC)

Sure, SPoore (WMF), here you are: w:he:WP:VP#חסימת תיוגים - האם זה טוב לנו. IKhitron (talk) 18:56, 30 May 2017 (UTC)

Thank you. SPoore (WMF) (talk) , Community Advocate, Community health initiative (talk) 19:07, 30 May 2017 (UTC)

Hello IKhitron, I appreciate the link to the discussion on hewiki. After reading the comments I’m interested in further discussion about the concerns raised. Also, to aid in the discussion about these with the wider community, I’m going to add a condensed version of the issues hewiki raised to the page here on meta. Additionally, I will post to the hewiki discussion to let them know that we saw the discussion and also let the the contributors know that they can discuss it more either on meta or hewiki. Cheers, SPoore (WMF) (talk) , Community Advocate, Community health initiative (talk) 22:03, 2 June 2017 (UTC)

Points made in hewiki discussion

• More important to fix the underlying problem of harassment than introduce this type of feature
• Hurts collaboration
  • by increasing distrust between user that are already in a conflict when added to blacklist and notification don’t occur.
  • by lengthening the time needed to discuss a topic if some doesn’t get a notification of a topic being discussed.
  • generally hurts collaboration
  • Wikimedia Foundation should be creating more tools for collaboration instead of blacklists.
• The blacklist should be controlled by admins instead of an indiv user. An user should request to an admins that an user go on a general blacklist.
• It is unnecessary
  • Most contributors do not experience a problem that the blacklist fixes.
  • Can be solved by contacting the editor and requesting them to stop and then escalate to admin for assistance if needed.
• Some people do not want the blacklist feature deployed on hewiki
• Although many users do not need the blacklist today, some users do, and others may find an use for it at a later time.
• The way that Echo notifications works now, people can choose to not turn on notifications at all or turn different types of notifications off. So already there should be no expectation that a notification that you send will reach someone else.

This is my summary of the points made in the hewiki discussion. Please point out any significant missed points. SPoore (WMF) (talk) , Community Advocate, Community health initiative (talk) 16:40, 5 June 2017 (UTC)

Looks good. IKhitron (talk) 19:07, 6 June 2017 (UTC)

But what's the point?

Aside from thanks-spamming and mention-spamming, I don't see the utility of hiding user notifications. The notifications-blocked user would keep making reverts and other edits which would normally trigger notifications and the receiving user wouldn't know about them, which is arguably a worse situation. Notifications also aren't particularly hard to ignore without having to set a user preference to hide some of them. Jc86035 (talk) 04:29, 31 May 2017 (UTC)

Ability to stop contrib-logs wikistalkers on Wikipedia

Asides from usual spamming, there's particular group of users who'll track other's contributions and stalk them by cause annoyances, for example reverting other's edits. That is one of major problem facing Wikipedia today so perhaps the blacklist should include the power to hide their contrib-logs from those who made them feel annoyed? To boil it down it's much like hiding tweets from certain trolls by clicking the "Block" button against them on Twitter. 219.92.71.23 06:39, 5 June 2017 (UTC)

I want to be sure I understand your proposed idea correctly. Is this example a fair representation: User:Apple blacklists User:Banana from seeing Apple’s contributions. Apple edits the George Washington article, but Banana cannot see Apple’s edit on Recent Changes, watchlist, or any other log page.

If that was an accurate understanding, then I honestly do not think such a feature would work on Wikipedia or any other Wikimedia community. Twitter content is personal — not all content belongs to the community. Wikipedia content is shared and operating within the community is an acknowledgement that your contributions will be visible to all users. There are some personal spaces (notifications, user page, user talk page, etc.) which could be gated by their owners, but shared content feels off the table.

We know wikistalking is one of the most common forms of Harassment and look forward to building solutions with the Wikipedia community! — Trevor Bolliger, WMF Product Manager 🗨 19:02, 12 June 2017 (UTC)

My understanding of the request was that user:Banana would not be allowed to view special:contributions/Apple (they'd see a permission error page similar to what non-checkusers see if they visit Special:Checkuserlog) but would still see Apple's edits in recent changes and page histories. The effect would be to make it harder (but not impossible) for Banana to follow Apple to articles where Banana has not been involved previously. It would though make it clear to user:Banana that Apple had blacklisted them. I think this would be less problematic than not seeing Apple's edits anywhere, but I'm undecided whether I support it or not. Thryduulf (talk: meta · en.wp · wikidata) 23:56, 13 June 2017 (UTC)

@Thryduulf: Oh, that makes a lot more sense as a defense mechanism, while still allowing the users to interact with the same wiki content. It's worth considering if this is a sanction that admins would impose (potentially as part of an iban) or if individual users would have the ability to control their own Contributions visibility. There's a lot to discuss and think about if we were to explore this more. I've added it to Community health initiative/User Mute feature which is where I'm tracking all suggestions for a larger user-to-user Mute feature. — Trevor Bolliger, WMF Product Manager 🗨 17:50, 14 June 2017 (UTC)

Changes we are making to the blacklist before release & Release strategy and post-release analysis

Hello;

I've posted #Changes we are making to the blacklist before release and #Release strategy and post-release analysis for those interested. Feedback appreciated. — Trevor Bolliger, WMF Product Manager 🗨 18:34, 23 June 2017 (UTC)

Rename from 'Blacklist' to 'Muted users'

Hello everyone. Before this leaves beta and released as a feature, we're reconsidering the name. 'Blacklist' feels too aggressive and provocative so we'd like to rename the feature. We're thinking the verb would be to 'Mute.' The section in preferences would be labeled 'Muted users'. Thoughts? Alternative suggestions? — Trevor Bolliger, WMF Product Manager 🗨 20:05, 12 July 2017 (UTC)

For me, both feel agressive. What about ignore? IKhitron (talk) 20:09, 12 July 2017 (UTC)

'Ignore' is fine to me, but 'Mute' is a much more common nomenclature for this type of functionality, right? — Trevor Bolliger, WMF Product Manager 🗨 18:45, 17 July 2017 (UTC)

Deny permission to view special:contributions

Thinking out loud, if a user can prevent others seeing their contributions, there needs to be a tradeoff between preventing malicious users working around a per-username block and preventing abuse. I suggest that certain groups of editors should be able to view anybody's contributions, even if blocked. Certainly edits should not be hidden in the checkuser tool, and Oversighters should always be able to see a users contributions list - possibly after a click-through similar to admins viewing a deleted revision. Should this be available to other groups - to 'crats perhaps? I don't know about extending it to all admins, as certainly on en.wp there are allegations made of stalking against admins and admins who are subject to interaction bans. No global option wider than "all non-admins" should probably be included though (and that should be discouraged), admins having the right to see all contribs unless explicitly prohibited.

Maybe to prevent abuse by spammers, accounts would need a certain access-level (autoconfirmed or extended confirmed perhaps) before having the option to deny visibility of their contributions. I can't think of an instance where we would trust someone not to abuse this but not trust them not to abuse other things that come with those access levels. Alternatively it could be disabled by default until switched on by an admin on request. Thryduulf (talk: meta · en.wp · wikidata) 14:06, 23 June 2017 (UTC)

@Thryduulf: Yes, the obvious workaround for a per-user mute feature is for the harasser to create a new account. Luckily this leaves a paper trail and is a clear violation of most community's policies.

I think it's a safe assumption that checkusers, oversighters, stewards, and bcrats would be able to continue using Sp:Contributions as usual. And I think there's a strong case for admins too. And there could be a multi-solution approach: perhaps permissioned users would see a warning message before viewing Sp:Contribs while non-permissioned users would be blocked outright.

I'm not sure how I feel about setting a account age requirement to use this tool. I understand the desire to keep it from being used maliciously but the optics of it not being available to newcomers would easily be perceived as unwelcoming. I think a better solution would be to have the interface for enabling this feature be clear and descriptive about the community norms and policies for using the mute feature. — Trevor Bolliger, WMF Product Manager 🗨 18:00, 23 June 2017 (UTC)

Hmm, good point about feeling unwelcoming, but I don't want to make it harder to stop spammers and sockpuppetters in their tracks early (not all RC patrollers are admins), and there is no reason for anyone to stalk your contributions before you have made an impression on someone, which is going to take having made several edits at minimum (or having a real-life stalking who knows you account name, and I don't think this will significantly help in that scenario). Perhaps the best solution would be a userright grantable (and revokable?) by admins or automatically assigned as part of another access level with that level settable per wiki. Haven't a clue how easy that would be to code though.

I think would be uncontroversial to allow 'crats, stewards, OS and CUs bypass access to special contribs, particularly if there is the warning message. Whether admins get that access is something I'd prefer to see wider discussion on (not least as I haven't made up my own mind one way or the other). Thryduulf (talk: meta · en.wp · wikidata) 19:11, 24 June 2017 (UTC)

@Thryduulf: You make some good points about sockpuppeters using this feature in a malicious way. Setting a blacklist before making any edits could be benign or evasive. Adding in a new userright is always possible, and certainly something we'll have to think about when we get into the research and design stage. We're waiting to see how Community health initiative/Echo notifications blacklist pans out before proceeding more widely on this User Mute feature topic. — Trevor Bolliger, WMF Product Manager 🗨 16:32, 26 June 2017 (UTC)

I don't think that this is a good idea at all. As I said below, the nature of a Wikimedia project means that people need to take responsibility for their actions and any functionality that hides Special:Contributions negates that. Exempting admins or other functionaries is not nearly enough to solve this issue, as one can see from enwiki's en:WP:ANI many if not most problems are reported by regular users. In addition, I think we need evidence of a substantial problem caused by people following Special:Contributions before implementing any restriction on viewing it. Jo-Jo Eumerus (talk, contributions) 10:14, 3 January 2018 (UTC)

General concern about this feature

I did post this already on Talk:Community health initiative/Blocking tools and improvements but I think it's more generally applicable to any "user mute" features: A number of people (at least on enwiki) mistake disagreement or critique of bad editing practices for harassment. This idea works for a social media platform, not for projects like encyclopedias that have general obligations for readers and whose participants thus need to be held responsible for their contributions to a degree rather than being allowed to hide other people's comments on them away. This would make it easier for bad editing practices to go without resolution and degrade the quality of the projects and potentially of the discussion on them. Jo-Jo Eumerus (talk, contributions) 10:10, 3 January 2018 (UTC)

Yes, I agree that if features like these Mute features lead to a future where most/all users cannot see the comments of a troll/troublesome user then there could be a blindness that forms of how unwelcoming some pages are to new participants. — Trevor Bolliger, WMF Product Manager 🗨 22:23, 3 January 2018 (UTC)

That's one concern, but not actually my concern. My concern is that a lot of alleged "stalking" behaviour occurs when an user is making problematic edits and another user follows them around to fix them. That happens rather frequently on enwiki, probably just as frequently as actual "stalking". Jo-Jo Eumerus (talk, contributions) 09:38, 4 January 2018 (UTC)

Ah yes, I believe I understand your comment now. Use of these Mute features does not absolve the user from abiding by wiki conduct or content policies, and they really are only designed to prevent some low level forms of communication. These Mute features do not affect the watchlist, watchlist emails, or notifications about the user's talk page (including mentions on the users' talk page.) There also exists the preferences to entirely disable notifications and email, and we believe these Mute features are a more granular form these existing all-or-nothing preferences. — Trevor Bolliger, WMF Product Manager 🗨 18:25, 4 January 2018 (UTC)

Yea, I was more concerned about some proposed expansions of User Mute discussed on this page, including user talk pages and Special:Contributions. Jo-Jo Eumerus (talk, contributions) 22:13, 4 January 2018 (UTC)

I try to avoid using the word "never" but — I feel confident saying we'll never build in a user-to-user feature to Mute/block others from viewing Special:Contributions. The benefits are small and the drawbacks are large, and it would probably be easy to circumvent as logged-out users can view Special:Contributions.

Muting/blocking users from editing user talk pages is a different matter. We're not actively pursuing the idea but I can see merits on both sides of the argument. — Trevor Bolliger, WMF Product Manager 🗨 23:45, 4 January 2018 (UTC)