Hi @daniel — we're working with @kaldari to organize for your and TechComm's request for a technical RFC.

@TBolliger Thank you!

For namespace blocks, it should be possible to specify a list of excluded pages. For example, if the user talk namespace is blocked, there should be able to exclude a pages of several admins that the user can ask, or page for requests to administrators for project namespace block.

In T2674#4400001, @putnik wrote:

For namespace blocks, it should be possible to specify a list of excluded pages. For example, if the user talk namespace is blocked, there should be able to exclude a pages of several admins that the user can ask, or page for requests to administrators for project namespace block.

@putnik Good idea. I can see that having one or more excluded pages could be useful in several workflows.

I also think that it would be quite good to forbid the creation of pages from a namespace, but not their editing. It can be sometimes useful. For example, if the participant has no to create articles, but corrects spelling errors in others.

For our initial implementation of this project we're going to keep it simple — allowing sub-actions within a namespace/category/topic is pretty niche for what we're trying to accomplish in the short-term.

I do agree that "page creation" should probably be a separate option to block, such as uploading files.

@daniel — I owe you an update. Between summer vacations and prep for Wikimania our bandwidth is limited, but we are still planning submit a TechCom RFC. We are aiming to have it ready for you by July 25.

I think, partial blocks are needed for perform topic-bans, and adding more features which block some actions are necessary instead of full block.

In T2674#4427537, @Marshmallych wrote:

I think, partial blocks are needed for perform topic-bans, and adding more features which block some actions are necessary instead of full block.

Partial blocks will certainly be one tool to help enforce topic bans, but there will still be need for socially enforced methods, as "broadly construed" is too difficult to capture in a block.

Just a suggestion, but maybe a whole separate log for these "blocks" could be created called "Restrict logs" where other than "Blocks" "Restrictions" are listed, as for the suggestion to create restrictions on Wikimedia Commons users to only be able to upload files of course editing "File:" Belongs to that as these files might need to be recatrgorised. Maybe for sysops a button separate for "block" and "restrict" could also be created.

In this scenario block logs would only record full sitebans and restrict logs restrictions from certain spaces or abilities (e.g. Uploading files, creating new pages, editing certain name spaces). Also this would be beneficial for users with interaction bans as then neither party could edit each other's user talk pages.

Addendum: As in my above suggestion "Block" and "Restrict" would be teo different settings (maybe even using a separate API) these could both be in effect at the same time without affecting the other as with the above example relating to the Utah editing restrictions.

In T2674#4433604, @TBolliger wrote:

In T2674#4427537, @Marshmallych wrote:

I think, partial blocks are needed for perform topic-bans, and adding more features which block some actions are necessary instead of full block.

Partial blocks will certainly be one tool to help enforce topic bans, but there will still be need for socially enforced methods, as "broadly construed" is too difficult to capture in a block.

What do you mean difficult? If you are going to make this tool, so take the trouble to make it good and in full force, not "I can't, it's hard", sorry.

In T2674#4433696, @OlegCinema wrote:

What do you mean difficult? If you are going to make this tool, so take the trouble to make it good and in full force, not "I can't, it's hard", sorry.

Sure, let me explain what I mean by 'difficult' using the example of a topic block about religion.

A partial block could be set against the articles about religion (religion, christianity, hinduism, islam, etc.) and T190349 could introduce the ability to block anything within categories about religion (Category:Religion, Category:History of religion, etc.). If the user creates troublesome new pages they could be blocked from creating new pages.

It become more difficult to proactively enforce on articles not within these categories, or within weakly related categories. The article about Tom Cruise belongs to several Scientology related categories, but the banned user should still be allowed to edit about Tom's acting career. The article about the actor Michael Cera does not belong to any religion related categories, but the banned user could add information about Michael's religious views against the ban.

It has been suggested that we expand AbuseFilter to focus on filtering editing for certain users as opposed to certain pages/namespaces/actions, but our software developers estimated that such a project would take well over a year to build, with partial blocks taking significantly less time. Our Anti-Harassment Tools team has other priorities in addition to this project.

In T2674#4311252, @daniel wrote:

During last week's the TechCom meeting, we came to the conclusion that this should go through the RFC process.

RFC ticket here: T199917: RFC: Block users by page, namespace, and/or action (Partial Blocks)

Thank you.

Also, here I suggest:

* 16:01, 22 May 2018 Tegel (talk | contribs) blocked Brion VlBER (talk | contribs) with an expiration time of indefinite (account creation blocked) (Vandalism)
* Block parameters: 
** Editing: User talk:Tegel, User:Brion VIBBER, Manual:DefaultSettings.php
** Account creation
** Moving pages
** Upload files

I expressed this on meta too, and am copying it here as well:

Imagine a user is indef blocked from editing in Wikipedia namespace, because of a history of disruptive edits in that namespace. Then that user insults someone else on their talk page, so I decide to block them everywhere for 1 week. I go ahead and change the block settings accordingly. At the end of the one week, the user will be unblocked everywhere.

This is an important side effect of the "one block per user" idea, which is part of this proposal. Instead, we should allow for multiple blocks per user. That way, I would add a *new* one-week block for all namespaces, and at the end of it only that block will expire, while the other namespace-specific indef block will continue to exist.

@Huji I completely understand the use-case and I agree that this is a problem that needs to be resolved. We created T194697 and after some investigation, we discovered that it's effectively a completely separate project that has no relation to this project at all. The only relationship is that... it's somewhat pointless to create multiple sitewide blocks for the same user/ip. We could do T194697 before doing this project, but what would be the point? At the same time, adding T194697 to this project constitutes scope creep since there isn't any overlap between the two. The irony is that this task (as well as T104099 & T6995 which are also separate projects) exposes the multi-block issue that wasn't a problem before. We are effectively creating a new problem (and perhaps that's not a bad thing).

A slight mitigation to this issue will be that we will preserve the existing pages/namespaces that were specified when switching between a sitewide and partial block. I realize this doesn't fix the multipile expiry issue, but at least you'll be able to manually go in and switch between the two without having to re-specify the pages every time. The work-around would therefore be to update the indefinite partial block to an indefinite sitewide block, and then manually switch them back to partial at the end of the week. I understand that this is far from ideal.

I completely understand.

But let's think about it this way. The current task says "replace the bedroom carpet". T194697 says "the pipes passing under the bedroom are slowly leaking". These are two separate issues, but if we are going to bring contractors in (akin to: have developers refactor this part of the code), I guess it is best to fix both issues at the same time.

If we fix this first and fix T194697 later, we will have to peel the carpet again (akin to: refactor the blocking interface again) once we enable multiple blocks, or use any other alternative solution. You could say "but I don't have enough money to pay for contractors for both jobs right now, and that is why they have been both waiting for so long" (akin to: we cannot dedicate development time to both of these tasks, and that is why they have been waiting for several years each), and I would understand. But I would hate to see the new carpet being torn apart.

We'll tackle T194697 after T2674, it's merely a question of sequencing. We likely won't release this on any large wikis until T194697 is complete.

(TechCom triage note: sub task T204991 has had implementation work begin, at https://gerrit.wikimedia.org/r/470656.)