Indefinitely de-prioritized from Anti-Harassment work.

Not to put a damper on this idea but did we all forget about cascading semi-protection? That was removed because it would have allowed non-admins to perform admin actions. Unless we were to restrict adding and removing categories to admins only this would allow anyone to block people under this type of partial block from additional pages. Which is something that should probably be avoided.

I know that this was de-prioritized but I wanted to mention that just in case someone stumbles across this again.

I think the issue of category blocking allowing non-admins to perform admin level actions has been highlighted sufficiently often now that it'll have killed category blocking for the foreseeable future, so I'll only mention it briefly, and only to say it's going to allow people involved in content disputes to try and game category blocks by moving pages in and out of categories as necessary. It'll clearly encourage socking and block evasion which isn't good for our already overworked checkusers.

What I would like to add, that's perhaps new, is that categories aren't fixed entities, they change and move as pages are created, deleted and moved around, categories can be merged (and deleted). If I was going to block a user from editing pages in that category, it would in part be on the basis of the pages within the category at the precise point in time I click the button. I don't much like the idea of the category contents changing significantly after I've made an admin action.

In the light of the above comments, I think the only way this could move forward would be as a way of adding a batch of page blocks at once. e.g. if I was to partially block User:Example and set the target as Category:Ships built in Millwall I would actually be blocking them from the ten specific pages in that category and the category page. If, e.g., HMS Eclipse (1860) were removed from that category they would still be blocked from editing it, but would not be blocked from editing any pages added to the category after the moment the block was applied (an explicit note to this effect in the UI would be good).

Regarding sub-categories, I'd say at most it should apply two levels below the specified category (but 0 should always be an option). Especially on Commons if you follow a high level down a few levels you can get some odd results (e.g. Sex → Sex in humans → Religion and sex → Chastity → Virgin Mary → Things named after Saint Mary → Buildings named after Saint Mary → Saint Mary churches).

How about this: We can add all those pages to a maintenance category like "Category:Partial block of User:Example from PROJECTNAME". In Commons, for example, it would be "Category:Partial block of User:Example from (Wikimedia) Commons". Then, we can set an edit filter to prevent all users but admins from adding or removing this category from all pages (possible using a simple regex). A better solution would be a built-in feature to prevent all users but admins from adding/removing the category. I really see no other way.

That could get unwieldy if lots of users are partially blocked from a given article/set of articles, something quite plausible in topic areas like Israel-Palestine or US Politics. I can also easily foresee it being regarded as a badge of shame (or for certain people a badge of honour) to have their username prominently listed like that.

The best way I can think to counter the latter issue (and maybe the first as well) is for these to be treated as a third class of category (after normal categories and hidden categories) and displayed (a) only to admins and (b) only on request (i.e. default to a collapsed state). Additions and removals of a page from this category should probably be logged somewhere other than the page history for similar reasons.

Actually, the more I think about this it's sounding less and less like a category, but more a special sort of page (similar to Special:EditWatchlist / Special:EditWatchlist/Raw ) that categories could be added to. For example something like Special:PartialBlock/Example (or Special:PartialBlock/User:Example) could include Category:Donald Trump and would result in user:Example being unable to edit any page that was in that category at the time they tried to edit it. Obviously only admins would be able to edit this, and maybe viewing the list could be restricted as well (make it a separate permission so the level can be set however each wiki wants it, maybe default to autoconfirmed).

This doesn't fix the non-admins being able to do admin actions, but I'm thinking that this might actually be best treated as a social problem rather than a technical one: editors adding or removing pages from a category so that another user can (or cannot) edit it would be themselves sanctioned - (partially) blocked or perhaps restricted from adding or removing categories.

What I am hearing is that people want a technical way to enforce "topic bans" and trying to find a way to technically define a topic (via page lists, categories, a combination of those, or a new feature).

In another separate thought: category-based bans may result in a new form of sock-puppetry in which the user uses a sock to remove a page from a certain category so that his main account can edit in it. Just a thought.

In T190349#5809608, @Huji wrote:

What I am hearing is that people want a technical way to enforce "topic bans" and trying to find a way to technically define a topic (via page lists, categories, a combination of those, or a new feature).

Page lists seem the way to go. If the page-ban mechanism can be changed so it 1) doesn't have the 10-page limit and 2) dynamically checks one or more lists of pages that can only be edited by administrators, this would effectively allow topic bans.

Tools can be written to make it easy to create such lists out of existing Category: pages, which would accomplish the example's goal of enforcing a topic ban against climate change: Use the tool to create a list of all pages in all categories related to climate change, then issue a page ban against the user which checks the page list that you just created. Later, if other pages related to climate change needed to be added to the list, an administrator can do so. Likewise, if some were in the original list in error because they were improperly in a climate-change-related category, they can be removed.

I think the bigger issue here is that this feature would allow anyone, even IP editors, to "extend" someone elses block to any page.

In T190349#5809771, @Davidwr wrote:

In T190349#5809608, @Huji wrote:

What I am hearing is that people want a technical way to enforce "topic bans" and trying to find a way to technically define a topic (via page lists, categories, a combination of those, or a new feature).

Page lists seem the way to go. If the page-ban mechanism can be changed so it 1) doesn't have the 10-page limit and 2) dynamically checks one or more lists of pages that can only be edited by administrators, this would effectively allow topic bans.

T208175: Proposal: Blocks should exist as serialized pages

Tools can be written to make it easy to create such lists out of existing Category: pages, which would accomplish the example's goal of enforcing a topic ban against climate change: Use the tool to create a list of all pages in all categories related to climate change, then issue a page ban against the user which checks the page list that you just created. Later, if other pages related to climate change needed to be added to the list, an administrator can do so. Likewise, if some were in the original list in error because they were improperly in a climate-change-related category, they can be removed.

https://en.wikipedia.org/wiki/User:DannyS712/Cat_links

In T190349#5811341, @Xaosflux wrote:

I think the bigger issue here is that this feature would allow anyone, even IP editors, to "extend" someone elses block to any page.

Indeed. Using serialized pages would avoid this, but otherwise there is too much room for abuse. Suggest declining

@TBolliger, @DannyS712
I'm inclined to agree with DannyS712 and others that this proposal can't be done because the risk of a non-administrator manipulating the blocks.

TBolliger, would you be open to "declinging/withdrawing" this proposal in favor of another existing proposal or re-writing it in a way that doesn't have this problem?

A "naive" way to do this - and I'm not suggesting we actually do this, would be to change the proposal as follows:

Leave as-is:

If an admin specifies a page or category to block:

Page blocks can only be set for existing pages/categories only, with validation required in the input field.

Add:

• Category blocks are not blocks on the category, but rather a tool to generate a draft list of pages to be blocked. For category blocks, a list of pages that are currently in one or more categories will be created. The administrator will be allowed to add or remove pages from this list prior to actually setting the block. This list, not the category or categories, will define the pages that are blocked.

Leave as-is:

An autosuggest should help the user find the correct page.
Pages can be from any namespace

Change:

If a page or category is moved, the user should still be blocked from editing (e.g. block by page ID, not page name)

To:

If a page or page that in the list of pages that is blocked is moved, the user should still be blocked from editing (e.g. block by page ID, not page name)

Remove as unnecessary:

If a category is provided, the blocked user cannot edit either the category page itself and all pages within the category.

Consider adding one of the following depending on what is feasible and desirable:

• The list is static and cannot be changed once a block is placed.
• Administrators will be able to remove pages from the list after the block is made.
• Administrators will be able to remove pages from the list after the block is made. If the list becomes empty, the block is automatically removed.
• Administrators will be able to add or remove pages from the list after the block is made.
• Administrators will be able to add or remove pages from the list after the block is made. If the list becomes empty, the block is automatically removed.

If necessary, add

• If the list is modified, the modifications will be logged.

This naive plan obviously only provides partial blocking on any given topic or category, since newly created articles would not be impacted by the block. However, they would be covered by any formal topic ban, as those bans are usually "broadly construed." Editors under topic bans would have to be put on notice that "just because the Wikipedia software lets you edit a page doesn't mean you are allowed to edit it."

I present the "naive" way above in case there is no existing proposal that would accomplish the goal of allowing administrators to use blocks to enforce a "topic ban" or "category ban."