The Wikimedia Foundation's #anti-harassment Tools team would like the Wikimedia #techcom to review our implementation plans for our project of Partial Blocks.
Thank you!
----
====Project goals
The goal of the Partial Blocks project is to give wiki administrators a more robust set of tools to be able to better respond to different user conflict situations. To retain constructive contributors who cause disruption on one page (e.g. contentious article page, user talk page of someone they constantly berate, etc.) we want to give admins the ability to block them from editing specific pages and/or all articles inside a namespace.
------
====Hyperlinks
* [[https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking|Project page on Meta]]
* T2674 — Primary phabricator task of prioritized work
* T193449 — Database Admin proposal and discussion Phab task
* T190350 — Larger epic including both prioritized and unprioritized work
----
====Product requirements
//This list is annotated for brevity, see the full list and UI designs at T2674//
* On Special:Block, add a radio button to select setting the block as sitewide vs. partial.
* When a block is saved with the `sitewide` radio button selected, the block should behave exactly as it does today.
* If the `partial` radio button is selected, the admin should be able to provide a list of pages and/or namespaces:
** Page blocks can only be set for existing pages in any namespace, with autosuggest and validation in the input field.
** Namespace blocks can only be for valid namespaces, with autosuggest and validation in the input field
** 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)
* The block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is sitewide (appear as-is today), for a page, for a namespace, or for a page + namespace.
* 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 includes information on their block (reason, expiration, etc.)
* Only one block per user (like it is today) — to update the block, admins will need to modify the block.
* 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 throw an error
------
====Technical Plan
- Schema Changes. The details can be found in T193449 and the patch is available in T197144.
- Add table `ipblocks_restrictions`
- Add column `ipb_sitewide` to [[ https://www.mediawiki.org/wiki/Manual:Ipblocks_table | ipblocks ]]
- PHP API Changes
- Allow `restrictions` to be get/set on a `Block` T197114
- Action API Changes
- Update [[ https://www.mediawiki.org/wiki/API:Blocks | API:Blocks ]] and [[ https://www.mediawiki.org/wiki/API:Userinfo | API:Userinfo ]](?) to list the details of the partial block T197141
- [[ https://www.mediawiki.org/wiki/API:Edit | Edit endpoints ]] will throw an appropriate error when an edit is made to a blocked page or namespace T197117
- Update [[ https://www.mediawiki.org/wiki/API:Block | API:Block ]] to allow partial blocks to be set via the API T197111
- Block Enforcement
- Modify [[ https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/user/User.php;83c9efb5b9ddf52163c77dedaa710db3a3ec9d80$2283 | User::isBlockedFrom() ]] to check if the block is sitewide or not and if not to check to see if the page is on the restrictions list. T197117
- UI Changes
- Update [[ https://www.mediawiki.org/wiki/Help:Blocking_users | Special:Block ]] to allow users to specify whether a block is sitewide or partial. If partial, they will be allowed to specify the pages/namespaces to block. T197109
- Update Block Notices with partial block details T197117
- Ensure that mobile block notices are page specific T197122
- Update Block Log & Special:BlockList T197143 with partial block details. T197108
------
====FAQ
**Why make this a part of Block instead of creating another thing (i.e. "Partial Block")?**
If we were to create a new tool at `Special:PartialBlock` a lot of the existing functionality between Block and Partial Block would be duplicated. There would not only be a separate page to create the block, but also a separate list of blocks `SpecialPartialBlockList` as well as a separate log. New, effectively duplicate API endpoints would need to be created to create and list partial blocks. Lastly, there would also need to be distinct block notices for users who are partially blocked. Not only is this a lot of duplication of existing functionality, it is confusing for new admins to have to different pages to //block// a user.
**Why make this part of core and not a new extension?**
Effectively, because //Block// is in core. The UX should be well integrated into the existing //Block// workflow. Alternatively, it is certainly possible to implement this feature as an extension, but many new hooks will need to be created in order to make the necessary modifications to the existing //Block// workflow. Another alternative would be to pull //Block// out of core completely into its own extension, but that is outside the scope of this issue.
------
====Future work
Depending on the effectiveness of this project (decreasing harassment and user misconduct while retaining contributors) and community response, we plan to add other types of partial blockingProduct plan
With extremely high certainty, potentially including:the WMF's Anti-Harassment Tools team will build the following in the second-half of 2018:
* {T2674}
* {T6995}
* {T194697}
Depending on the effectiveness of this project (decreasing harassment and user misconduct while retaining contributors) and community response, we plan to add other types of blocking in 2018/2019:
* {T194529}
* {T199918}
* {T19034900070}
If partial blocks is a roaring success we may consider future enhancements to partial blocking. I (@TBolliger) feel this is extremely unlikely because of local maximums available for partial blocking — pages, categories, and action blocking will cover the majority of the use cases, and our team has other priorities. The most commonly requested partial blocking functionality that we've prioritized low (for design, technical, and/or social reasons) are:
* {T201853}
* The biggest open question is about topic blocks, which could use categories (T190349), Wikiprojects or ORES classification (T194804.)
* {T202159}
* {T27400}