Wikipedia talk:Community health initiative on English Wikipedia/Partial blocks

Help us design this tool!

Hello everyone! The Anti-Harassment Tools team at the WMF will start building these granular blocking tools in a few weeks and we've asked WMF designer Alex Hollender to help us make some wireframes so the tools are intuitive to MediaWiki users.

A rough wireframe of what the tool could look like.

I've written a first draft of how we think this tool should work. You can read the full proposed implementation here but here are the significant parts:

• Granular blocks (page, category, namespace, and file uploading) will be built on top of Special:Block. These blocks will function as if they were regular blocks and allow for the same options, but only take effect on specific pages.
• We will add a new checkbox for "Block this user from the whole site" which will be checked by default. When it is unchecked the admin will be able to specify which pages, categories, and/or namespaces the user should be blocked from editing.
• Granular blocks can be combined and/or overlap. (For example, a user could be simultaneously blocked from editing the articles Rain, Thunder, Lightning, and all pages inside the Category:Weather.)
• Only one block is set at a time, to adjust what the user is blocked from the administrator would have to modify the existing block.
• Block logs should display information about the granular block
• When a blocked user attempts to edit an applicable page, they should see a block warning message which include information on their block (reason, expiration, what they are blocked from, etc.)
• If a category is provided, the blocked user cannot edit either the category page itself and all pages within the category.
• If the File: namespace is blocked, the user should not be allowed to upload files

We like this direction because it builds on top of the existing block system, both a technical and usability wise. Before we get too far along with designs and development we'd like to hear from you about our prosposal:

1. What do you think of the proposed implementation?
2. We believe this should be an expansion of Special:Block, but it has been suggested that this be a new special page. What are your thoughts?
3. Should uploading files be combined with a File namespace block, or as a separate option? (For example, if combined, when a user is blocked from the File namespace, they would neither be able to edit any existing pages in the File namespace nor upload new files.)
4. Should there be a maximum number of things to be blocked from? Or should we leave it up to admin discretion?

Thank you! — Trevor Bolliger, WMF Product Manager (t) 21:49, 3 May 2018 (UTC)

1. I don't think being able to have multiple blocks is a good idea. It should probably be one block, and modifiable as now. I can already imagine trying to figure out *which* block is affecting a user requesting an unblock whom perhaps has 3-5 complex blocks.
2. I think Special:Block would be ideal.
3. File namespace would do the job just fine.
4. There should probably be a hard limit. I don't know what it should be - but there should likely be a limit.

Would this implementation apply to rangeblocks and IPs as well? SQL^{Query me!} 23:05, 3 May 2018 (UTC)

Bullet 2 in the About section says Can be set for usernames, IP addresses, or IP ranges so yes. ~ Amory (u • t • c) 00:56, 4 May 2018 (UTC)

Thanks ever so much, I had missed it. SQL^{Query me!} 01:27, 4 May 2018 (UTC)

"Category" is a huge mess waiting to happen, because then any editor at all can control the block of a specific editor. — xaosflux ^Talk 00:52, 4 May 2018 (UTC)

"Page" is messy as well, how will transclusions be handled? Would it apply to translated versions? — xaosflux ^Talk 00:53, 4 May 2018 (UTC)

Namespace sounds like it could be useful. As far as "uploads" that is an "action", so it should be a separate blockable item, and if going there, just make another grouping for "actions" and block against actions (e.g. you might be MOVE blocked, or UPLOAD blocked). — xaosflux ^Talk 00:56, 4 May 2018 (UTC)

Category blocks certainly give the option for a big mess, but maliciously adding a category to prevent a user from editing sounds like a good way to get blocked yourself. I wouldn't think it'd be a popular option. I do really like the idea of addition "action" blocks — philosophically that fits well since we already block on an action. ~ Amory (u • t • c) 01:14, 4 May 2018 (UTC)

There's already enough edit warring over categories in borderline places, including from IP-hopping anonymous editors. Having those category wars also affect blocks sounds like a bad idea, unless we limit category blocks to special categories that are also controlled by an edit filter. --Ahecht (TALK
PAGE) 17:02, 4 May 2018 (UTC)

@Xaosflux: @Ahecht: Yes, categories seem to be the most potentially troublesome of all these types of blocks and as such should be used sparingly and tactically. We will start with page and namespace blocks first, and save this most risky type of block for the end of the project. Ahecht's idea for a whitelist (and I propose a blacklist) for category blocks sounds like a potential way to mitigate continued abuse.

Our current thought is to keep page blocks as simple as possible: a user would just be blocked from the page itself — not anything transcluded, its subpages, or even its talk page. These can be added as other pages for the block. And if a user keeps finding ways to evade a page block, a larger scale block should probably be considered.

We've created a ticket for move blocks at phab:T194529. Makes sense, in the vein of upload blocks. For our first version we want to bundle the upload block with the File namespace, we may split it out later. — Trevor Bolliger, WMF Product Manager (t) 22:08, 11 May 2018 (UTC)

(edit conflict)Let's keep it simple and have it at Special:Block. Various tools will need to be rewritten, but I really don't want to have to jump around or look in two different places; besides, if they'll be in the same log, they definitely should be made at the same page. And I agree, uploading files should auto-include the File namespace; simpler, makes sense, good backup. I've got one question and one comments:

1. I imagine blocking a namespace won't automatically include the associated namespace, but would category or page blocks include the talkpage? I can see it being desirable but perhaps not required?
2. Only one block per user (like it is today) — to update the block, admins will need to modify the block. and Blocks can be overlapping (e.g. A user can be blocked from 'Rain' and 'Category:Weather') seem contradictory. I understand that you're saying the process doesn't change, just the options — that is, as we can now "reblock" with different times, rationales, removed talkpage access, etc, so too would we be able to reblock with different pages, namespaces, etc — but it does sound a little confusing to use "block" for two different meanings.

Anyway, looks good! ~ Amory (u • t • c) 00:55, 4 May 2018 (UTC)

@Amorymeltzer: Thank you for the feedback. Our current thought is to not include the associated namespace in the block. If you want to block a user from File: and File_talk: you would need to specify both of them in the block. Is this how you would design it?

You're right about the confusing language I used. It's tough that 'block' is both a noun and a verb! After I collate all this feedback and make any necessary changes to our implementation plan I will be sure to use less synonymous words. — Trevor Bolliger, WMF Product Manager (t) 22:08, 11 May 2018 (UTC)

Yup, that's good, just wanted to confirm since it wasn't clear. ~ Amory (u • t • c) 22:33, 11 May 2018 (UTC)

• The suggested tool in the screenshot looks OK, but I don't think it will change much in the way I block users - they generally need blocking from the whole site. It might be useful in the case of Topic Bans, but that would depend on how granular the Category Block system is to be configured. Kudpung กุดผึ้ง (talk) 02:33, 4 May 2018 (UTC)

• On the topic of uploading, that should be a separately blockable capability from the file: namespace changes. Some people may get into trouble uploading copyright infringements, and usually their ban would be just on uploading. But changing other people's uploaded file page would be a different capability and problem. Graeme Bartlett (talk) 08:52, 16 May 2018 (UTC)
  • @Graeme Bartlett: Yeah, great point. It has also been mentioned that there are cases where a user could/should be blocked from moving pages, so we may want to consider breaking this out into 'action blocks' as opposed to granular 'content blocks'. — Trevor Bolliger, WMF Product Manager (t) 18:52, 16 May 2018 (UTC)

• No specific suggestion, but please keep in mind that it would be desirable to design the blocks so that it is harder for someone to violate a topic ban or interaction ban. For example, if someone is topic banned from a page, make it so that he can't edit it. If someone has an interaction ban, make it so that he can't post to thae other users' talk page. It won't stop all abuse, but if it prevents a few mistakes it would be worth it. Possibly crazy idea: could you stop someone from reading a page? with a cookie in case they try it while logged out? --Guy Macon (talk) 03:04, 6 June 2018 (UTC)

Don't forget the API!

Whatever new stuff you add here needs to be added to action=block and included as appropriate in the output of action=query&list=blocks, action=query&list=allusers&auprop=blockinfo, action=query&list=users&usprop=blockinfo, and action=query&meta=userinfo&uiprop=blockinfo. And various "you are blocked" API responses, although all those reuse the code from meta=userinfo.

This should be part of the initial implementation, not left as tech debt to be cleaned up later. Anomie⚔ 14:01, 4 May 2018 (UTC)

@Anomie: Absolutely! I've added it as a Phabricator task to ensure we get to it in a timely manner: phab:T194549 — Trevor Bolliger, WMF Product Manager (t) 22:08, 11 May 2018 (UTC)

It would be better to have an ordinary text page with a list of sites blocked for a user than a special menu or categories

Your "wireframe" shows an admin selecting Donald Duck and Hot Wheels as articles to block in a menu. That works well when there are two articles blocked, but some editors might have a larger list of issues, which could make for an ugly menu. Setting it up for periodic editing might be tedious -- and at the least, it's reinventing the wheel. Categories also seem problematic to block by, since I could change a category and then the user would be free to edit, or I could even obnoxiously add the category to a page where I have a dispute with him just to lock him out for spite. There would be other issues like a user might find that he is blocked from some page he didn't know about, if only admins can view the menu, which could tick people off who are already on the verge.

I think it would be more straightforward to have a full-protected page (deleted and salted for all non-blocked users) at some standard location, maybe User:Username/Blocked pages. It should contain all the information from your wireframe page in a text form. As a result, everyone could see what a user is blocked from and when, and admins could edit that list using only the ordinary editing tools that already exist on Wikipedia. If a graphic form of it exists at all, this would only be a courtesy for an admin to visual-edit the list. Really, it would not be necessary to have any new software at all, apart from that which actually accesses the text page and determines which edits are blocked. However, a visual editor might have features like "add everything from Category:Donald Duck" to build lists of blocked pages quickly, but to put them in a fixed form not subject to hijinks. The goal should be that when an editor gets topic banned from "all pages related to Donald Duck, broadly construed", an admin can rapidly compile a real list of what all those pages are, so that the editor is nearly unable to violate the topic ban, and if he does you can quickly see whether he was trying to. (In other words, if the 'broadly construed' list does not contain Mickey Mouse, the editor has a better sense that he is safe to be editing Minnie Mouse, even if there's something somewhere on the page about her having an avian affair, but if it contains 15 different Donald Duck pages and the editor goes and edits some new article on Donald Duck in Renaissance literature, then you know you have a problem. And so does he.) Wnt (talk) 22:30, 9 May 2018 (UTC)

@Wnt: I do agree that the list of pages a user is blocked from should be easily visible. Our current design has the list appear in the block log and on Special:Contributions. Do you think this is adequate?

While we can technically build this in a manner where an unlimited number of pages can be set, we suggested adding a limit of items (pages + categories + namespaces) that a user can be blocked from, as we do not believe granular blocks should be overused (and keeps the logs sane.) At some point, an editor that requires with this short a leash should be siteblocked. Do you agree with such a limit? or should we pursue a different design?

We do not see categories as a 1:1 replacement for topic bans. To use another example, a 'medicine' topic ban could potentially include every article on Wikipedia — medicine depicted in film, medical beliefs or practices of persons, etc. No category block could fully cover a 'broadly construed' topic ban, but could certainly help for obvious articles. — Trevor Bolliger, WMF Product Manager (t) 22:22, 11 May 2018 (UTC)

I would think that if a ban is not too broad to make it is not too broad to explain. I do think that such massive, overbroad bans pretty much set editors up for failure. But so long as they exist, would it be a bad thing to give the user a genuine list? If need be (sigh) you could even transclude lists... Wnt (talk) 22:45, 11 May 2018 (UTC)

First designs

Hi all!

Thank you for your comments to the "help us design" discussion above. We've enlisted the assistance of Alex Hollender, a User Experience designer here at the Wikimedia Foundation. Here is our first wireframe based on the discussions on this talk page, Wishlist proposal, and Phabricator to date.

We believe the Special:Block page is already at its limits with its current layout and would like to propose this new organized layout. This will make it easier to add the granular blocking (page, category, namespace, etc) and whatever is to come in the future. All of the same functionality is available on this new layout, but in a more organized, step-by-step process. Here's the wireframe:

To set a granular block (as opposed to a full-site block) we have three ideas of how to design this. Currently we are not setting a limit to the number of pages, categories and namespaces a user can be blocked from. We would love to hear from everyone on this page about what you prefer!

We also think we may want to move the block history to the right of the page for LTR wikis for users using large monitors so it is more easily visible:

What do you think of this direction? And what option do you prefer? Thank you! — Trevor Bolliger, WMF Product Manager (t) 00:04, 30 May 2018 (UTC)

I like option 1 — if you're adding multiple block options, it's very clear what you've done, and which are pages, cats, or namespaces. Extra clicks like in option 2 get annoying, and I would think mixing cats and articles as in option 3 would result in some wires getting crossed. Moving the block log seems reasonable: there's already plenty of text on top of everything, at this point the space under the sensitive IP addresses isn't getting used. ~ Amory (u • t • c) 00:41, 30 May 2018 (UTC)

I like option 1/3. Given, I'm one of the few admins who is opposed to even having these options, and I will never use them, but if you're talking about aesthetics and what would be easier to use, those are the ones I prefer. Option 3, with the moved block history, is preferred. That would be much more useful than any of the granular block stuff. TonyBallioni (talk) 23:26, 30 May 2018 (UTC)

• I don't see one of the most requested options (I think), the ability to block for X time (up to indefinite) and separately disable e-mail/TPA for a shorter Y time, or in this case set different elements of the block for different durations (block edits to categories indefinitely + block edits to an article for 3 months + block all edits for 24h or something like that). Also, shouldn't the "expires in" allow custom durations instead of preset dropdown ones? Ben · Salvidrim! ✉ 20:21, 31 May 2018 (UTC)
  • @Salvidrim: Yes, the "expires in" will function the same as it does today — with both a dropdown, a datetime selector, and custom lengths. As for multiple simultaneous blocks: my team and I have discussed this on a near-daily basis for the past month, for the exact purposes you provided. We agree this is an important piece of functionality and want to provide it but have determined that it is technically independent of adding these new granular options. We would like to build this in phab:T194697, but still need to prioritize it against our work on tools to report harassment. — Trevor Bolliger, WMF Product Manager (t) 21:50, 31 May 2018 (UTC)
• Option 1 please, that way we can paste in lists of articles. Also: Bring it! This will be HUGE! Guy (Help!) 21:15, 31 May 2018 (UTC)
• I think I like option 1 best. I like categories and pages being separate. SQL^{Query me!} 22:27, 31 May 2018 (UTC)
• Option 1. One could imagine a situation where I want to prevent a user from editing a category page, but not all pages in that category. MER-C 13:31, 3 June 2018 (UTC)

Category block depth

• Question Maybe this has been discussed, but I've not seen it. What does "categories" mean? If I'm blocked from Category:Living people, does that mean that I can't do anything at https://en.wikipedia.org/w/index.php?title=Category:Living_people&action=edit, or does it prevent me from editing pages that are in the category, or both? Nyttend (talk) 23:44, 31 May 2018 (UTC)
  • @Nyttend: Both! But only one level deep. For example, if someone is only blocked from Category:Weather they would still be able to edit Storm as it is a member of Category:Weather hazards. — Trevor Bolliger, WMF Product Manager (t) 23:55, 31 May 2018 (UTC)
    • TBolliger (WMF), answers like that are why I am so opposed to this: pardon my language, but that’s a clusterfuck waiting to happen. If someone is blocked from Category:Weather, they should not be able to edit anything in the subcategories. Any reasonable topic ban would be interpreted this way. I know I’m the lone voice in thinking this is the dumbest longstanding community wish out there, but what you are describing is significantly worse than what I originally thought was a horrible idea. This type of system will actively increase disruption on the project by helping wikilawyers to find ways around sanctions that would never be imaginable today.
      If we’re going to go down this road, which we apparently are, we should at least make the the technical bits match how the community actually works. TonyBallioni (talk) 02:12, 1 June 2018 (UTC)
      • TonyBallioni makes a good point. Category blocks should be cascading. SQL^{Query me!} 02:16, 1 June 2018 (UTC)
        • No, they should not. Remember that many major categories have tons of child categories down the line. For example, look at this oldid, which contains everything that was a subcategory of Category:Morocco at the time (2011). Were category blocks possible at the time, and were they cascading, someone blocked from the Morocco category would also be blocked from subcategories like Category:Albanian people of the Spanish Civil War, Category:Moorish Revival architecture in Ohio, Category:Gulf War ships of Australia, and Category:Bolivian Socialist Falange politicians. Nyttend (talk) 02:42, 1 June 2018 (UTC)
          • Perhaps cascading should be an option? Or perhaps blocking by category isn't a wise idea. SQL^{Query me!} 02:45, 1 June 2018 (UTC)
            • I like the idea of blocking by category, just as long as it's limited. Going down one level, or going down a few levels, will be appropriate; we just can't let it go down indefinitely. Either have a mandatory number of levels (i.e. it's automatic), or allow us to specify a number of levels (with a maximum, so you can't do 999 levels), I think, but please don't get rid of it and definitely don't make it always cascading indefinitely. Nyttend (talk) 02:47, 1 June 2018 (UTC)
              • Option to cascade to x levels isn't bad tbh. My biggest concern with category blocking is that anyone can change the terms of the block. You can log out and do it, you can make a new account and do it, you can ask your buddy Frank to do it, hell - someone sympathetic may do it for you. Today, if I don't think I can trust you to stick to your topic ban - I'd just regular-old-block you until whenever. SQL^{Query me!} 02:51, 1 June 2018 (UTC)
                • A couple or three levels at most, I think, would be wise. In this case, Ohio is seven levels down on the category tree (Moorish Revival architecture is below Moorish architecture, a component of Moroccan culture), as are the Albanians, while the Australians are six levels down (both wars are subcategories of "Wars involving Morocco"), and I can't figure out where the Falange politicians come into the mix. Even four or five levels might be problematic; Category:Gulf War is only three levels down from Morocco, so a four-level block would result in you being unable to edit Organization of United States Air Force Units in the Gulf War or Yeşilova incident, and a five-level block would include Wag the Dog (novel) and Norwegian Coast Guard. No comment on the block-evasion issue, except for this — how is such a situation different from now? You can log out and edit away as an IP. Nyttend (talk) 03:10, 1 June 2018 (UTC)

And this is why granular blocking is a horrendous idea: the category trees can be a mess: anyone can edit them or change them as an IP or remove categories from pages and by the way, we wouldn’t catch it 99% of the time.

In terms of cascading: indefinite cascading would be the least disruptive option available, and it should be the default with an opt-out. We remove categories that are parents if a child category is there, and no one is going to bother to find every subcategory that someone needs to be blocked from. The WikiLawyering and general disruption this is going to unleash on the project will be endless if cascading is not indefinite by default.

Or more admins could realize that if someone doesn’t have the self-control not to edit Storm when they are topic-banned from weather without technical prohibitions, they are too disruptive to be editing the site as a whole. Like I said, I will never place one of these because either you’re too disruptive to edit at all or you aren’t, but I do want to make sure that we aren’t going to be choosing the absolute worst possible way to implement this, which from what it sounds like we are. TonyBallioni (talk) 03:00, 1 June 2018 (UTC)

Granular blocks are not intended to be a replacement for site-wide blocks, but rather an alternative for situations where an otherwise constructive contributors is causing a disruption in a contained part of the wiki. If the user continues to game the system they should probably receive a full site block. Also, in some cases topic bans may need to exist independent of granular blocks. Blocking from named pages, categories, and namespaces will never be a true replacement for "broadly construed".

Adding infinite category depth is likely out of the question due to technical complexity. In MediaWiki categories are stored as flat, so in order to know that Slush flow is three-deep from Category:Weather (via Category:Weather hazards > Category:Avalanches) it would require a query for all members of Weather, Weather hazards, etc. every time a page is attempted to be edited by the blocked user. I'll talk with my team about supporting one- or two-level deep support. — Trevor Bolliger, WMF Product Manager (t) 16:06, 1 June 2018 (UTC)

Either one is disruptive enough to be blocked from the entire site, or they aren't. Your explanation as to why this will never be a replacement for "broadly construed" is one of the reasons why this will either serve limited user or, in most cases, be harmful if used. I'm aware of what this is supposed to do, I just think that any implementation of category blocking will harm the project.

What we're at now is picking the least bad way for this to be done if category blocking is to be done at all. Something Nick pointed out besides the mess that will be the Wikilawyering is that we are now allowing non-admins to decide what other editors can and can't edit by placing categories on pages. To use the weather example, if I am a caste warrior who has an opponent who is category blocked from Category:Weather, all I have to do to get him to not be allowed to edit articles I don't want him to edit is to add a blocked category there as an IP. We'd never catch it in most cases.

Anyway, I think allowing multiple levels deep category blocking, if indefinite isn't possible, is absolutely needed for this to be less messy. I'd prefer it to be removed from the design altogether because of the other issues it will cause (more socking, non-admins deciding who is blocked from what, more wikilawyering regardless of how it is implemented), but if it isn't, this needs to at least be made user friendly so the damage is controlled. TonyBallioni (talk) 16:32, 1 June 2018 (UTC)

TBolliger (WMF): fix ping TonyBallioni (talk) 16:33, 1 June 2018 (UTC)

@TonyBallioni: Our rollout plan for this is to start small and slowly expand. We plan to first build page blocks, which are more straightforward. Assuming this feature proves beneficial we will proceed to add file upload, namespace, or category blocking next. Categories are certainly the riskiest part of this feature and we need to do it properly, which is why we need feedback to help us identify pitfalls. I appreciate you starting this topic — it's helping us shape our work.

In any of our projects we are open to reversing/changing course if we find we're causing more harm than good. My team doesn't measure success by the number of features released — we are in this to help Wikipedians spend less time on misconduct work. — Trevor Bolliger, WMF Product Manager (t) 21:19, 1 June 2018 (UTC)

@TBolliger (WMF): it would require a query for all members of Weather, Weather hazards, etc. every time a page is attempted to be edited by the blocked user You could go the opposite direction: take all categories of the page being edited, and query their categories, etc., then see if Weather is among them. That'd probably be much more efficient than trying to fetch all members of something like Category:Living people to see if a particular article is present. Anomie⚔ 11:30, 2 June 2018 (UTC)

Mid-discussion summary, June 6

Hi all — thank you for feedback so far on both Meta Wiki and here on English Wikipedia. It seems like Option 1 has the most support, with some folks preferring option 2 or 3. We have two more variations that have come up: Option 1.2 (which swaps the order for full-site and granular blocks) and Option 4 which deemphasizes “full block” by making it a checkbox under granular block. It would still be enabled by default. Any thoughts about these new options?

Other notes:

• We’ve received several comments in support of moving the block log to the right (for left-to-right languages) on large monitors. We’ll have to calculate the exact breakpoint for this to happen so it is still readable, and we may make it scrollable or expandable to save even more space.  
• We’ve received support for separating “prevent user from” and “additional options”
• It has been suggested that we use type-ahead suggestions for pages and make it possible to use a mouse to remove items once selected.
• The ‘Reason’ dropdown needs more room. We’ll address this in the next wireframe, same with adding the ‘other’ text area back for expiration.
• Category depth is still a very real question. I originally suggested that this would only support 1-level deep (i.e. block users from editing pages belonging directly to a category but not pages within its sub-categories) but it has been suggested that categories have infinite depth (i.e. block users from a page if it is in any level of sub-category from the original blocked category.) We’ll need to design something that is not computationally heavy, such as 2-categories deep. More feedback would be greatly appreciated on this topic.
• There is criticism that category blocks will cause problems because they may allow other non-admin users to dictate the parameters of a block by adding or removing categories to a page.
• It has been requested that we drop this project or to build it as a different tool from Block. My team (the Wikimedia Foundation’s Anti-Harassment Tools team) has identified this as a long-requested feature with lots of promise to address situations of harassment and other user misconduct where the offending user does not deserve a full-site block response but should still be quarantined from a part of the wiki. We still believe this tool holds great potential for helpful impact and are proceeding as such.
• It has been requested that we build separate expiration times for granular blocks vs. full-site blocks. We plan to build this after our initial version, which will just be page blocks, in phab:T194697.

We also have some wireframes for how Special:BlockList could be updated. We also think this table could be expanded to Special:Contributions to make the block information easier to read, especially in cases with several blocked pages:

• 
  A wireframe of Special:BlockList showing a new column for the type of block
• 
  A wireframe showing the BlockList design used on Special:Contributions

Please let me know if I’ve missed anything.  We’ll make a new wireframe next week with all this (and any forthcoming) feedback incorporated. Thank you! — Trevor Bolliger, WMF Product Manager (t) 00:45, 7 June 2018 (UTC)

Have you considered a two stage rollout - given that category-based blocking is going to inevitably be a mess that confuses everyone, and makes it much harder for administrators to manage, why not just focus on the areas where this is more likely to work, and be useful, which are namespace-specific blocks, specific page (page ID) blocks, and upload blocking? Those would all be very useful, and be more straightforward to implement, and then we could re-evaluate phase 2 (category-based blocking) in 6 or 12 months' time with all the extra intelligence and experience garnered from the implementation of phase 1. Fish+Karate 14:54, 7 June 2018 (UTC)

@Fish and karate: Yes we have. I ought to write this up and share it more widely. We plan to build this incrementally and release as functionality becomes ready. (This might be to a test wiki, such as test.wikipedia.com or directly here to English, depending on how discussions and development goes.) We are starting with our "minimum viable product" of just single pages. Details can be found at phab:T196578. From here we will build in namespace blocks, then upload blocks (and maybe 'move' blocks) and end with category blocks (if at all, given how complicated they may be.)

We're going to have another round of designs ready next, and I'll be sure to share a more detailed summary of this plan right here next week. Thank you! — Trevor Bolliger, WMF Product Manager (t) 00:20, 9 June 2018 (UTC)

Update: We're putting category blocks on hold, focusing on page and namespace blocks

Hi all, my team shares our project plans and designs here on wiki so we can make sure we're building the best possible tools. Based on feedback we've gotten so far we've decided to put category blocks on hold and instead focus on building page, namespace, and upload blocks first. Category blocks introduce several complexities (how deep should the category blocks apply? how do we monitor bad-faith category manipulation? etc.) that became more apparent thanks to discussions on this talk page — thank you for participating, because we want to make managing uncivil users less burdensome, not more. Once we have all the details ironed out for these more straightforward types of blocks we plan to return to the topic of category blocks, likely not before August of this year. Watchlist this page for more updates.

We're working on another round of designs, which I'll post here as soon as they're ready. Keep the feedback coming, if you haven't voiced your 2¢ yet.

Thank you! ✌️ — Trevor Bolliger, WMF Product Manager (t) 21:41, 12 June 2018 (UTC)

Does Category Ban also include subcategories?

Does a category ban also include articles in subcategories? If not, it would be horribly ineffective. For instance, the Category:Music includes only one mainspace article and a portal, plus a ton of subcategories with significantly more articles. Would those be included too? Smartyllama (talk) 14:39, 7 June 2018 (UTC)

@Smartyllama: The original plan was just to support 1 level deep, but after some discussion we realized this is too shallow. Full category depth is computationally challenging (e.g. every sub-category of every sub-category within Category:Music) but we are currently thinking about 2 levels deep (e.g. the one article directly within Category:Music and all pages directly in its 39 sub-categories. Do you think this would be a good middle-ground way to address this challenge? — Trevor Bolliger, WMF Product Manager (t) 00:23, 9 June 2018 (UTC)

Why a category block rather than a topic ban?

@TBolliger (WMF): I share the concerns expressed by those above who point out that this could easily be evaded or manipulated. It almost invites socking. I understand the reasoning behind it, but it seems to be to be a poor substitute for an ordinary topic ban. Doug Weller talk 10:35, 11 June 2018 (UTC)

@Doug Weller: In some situations, a topic ban may be a better solution than a category block, this feature is not intended to be a full replacement for the bans system (but, if successful, should certainly decrease its necessity.)

The feedback about this project has been clear: categories will be the trickiest part. Thanks to all the comments we've decided to deprioritize it so we can focus just on single pages, namespaces, and upload blocking. We may approach the idea of categories later in the year but for now we're going to put it on ice. — Trevor Bolliger, WMF Product Manager (t) 20:54, 11 June 2018 (UTC)

I had thought that the category block would be for instances where a call for a topic ban vote would be a waste of the community's time. Ian.thomson (talk) 20:58, 11 June 2018 (UTC)

@Ian.thomson: if you look at the discussion further up, it appears that a category block might not block as much as a topic ban, and obviously wouldn't block discussion of the subject in an article not directly related to the category. @TBolliger (WMF):, Thanks for listening and responding. Doug Weller talk 21:11, 11 June 2018 (UTC)

I believe granular blocks, much like (non-discretionary) topic bans, should not be issued in an administrator's individual capacity but only as the result of a community discussion. Hopefully the English Wikipedia community recognizes what a terrible idea this is and bars granular blocks altogether. Take namespace blocks for example: If an editor deserves a block from an entire namespace, then they deserve a block from the entire site. — Godsy ^(TALK_CONT) 12:37, 13 June 2018 (UTC)

They are complementary. A ban could be by category, or by topic with one or more categories used as technical blocking to reduce the compliance monitoring work on the topic. Same reasoning for broadly construed banning, technically perfect matching isn't necessary and partial technically enforced blocks are a handy tool. Human admins have the usual scope for dealing with subsequent abuse, whether it's editing a page subject to a ban outside a subset included in categories or maliciously altering categories. Jamesday (talk) 07:00, 21 June 2018 (UTC)

An odd comment, but something that should be considered, what about "blocks" that are implemented by consent?

Currently blocks don't distinguish between 'imposed' blocks and voluntarily requested ones. The latter are rarely used but it would be clearer fro admins to know if a block was 'imposed' for misconduct, vs a block imposed by consent (due to for example a declared conflict of interest for example), vs a block imposed for technical reasons ( I've sometimes asked for blocks on my account because of security concerns.) Edit summaries in the block log are good, but a formalised distinction for 'blocks' by consent would be appreciated if the granularity of blocking is under development. ShakespeareFan00 (talk) 08:50, 19 June 2018 (UTC)

Hello @ShakespeareFan00: and thank you for your comment. Yes, that is outside the scope of my team's project. It has been previously requested (in phab:T46759 and several places on wiki) that admins should be able to annotate the block log with further comments. We will not be building this now, but it's worth to capture your idea for a potential future project. — Trevor Bolliger, WMF Product Manager (t) 23:17, 20 June 2018 (UTC)

Second designs

Hello everyone, we've continued to make adjustments to the designs based on your input. Most notably we've moved the actions checkboxes to be closer to the sitewide/partial radio buttons. This way admins will be able to set a block against users from just uploading files, moving pages, or sending email. I personally think 'account creation' and 'editing their own talk page' should only be active if 'Sitewide' is selected, as they make little sense by themselves. We've still yet to decide. Please note that we still need to decide what the default values will be for the checkboxes when you navigate straight to Special:Block.

You can also see designs for the type-ahead suggestions, how the box will handle a long list of page blocks, and the radio button and button combination options for block duration. The reason dropdown will appear narrow when collapsed, but on click it will display as wide as necessary. We believe this will keep it just as easy to use the dropdown but it will take only one row.

We also have a design for how this will appear on Special:BlockList, in which the details will be loaded when 'view details' is clicked.

Here are the latest wireframe designs:

• 
  This is the default view for Special:Block
• 
  A partial block configured.
• 
  A partial block with several pages set
• 
  Type-ahead suggestions for namespaces
• 
  Type-ahead suggestions for pages
• 
  How a partial block will look and function on Special:BlockList

What do you think? — Trevor Bolliger, WMF Product Manager (t) 19:51, 28 June 2018 (UTC)

• Looks pretty good and consistent with recent redesign philosophies of other UI elements. Yes, e-mail, autoblock, own-talkpage and account creation should be greyed out unless "sitewide" is selected, as the current policies do not support blocking for these elements without blocking editing in general. (If policy changes in the future this can always be tweaked to allow the options to be set even if sitewide editing is not disabled). Apologies if this was discussed earlier, but will we be able to block editing of page titles for which there is not currently an existing article (redlink)? A small note, will blocking out the "user talk" namespace still allow the user to edit their own talkpage? It should, that's how it currently works, that's why own-talkpage is a separate option. Ben · Salvidrim! ✉ 19:01, 13 July 2018 (UTC)
  • @Salvidrim!: Yes, the "allow users to edit their own talk page" will still work if they are blocked from the entire user talk namespace. We will support redlinks both for pages that have never been created and for pages that have previously been deleted. We'll also store the page name if the page is deleted while a partial block is in place. — Trevor Bolliger, WMF Product Manager (t) 22:35, 13 July 2018 (UTC)

Concerns

I'm not an admin here, so I suppose this isn't really my business. However, I share others' view that if someone is being disruptive they should just be blocked. I also don't think this is the right approach to dealing with harassment. What needs to be changed is policies and enforcement, not the software. In particular, if you want to cut down on harassment of marginalized groups such as women, the "all incivility is equal" approach should be dropped. Hate speech and other gendered/racialized/etc. remarks and behavior need to be a separate blockable offense. AFAIK they're not.

Separately, I've raised the issue of third-party wikis on the Meta talk page, and it's been confirmed that this will be part of core MediaWiki. You can read my objections there. This is clearly designed for use cases on this site such as topic bans, which almost certainly do not apply to the vast majority of MediaWiki wikis. Third-party wikis wear Wikimedia's hand-me-downs; they don't matter. I hope Special:Block is at least kept fairly similar to the existing version.

Of course, none of what I say here is important because this project is going through regardless of what anyone says at this point. ♫ekips39 (talk)❀ 23:50, 10 August 2018 (UTC)

Hello @Ekips39: I've responded to your concerns about building this in MediaWiki core for non-Wikimedia Wikis on the § Non-Wikimedia wikis on Meta.

I agree that addressing harassment on Wikipedia is not just a technical problem. The Wikimedia Foundation's Community Health Initiative hopes to address problems of harassment and incivility by working with Wikipedians to define improved tools (including Partial Blocks), improved policies, and improved opportunities for moderation training. These tools, policies, and moderators need to complement each other for this problem to be alleviated. — Trevor Bolliger, WMF Product Manager (t) 16:44, 13 August 2018 (UTC)

How should partial blocks be logged

Hi all! Our next round of designs is delayed until next Wednesday, September 5. Until then let’s talk about how should partial blocks be logged. Block log entries keep a historical record of every time a block is set, modified, or removed and are used both to answer simple questions (e.g. when does my block expire?) as well as to determine a sequential history of actions (e.g. why was a user blocked 5 years ago? Which admins participated in the blocking procedure?)

Logs currently appear on Special:RecentChanges, Special:Log, Special:Contributions (if a user is currently blocked), and Special:Block. With partial blocks we’re slightly changing how the block notice on Special:Contributions appears (see this mockup) so for the sake of this discussion let’s only talk about how block logs should work on Special:Log, Special:RecentChanges, and Special:Block. We anticipate most partial blocks to only contain a small amount of pages but we want to find a solution that will work if a user is either blocked from just one page or one hundred. Here are our four ideas:

Idea 1 - One log entry per item blocked

• If an admin blocks a user from multiple pages and/or namespaces, a log entry would be created for each item.
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Carbon with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Nitrogen with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace Template with an expiration time of N (reason) (unblock | change block)
• All active blocks would then appear on Special:Log (filterable to the user), which would be how a user would see what pages they are prohibited from seeing
• Pros:
  • Builds off existing structure and behaviors
  • Simple format
  • Works well for simple blocks (around 1-10 pages, namespaces, and/or actions)
• Cons:
  • Repetitive
  • Potentially spammy if a user is blocked from a lot of pages at once
  • Unlikely to be necessary to see this level of granularity on Special:Log and RecentChanges.

Idea 2 - One log entry per block action, simplified

• If an admin sets a granular block, the log could be generic and point to another page that lists the full details of the block
• Example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing certain parts of the wiki with an expiration time of N (reason) (unblock | change block)
• “certain parts of the wiki” could be a link, or a “see details” could be added to the last parenthesis
• We could create a new Special page (or expand a current Special page) to show a history of the pages/cats/namespaces a user is blocked from
• Pros:
  • Saves space, one log entry per block
• Cons:
  • Partial block log entries will not be comparable to other block log entries (e.g. to determine when/who/why a certain page was added to a block.) This problem is addressed in Idea 4.

Idea 3 - One log entry per block action, detailed

• Log every log action as a single log entry
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Carbon, Nitrogren, Potassium, and Argon and the namespace(s) Template with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Antidisestablishmentarianism, Pneumonoultramicroscopicsilicovolcanoconiosis, Winchester-on-the-Severn, Maryland, Saint-Remy-en-Bouzemont-Saint-Genest-et-Isson, Supercalifragilisticexpialidocious, The Name of This Band Is Talking Heads, My Best Friend, General Vasili, Son of Joseph Stalin, United States v. Article Consisting of 50,000 Cardboard Boxes More or Less, Each Containing One Pair of Clacker Balls, Fourteenth Amendment to the United States Constitution, and 1995–96 Courage League Division 4 and the namespace(s) Template, Template talk:, Wikipedia, Wikipedia talk:, MediaWiki, MediaWiki talk:, File, File talk, Category, Category talk, Draft, Draft talk and User with an expiration time of N (upload block, This user has abused a lot of things and needs this very specific block.) (unblock | change block)
• Pros:
  • Single log entry
  • Contains all information about the block, is traceable for changes
  • Works well for simple blocks (around 1-10 pages, namespaces, and/or actions)
• Cons:
  • A single log entry could become unreadable in complex situations
  • "Clogs" up Special:Log and other places
  • Might not be technically possible in big blocks (e.g. user is blocked from 100 pages at once or certain length of pagenames)

Idea 4 - Two logs

• Keep the existing block log as-is, but mark if a block is sitewide or partial
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) sitewide blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talk page) (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) partially blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talk page) (reason) (unblock | change block)
• Introduce a new ‘partial block log’ that only logs each individual item (page, namespace, action) blocked.
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Carbon with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Nitrogen with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace Template with an expiration time of N (reason) (unblock | change block)
• The partial block log could be hidden from the primary view of Special:Log, RecentChanges, and Special:Block, so it wouldn't matter if it was unwieldy
• Could potentially cross-link between the two, maybe showing the block ID.
• Pros:
  • Allows Special:Log, RecentChanges, and Block to be readable, but also allows for the granularity needed to understand the exact contents of a block.
  • Because Special:BlockList and Special:Contributions will show a table view of what a user is currently blocked from, the lengthy nature of the partial block log is acceptable.
• Cons:
  • The partial log could become very lengthy and unwieldy.
  • Are two logs really necessary? Potentially overkill for small partial blocks.

We can also explore other ways of logging, such as how enhanced Recent Changes handles groups of similar actions. Please comment on which would work best or suggest something new. Cheers, SPoore (WMF), Trust & Safety, Community health initiative (talk) 13:57, 13 September 2018 (UTC)

Ideas 2 and 3 seem the best; I don't see the need for a separate log and having one log entry per page blocked from definitely seems the wrong way to go about it. Something in between in detail might also be good, better than Idea 2 which has way too little detail IMO: "TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing 12 pages and 4 namespaces with an expiration time of N (reason) (unblock | change block)" with a link to a detailed list. At the same time, I don't see why any admin would do partial blocks of more than a few pages - if someone is being disruptive more than a few pages a full block would be used; Idea 3 would work well then for the vast-majority of cases. Galobtter (pingó mió) 16:12, 13 September 2018 (UTC)

Linked page block in stead of category

I think that, in stead of category blocking, we should have an option of blocking all pages linked from a given page. This can technically be synchronized by a bot; and has the advantage that it's both easier to track changes, and technically possible to lock the said page from unautherized editing. עוד מישהו Od Mishehu 16:24, 20 September 2018 (UTC)

@Od Mishehu: Good idea, but there could be some gnarly accidental blocks (such as Houston and Texas from Beyoncé.) I think a more appropriate way to handle it is to allow admins to populate the list based on page links but to manually validate the list, if desired. We're also considering a tools that suggests additional pages to block with the 'Related' API in phab:T201102 — Trevor Bolliger, WMF Product Manager (t) 17:27, 20 September 2018 (UTC)

That will lead to bizarre effects, to say the least and IMO, won't be of any practical use. Category blocking seems a better option as compared to this!! ∯WBG^converse 06:25, 21 September 2018 (UTC)

September 21 update

Hello all;

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! — Trevor Bolliger, WMF Product Manager (t) 17:19, 21 September 2018 (UTC)

List of proposed measurements

The Anti-Harassment Tools team plans to generate baseline data to determine the effectiveness of blocks and we'd like to hear from users who interact with blocked users and participate in the blocking process to make sure these measurements will be meaningful.

The full commentary and details on how these will be measured are under § Proposed Measurements. For sake of brevity and discussion here are the seven proposed measurements for determining the effectiveness of blocks:

Sitewide blocks effect on a user

1.  Blocked user does not have their block expanded or reinstated.
2.  Blocked user returns and makes constructive edits.

Partial block’s effect on the affected users

1. Partially blocked user makes constructive edits elsewhere while being blocked.
2. Partially blocked user does not have their block expanded or reinstated.

Partial block’s success as a tool

1. Partial blocks will lead to a reduction in usage of sitewide blocks.
2. Partial blocks will lead to a reduction in usage of short-term full page protections.
3. Partial blocks will retain more constructive contributors than sitewide blocks.

Are we over-simplifying anything? Forgetting anything important? SPoore (WMF), Trust & Safety, Community health initiative (talk) 15:13, 8 October 2018 (UTC)

Special page blocks

I see there are page editing blocks implemented, we should extend this to Special namespace pages as well, like Special:MovePage, Special:Upload. This makes granular blocks much more a better alternative to area-banning editors. --qedk (t 桜 c) 13:49, 11 May 2019 (UTC)

The latter (block from upload) has been considered at phab:T6995 then partly deprioritized by this project, probably until impact of partial blocks is assessed. Block from moving pages is unlikely to be developed separately as it will be redundant to existing partial blocks and traditional move-protect feature, which either or a combination of can be used to block user(s) from moving desired pages. – Ammarpad (talk) 07:46, 12 May 2019 (UTC)

Move-protect makes it admin-only and move-protecting a bunch of pages the user deals in is not a good option, rather ban for a while because of their given lack of understanding page move procedure. Similarly, the problem is partial blocks apply to a page or namespace. --qedk (t 桜 c) 18:54, 12 May 2019 (UTC)

If a user is moving 1, 2 or 3 pages irresponsibly, they could be partially blocked from editing that pages. If they're doing it on 4 or more pages (for instance) they'd be sitewide blocked. It's either one's disruption is mild enough to be contained by a partial block or is so egregious to merit sitewide blocks. – Ammarpad (talk) 04:13, 13 May 2019 (UTC)

"Community health initiative/Per user page, namespace, category, and upload blocking" listed at Redirects for discussion

A discussion is taking place to address the redirect Community health initiative/Per user page, namespace, category, and upload blocking. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 April 20#Community health initiative/Per user page, namespace, category, and upload blocking until a consensus is reached, and readers of this page are welcome to contribute to the discussion. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 12:53, 20 April 2021 (UTC)