Community health initiative/Per-user page, namespace, and upload blocking
This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team has prioritized for software development.
The Wikimedia Foundation's Anti-Harassment Tools team is currently in development of partial blocks. Sitewide blocks are not always the appropriate response to some situations. Smaller, more tactical blocks may defuse situations while retaining constructive contributors. The goal of this project is to give wiki administrators a more robust set of tools to be able to better respond to different user conflict situations.
Please discuss this project at Talk:Community health initiative/Per user page, namespace, and upload blocking!
- 1 About
- 2 Updates
- 3 Proposed implementation
- 4 Notes
Types of blocks
No functionality will change for sitewide blocks. All existing blocks will remain in place and the ability to block troublesome users from the entire wiki will remain as-is. In addition to sitewide blocks, we would like to introduce the ability to block a user from:
- Editing one or more specific page(s)
- Editing all pages within one or more namespace(s)
- Uploading files
- Emailing other users
These types of partial blocks could be useful when:
- An otherwise productive user has an agenda on a particular topic (e.g. politics, religion, etc.)
- There is sustained vandalism to one page from an identifiable IP range (e.g. students from one sports team vandalizing pages about a rival team.)
- Two or more users have been sanctioned with an interaction ban
- A user has a repeated history of uploading copyrighted images
- A user abuses the Email User feature but is otherwise productive on-wiki
- A user makes ill-advised edits to templates
These partial blocks would work similar to sitewide blocks:
- Can be set by administrators.
- Can be set for usernames, IP addresses, or IP ranges
- Will include standard block parameters: reason, expiration, talk and subpage inclusion, and the option to autoblock IPs.
- Will appear on the block log, Special:BlockList, and everywhere else sitewide blocks appear.
- When a user has been blocked, they will see a block message displayed that explains what they are prevented from editing in addition to the rest of the block information (the admin who blocked them, when the block expires, the block reason, and how to request an unblock.)
We have a fourth round of designs, based on feedback from our second round in June. Here are the two new designs, detailed UI element views can be seen in the gallery below. in #Designs
Our team is nearly ready to release the first feature set of partial blocks — the ability to block a user from ≤10 pages — on the beta environment then test.wikipedia by mid-October. We are talking with some early opt-in wikis to test the functionality, please let us know if your wiki would be interested in utilizing this functionality, which also gives you a great opportunity to dictate the future of this project!
In other news, due to technical complexity, we have decided to de-prioritize multiple blocks (phab:T194697) and remove it from this project. I've moved the documentation here. This small amount of functionality would take a very large amount of time to build and we first want to make sure page, namespace, and upload blocking work as expected and actually produce meaningful impact. We'll have another round of designs soon and we look forward to delivering a great partial blocks feature in the coming months!
We have our third round of designs almost ready and we want to share them now before we go too far without validating our direction. These designs include functionality to view details about multi-blocks. Because of this change we need to introduce a new piece of information during the blocking process. This led us to the idea of a block modal window, which can theoretically appear on any page — a diff page, recent changes, a profile, etc. This would allow an admin to block a user without having to navigate to another page. Here is how it would work:
// designs redacted, moved here. //
Based on conversations on the talk page, in person at Wikimania last month, and on the TechComm RFC for this project our team has decided to merge the project of multi-blocks into Partial Blocks. The goal of multi-blocks is to allow admins to set multiple concurrent blocks against an account with independent expiration dates, decreasing the manual workload on administrators. Example use cases for multi-blocks include:
- User:Apples has been indefinitely blocked from editing
Neptune. They then receive a 24 hour full-site block. When the full site block expires, they should continue to be blocked from
- User:Bananas is indefinitely blocked from editing
Marsand from editing
Venusuntil 2025. An admin wants to block them from
Saturnfor one month.
- After User:Carrots has violated a wiki policy, an admin wants to set both an indefinite block against
Plutoand a 24-hour sitewide block at the same time, without having to write a self-reminder to update the block.
This will require changes to Special:Block, Special:Unblock, Special:BlockList, and Special:Contributions. We are working on another round of designs (with minimal changes from the last round) which we will post on this page next week. Work for multi-blocks will be tracked in Phabricator at phab:T194697. Our TechComm RFC can be found at phab:T199917 which includes all our proposed database changes and other technical implementation details.
Most feedback we’re receiving at this stage in the project is about one hypothetical — yet entirely likely — workaround a malicious user could exploit to their advantage: a user using a temporary sitewide block to erase (and therefore evade) an indefinite partial block. This could be resolved with manual solutions (e.g. calendars and reminders to reinstate the partial block) but this is inconvenient and interruptive to your workflows and prone to human error. It’s clear that we need to determine a solution to prevent this abuse before Partial Blocks releases to most wikis. There are a few ways to do this and this can get pretty complicated, please help me determine which system we should build:
- Option 1 - Re-blocks
Description: If an admin escalates a partial block to a sitewide block and the expiration date for the sitewide block is shorter than the previous partial block, the admin should have an option for the block to revert to the previous partial block parameters when the sitewide block expires.
Example: An admin blocks User:Apples from editing the page Argentina for 9 months. The same day, an admin modifies the block to Argentina and Bahamas for 8 months. The same day an admin blocks the user from the entire site for 7 months. After 7 months, User:Apples would be blocked from Argentina and Bahamas for 1 more month, after which the partial block would be entirely expired.
This change would only require adding one additional option into the Special:Block UI when a block is being modified.
- Option 2 - Multi-blocks
Description: Admins should be able to set different expirations for different elements of a block.
Example: An admin could block User:Bananas from editing Argon for 9 months, Boron for 8 months, and sitewide for 7 months. After 7 months, the user would be blocked from Argon and Boron and after 1 more month the user would be blocked only from Argon. After 1 more month the partial block would be entirely expired.
This change would require a more significant change to how blocks are currently logged and managed on Special:Block, Special:BlockList, Special:Contributions, and Special:Unblock. Users can be partially blocked from an unlimited number of pages, meaning every page could hypothetically have a different expiration, which could lead to some complicated situations.
- Option 3 - Something else!
We’d love to hear more alternate proposals. Please discuss on the talk page.
For all options it should be possible for an admin to clear all blocks from an account, leaving it entirely unblocked. This will most likely be a change to Special:Unblock.
Join us on the talk page to let us know what you think!
The banner has been disabled because of the delayed code release to major Wikipedias. We aim to re-enable it on all wikis from July 30 to August 3.
From today until Monday, July 23 we will be running a banner on Special:Block to invite administrators to visit this wiki page to read about this project and to provide feedback on our designs. If that banner brought you here, welcome!
This project was slightly delayed due to other interruptive work and unfortunately will not be demonstrable by Wikimania. The entire Anti-Harassment Tools team will be at Wikimania in Cape Town next week, so if you are attending please find us and discuss this project!
We are optimistic to have a functional version of this in early August. We're still planning to build it according to the designs in the June 28 update.
During the last week on July, we will post a banner on Special:Block inviting people to visit this page to learn about our changes. We anticipate a lot of people will join the discussion. Welcome!
We will also be holding a technical RFC in the coming weeks to make sure our architecture decisions are agreeable.
June 28, 2018
This project is currently in development and we hope to have a functional version ready by mid-July to demonstrate how this would work for further feedback. We anticipate a mid-August release to test wikis and will soon be looking for a wiki to try this as a pilot.
We have a new series of designs to share. We believe these should address most feedback we've received over the past month.
Notes about these designs:
- The first mockup shows the checkboxes for 'upload files' and 'moving pages' as unselected. This is an error we will fix in our next round of designs.
- The dropdown for Reason will display as wide as it needs to, based on the customized list on every wiki. It will function as it does today.
- We plan to add in ajax loading for the block history table, which will display under the tool on small monitors or to the right of the tool on wide monitors for LTR wikis.
Previous updates have been posted on the talk page, but moving forward we will provide updates directly here. Here is a summary of the project to date:
- We believe it makes the most logical and practical sense to build this functionality on top of Special:Block as opposed to a new tool, as it shares nearly identical mental models, workflows, and user experiences. We understand that most blocks will be sitewide so the default workflows will be optimized to not interrupt current usage. All changes we make will be additive to existing functionality.
- We have decided to put blocking by categories on hold as it poses some complicated challenges. We will ensure page, namespace, and upload blocking are satisfactory and are achieving the goal of allowing communities to set appropriate sanctions to keep troublesome users productive yet distanced from areas where they cause problems.
- It has been suggested that we abandon this project altogether. Our team, the Anti-Harassment Tools team, strongly believes this will be a useful tool to address situations and we acknowledge this needs to be released to wikis delicately as it will alter how sanctions are set. We do not believe partial blocks will be appropriate for all situations, in some cases socially enforced sanctions may still be needed.
- On Special:Block, add a radio button to select setting the block as sitewide vs. partial.
- When a block is saved with the
sitewideradio button selected, the block should behave exactly as it does today.
- If the
partialradio button is selected, the admin should be able to provide a list of pages and/or namespaces:
- If an admin specifies page(s) to block:
- Page blocks can only be set for existing pages, with validation required in the input field.
- An autosuggest should help the admin find the correct page.
- Pages can be from any namespace
- If a page is moved or deleted, the user should still be blocked from editing that page (i.e. block by page ID, not page name)
- If an admin specifies namespace(s) to block:
- The input field should only accept valid namespaces, with validation required in the input field.
- An autosuggest should help the user find the correct namespace.
- If an admin specifies page(s) to block:
- Help tooltips should display for the new fields
- Block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is partial:
- Log for sitewide blocks should not change.
- Log for page blocks should include
TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Foobar with an expiration time of N (reason) (unblock | change block)
- Log for namespace blocks should include
TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace(s) Foobar with an expiration time of N (reason) (unblock | change block)
- Log for both page and namespace blocks should include
TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Foobar and namespace(s) Foobar2 with an expiration time of N (reason) (unblock | change block)
- The block should be listed and annotated on Special:BlockList, per the designs
- When a user attempts to edit an applicable page, they should see a new type of block warning message using a new string key which include information on their block (reason, expiration, etc.)
- If a partial block is set, the checkbox for
Prevent this user from editing his own talk page while blockedshould be marked as disabled
- The Block API should be updated to support all partial block functionality
- Sitewide blocking via API should not change
- API documentation should be updated
- If a partial block is set via API, invalid pages and namespaces should be ignored
Previously, this project aimed to build the ability for admins to block a user from editing all pages inside a category. This has been put on hold until we build page, namespace, and upload blocking. Category blocks pose unique challenges that need to be addressed before we proceed with development:
- How do we handle categories that may be on the Talk Pages of applicable article pages?
- How many sub-categories deep should the category blocks apply?
- How to address situations where a user may use a sock to remove a category from a page and therefore change their own block?
- Will this introduce a speed performance drag on the user experience?
Functionality for setting more tactical types of blocks has been requested in:
- The 2015 Community Wishlist Survey/Moderation and admin tools#Enhanced per-user / per-article protection / blocking
- The 2017 Community Wishlist Survey/Anti-harassment/Per-page user blocking
- Phabricator ticket T2674 since 2005.
- This was also discussed in our wider Community health initiative/Blocking tools and improvements on-wiki consultation in late 2017 to early 2018.
In addition to simple per user blocking, the Foundation's Anti-Harassment Tools team would like to support the work done by volunteers who set, monitor, and enforce editing restrictions on Wikimedia wikis, as well as building systems that make it easier for users under a restriction to avoid the temptation of violating a sanction and remain constructive contributors.
The Editing restriction page will be used to collate and share ideas about implementing tools to make this work more accurate and more efficient. Join us on Talk:/Editing restrictions to discuss the problems encountered today that could be addressed with tech solutions.