Community health initiative/User Mute features
This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team may build. Development of this feature is complete.
🗣 We invite you to join the discussion!
The WMF's Anti-Harassment Tools team introduced two User Mute features to allow users to prohibit specific users from interacting with them. These features equip individual users with tools to curb harassment they may be experiencing.
The current notification and email preferences are either all-or-nothing, and on-wiki policies (interaction bans, polite requests) can be easily ignored. These mute features will act as a middle step allowing users to receive purposeful communication while ignoring non-constructive or harassing communication. Giving control to individual users over who cannot send them notifications will prevent minor cases of incivility from boiling over into large problems and will ultimately retain more contributors on Wikimedia projects.
Contextualized entry points for mute featuresEdit
The Anti-Harassment Tools team decided to work on unifying the mute lists with the help of a special page, called Special:Mute. There were a few reasons we decided to undertake this project.
Firstly, there has been an idea around what unifying the mute lists for a long time. The email and notification mute lists currently are separate. The email mute list is under the User profile tab in Special:Preferences while the notifications mute list is under the Notifications tab. This makes it hard to discover the two lists. Furthermore, the use case for having the two lists exist separately is not clear.
Secondly, the Anti-Harassment Tools team was slated to work on the User Reporting System at the end of last fiscal year. In preparation for that, we were interested in checking into the hypothesis that harassment often goes unreported on the wikis. If making the mute features more visible increased the frequency of the mute lists being used, that would be a good indicator that there is more on-wiki harassment than we thought.
With the rollout of this feature, there will be a link to Mute preferences in the footer of emails coming from a user and also in the Tools sidebar menu on a user's page. We will be collecting data about the usage of the mute options, most importantly to find out whether there is a use case for muting only one of the options rather the both. We would be sharing what we learn from this data in the future.
A future possibility for expanding on this feature would be to add a link to the special page from the notifications coming from a user.
By default, users are opted-in to receive notifications for several actions on Wikimedia wikis. Two of the most common types of user-to-user notifications, 'Thanks' and 'Mention,' are incredibly useful when used constructively. However, these notifications can be used as a vehicle for harassment if used maliciously.
The Notifications Mute feature will live at the bottom of the "Notifications" tab of user preferences.
For example, if User:Apples mutes User:Bananas on English Wikipedia:
- Bananas can still link to the username of User:Apples on a talk page and successfully save their changes, but Apples will not receive a notification that Bananas mentioned them. Bananas will still receive a 'successful mention' notification, if they've enabled that preference.
- Bananas can send 'Thanks' for an edit made by Apples, but Apples will not receive the notification.
- If Bananas reverts an edit made by Apples, Apples will not receive the notification.
- If Bananas writes a message on User_talk:Apples or participates on their Flow page, Apples will receive a notification. This is the only type of notification that Apples will receive.
- The Notifications Mute list is not global. If Bananas sends 'Thanks' to Apples on a different wiki (e.g. French Wikipedia) Apples will not receive the notification on English Wikipedia, but will receive the notification if they visit French Wikipedia.
- The Notifications Mute list does not affect Watchlist. If Bananas edits an article on Apples' watchlist, the edit will appear to Apples when viewing Special:Watchlist, and Apples will receive a watchlist email, if they've enabled that preference.
This feature is currently live on Meta Wiki and will be released on all Echo-enabled wikis by the end of August 2017.
If a user has verified their email address on Wikimedia, by default the preference to receive emails from other users is enabled. While this can be a productive tool to communicate it is also a big vector for harassment because this communication is not transparent and available on wiki for administrators to witness.
The preference is all or nothing — either all users can send emails, or no users can send emails. We intend to add in the ability to Mute specified users from contacting them via Special:EmailUser.
The Email Mute list will be placed in the 'Email options' sections of the 'User profile' tab of user preferences. It will not be connected to the Notifications Mute list, it will be an entirely independent list.
For example, if User:Carrots mutes User:Durian:
- Durian will not see the 'Email this user' link in the left navigation when viewing User:Carrots.
- If Durian navigates directly to Special:EmailUser/Carrots they will see the standard error message of "This user has chosen not to receive email from other users." as if Carrots had the entire preference disabled.
- The Email Mute list does not affect Watchlist. If Durian edits an article on Carrots' watchlist, the edit will appear to Carrots when viewing Special:Watchlist and Carrots will receive a watchlist email, if they've enabled that preference.
- The Email Mute list does not affect Notifications emails. The Notifications Mute feature must be used for preventing notifications emails.
This feature is live on all Mediawiki wikis.
- Annie feels annoyed by Bobby. He's not breaking any rules but his presence makes her uncomfortable. She wants to continue participating but wants to keep Bobby at a distance.
- Ethel and Frank have received an interaction ban. Frank wants to move on so he wants to protect himself from Ethel's messages.
- George relies on emails to keep up-to-date on his wiki work. Harry is a productive editor but very chatty. No offense Harry, but George doesn't want to see emails triggered by your edits.
Q. User communication is an important part of collaboration on Wikimedia projects. If people use the Mute feature, won't they miss important messages?
- A. This feature may indeed prevent certain important notifications from reaching you, if actions connected with them are performed by the person you are trying to block. Users currently have the option of disabling all notifications, through their preferences. This feature allows a user to receive most notifications, except those from specified users. Therefore, a user will be able to receive more messages than if they had notifications turned completely off.
Q. Why introduce this feature instead of addressing the harassment or disruption with current methods such as warnings, interaction bans, or blocks?
- A. User controlled preference settings empower a user to have some control over whose notifications they receive/see and therefore exclude unwanted notifications while other remedies to address user conduct issues are pursued. Such a quick and easy feature can also prevent negative situations from escalating further and may even contribute to their de-escalation. However, in some instances warnings, interaction bans or blocks may still be needed.
Q. Why is the muted user not informed that they have been muted?
- A. Sometimes tools are effective exactly because their use is not advertised. Informing a user that they have been muted may exacerbate an already strained relationship; it can cause the muted person to attempt to make contact in other ways where the person using the mute tool continues to feel uncomfortable or harassed. Individual users can chose to manually inform users they have muted, if they want to.
Q. Why introduce this feature when there are already community policies in place to report harassment?
- A. The existing workflows for reporting small-scale incidents of harassment are not always effective or timely. This tool can offer immediate relief to the user from an escalating situation. It may also help reduce the workload for admins, as all users will have a new tool to protect themselves from harassment and using it would, in a way, impose a comms break between the two users which could de-escalate the issue and prevent further reporting.
March 13, 2019Edit
The Wikimedia Foundation's Anti-Harassment Tools team has prioritized enhancements to Mute features for the months of April - June 2019. We are currently generating data on how these current Mute lists are being used. Our team will publish some findings on this page or the talk page once our analysis is complete. You can track our work at phab:T216185 and here is a quick preview:
- Across all wikis, less than 2% of users who have customized one Mute list have the exact same users Muted from both email and notifications. This may be intentional or unintentional (due to a lack awareness, due to having all email disabled, having partial overlap, etc.) so more research is required. Our team still believes there would be a strong user benefit to merging both the Email and Notification lists into one list.
- The "Allow email from brand-new users" is the most popular of notification preferences, with ~750 users/month disabling the option. The overall "allow email" preference is used by ~500 users/month. (This data is from English Wikipedia but is similar on most other wikis.)
- Both the Mute list features are seeing small but steady usage, in the ballpark of one hundred of users per month, across all wikis. Our biggest theory is that the preferences are too buried, so we will be pursuing some product tactics in the coming months:
Additionally, we'll be looking into making the lists work cross-wiki. We may not have time to build the 'perfect' system as described in phab:T167902 but we will look at some potential changes in phab:T218263.
As always, if you have thoughts about these ideas or suggestions of your own, please leave us a message on the talk page. Thank you!
- Unify the lists and make them work cross-wiki. (We would also determine a migration strategy to combine the two existing Mute lists.)
- As a special page.
- Merge both lists within Preferences
- Change the UI to push users to Global Preferences instead of local Preferences
- Prevent additional communications
- Prevent the muted user from triggering watchlist emails
- Prevent the muted user from editing wiki pages attached to their username, such as their user page, user talk page, and/or subpages
- As an alternative, the UI could display a warning message (e.g. "USERNAME has requested that you not post on their talk page unless absolutely necessary.") to the muted user but still allow them to edit
- Collapse comments on Talk pages and Flow threads made by the muted user — T173461
- Warn the person when they are about to edit a page that was recently edited by a user they have muted.
- Improve the user experience of the existing functionality
- Allow people to Mute another user via the 'Tools' list on user pages
- Allow people to Mute another user via a link in the notification itself
- Allow people to Mute another user via a link in the email footer
- Expand this functionality into admin tools
- Consider a feature that allows admins to mute two users from each other, as a form of Interaction Ban
- Consider a feature that allows admins to disable Mute features for users who abuse the feature
- For the feature that allows individual users to broadly protect their user pages, see User and User talk page protection tools.
- Grants:IdeaLab/Allow users to restrict who can send them email
- 2016 Community Wishlist Survey/Categories/Miscellaneous#Allow users to restrict who can send them notifications
- 2016 Community Wishlist Survey/Categories/Miscellaneous#Allow users to restrict who can send them email
- The Anti-Harassment Tools team will build functionality described in Phabricator task T138165 to allow users to set a preference to disallow emails from certain levels of users (e.g. all users, confirmed users, admins only.)