I'm curious to what approach would be best for this? A site-wide blacklist of users who shouldn't trigger user talk page notifications supplemented by a page in the user namespace (something like User:Example/User notification blacklist). This does have the disadvantage of being publically visible, which is probably bad. Perhaps an option in the user preferences?

@Mainframe98 I think a secret blacklist is better as you suggested. Otherwise you are at risk of being even more harassed from people that discover that they are on the public blacklist.

This is already possible using an AbuseFilter, and if the list has to be secret you can just make that filter private.

@Nirmos

In T165124#3260370, @Nirmos wrote:

This is already possible using an AbuseFilter, and if the list has to be secret you can just make that filter private.

If Wikipedia installed https://www.mediawiki.org/wiki/Extension:AbuseFilter , could I then prevent specific people from using my Talk page by adding them to a blacklist on Preferences?

Allow users to restrict who can send them notifications

If Wikipedia installed https://www.mediawiki.org/wiki/Extension:AbuseFilter

AbuseFilter is already installed on Wikipedia wikis.

could I then prevent specific people from using my Talk page by adding them to a blacklist on Preferences?

Not in Preferences, no. Filters are managed at Special:AbuseFilter.

@Nirmos Thank you!

Can you please give me specific instructions how to use https://en.wikipedia.org/wiki/Special:AbuseFilter/new to block TheTroll (fictional user name) from accessing my Talk page: https://en.wikipedia.org/wiki/User_talk:David_Hedlund?

Off-hand, I imagine the ruleset would be something like

article_prefixedtext == "User talk:David Hedlund"
& user_name == "TheTroll"

@Nirmos Thank you, that is really useful!

@Nirmos I have not tried it, I'll let you know if it worked later.

@Nemo_bis How do I add https://phabricator.wikimedia.org/T150419 as a "parent task"? I need to learn.

@David_Hedlund: "Edit Related Tasks..." in the upper right corner. But I don't see how T150419 is blocked by this. The current parent task T164542 feels correct.

AbuseFilter is enabled on ENWP but requires membership of the editfiltermanager group to edit filters and therefore can't scale to a per-user basis. There are hundreds of thousands of active users across all Wikimedia projects — and while I assume the vast majority would never use this functionality AbuseFilter is not a scalable solution.

While a private blacklist under user preferences would be ideal, upon leaving a message the user would find out either by checking if message was left or a warning. Now it could be implemented as a fake edit but...any determined user would just start abusing account creation making this useless along with the worst case scenario of a proxy being involved.

The current summary is clearly a WONTFIX: random users cannot decide the editing permissions of an entire namespace. I suppose you mean that each user should be able to restrict their own user page, talk page and subpages thereof? (Which is not gonna fly anyway, but feel free to beat the dead horse.)

In T165124#3309389, @Nemo_bis wrote:

The current summary is clearly a WONTFIX: random users cannot decide the editing permissions of an entire namespace. I suppose you mean that each user should be able to restrict their own user page, talk page and subpages thereof? (Which is not gonna fly anyway, but feel free to beat the dead horse.)

The point was to allow individual users to restrict user contact just like on other websites such as Twitter, FaceBook, DiscordApp. There is no reason to force users to rely on administrators (usergroup with block permission) at a locally hosted wiki or on WMF staff/volunteer administrators, there are places where the administrators or staff simply don't care and that places users at the disadvantage of being forced to leave which should only be a last resort. Yes, this may not be high priority for WMF but rather would be useful for those that run their own wiki.

It's not about "priority" but about avoiding to completely break collaboration on wikis. For instance, if I can't edit a userpage I have problems with, my only option is to ask administrators directly (without the user even knowing) to delete it.

Such specialised feature requests which rely on assumptions about specific wikis' culture and collaboration models are normally filed in MediaWiki-extension-requests by the way.

@Nemo_bis — First off, thank you for renaming this ticket to a more descriptive title. 👍

I acknowledge that this feature idea needs more research and discussion to understand how it could affect collaboration on various wiki communities. The Anti-Harassment Tools team believe these conversations are worth having, therefore this ticket is on our backlog. A ticket on a backlog does not guarantee it will be built.

The other side of the "break collaboration" discussion is that users cannot collaborate if they've quit the project due to prolonged harassment. If this idea gains momentum we'll want to design it so users clearly know its implications/ramifications.

It's also worth mentioning there are half-measure alternatives: blacklisted users could see a warning instead of an outright rejected edit, blacklisted users could be throttled to a certain amount of edits per time period, etc.

In T165124#3309873, @Nemo_bis wrote:

It's not about "priority" but about avoiding to completely break collaboration on wikis. For instance, if I can't edit a userpage I have problems with, my only option is to ask administrators directly (without the user even knowing) to delete it.

I understand the concern of not breaking collaboration. I am not saying to deny editing userpages but does anyone besides the owner of that page really need to edit it? Generally, there's no need. If you have problems with a userpage, the first approach should be to leave a message on their talk page; there's no reason to go immediately to administrators unless its unacceptable content. It's hard enough to edit at Wikipedia already where I have encountered those with rollbacks not paying attention to latest information and just reverting practically every edit & ignoring communication attempts as well as heard of some administrators repeatedly blocking a particular user for seemingly no reason & getting away with it, not to mention independent wikis outside of WMF could lead to bad situations involving harassment. Many times warnings are used, sometimes those are ineffective and its at those times its easier for the user to just block the target from leaving them messages rather than ignoring notifications.

Now perhaps a permission or for admins to override this to leave a message but the overall issue is if they won't take proper action then you risk losing potential editors because volunteer admins won't enforce policy properly whether at WMF or not. A small issue not properly resolved can turn into an uncontrollable inferno. This isn't to say that trolls, vandals, spammers won't abuse this as well but those disrupters don't heed warnings anyways to begin with so blocking immediately is the general tactic.

in a nutshell: its best to always have something & never have to use it then to need it & it not available. its hard to balance this but keep in mind that not everyone online has the best intentions of collaborating even if not intentional.

Such specialised feature requests which rely on assumptions about specific wikis' culture and collaboration models are normally filed in MediaWiki-extension-requests by the way.

T150419 already started to implement a MVP for this

does anyone besides the owner of that page really need to edit it

Yes, collaboration in user space is very useful on Wikimedia wikis and absolutely necessary in a number of cases (without it, we'd often have to give up on the user, i.e. block or disgruntle them, making our wikis less inclusive). In particular it's important:

• to help newbies with the syntax and content of their user pages;
• to help users improve their sandbox pages before they get into main namespace (if they choose to go the sandbox way);
• to collaborate on smaller personal projects which are not felt appropriate for project namespace but interest more than one user;
• to fix and maintain content of user pages and subpages of "important" or inactive users who don't manage to do it themselves;
• to keep archives on discussions functioning (e.g. fixing broken links or broken wiki syntax), since a lot of discussion relevant for the community or for articles happens in user talks;
• to take care of certain inappropriate content on user talks by other users, such as spam;
• etc. etc.

There is practically no way this can ever work on Wikimedia wikis, unless perhaps it's some special feature which only admins can enable (and disable) for users. In core it could be implemented with two feature requests: one to allow page protection to apply only to a list of users, and another to have page protection apply to all subpages of a page (with some restrictions). Otherwise, it needs to be an extension.

already started to implement a MVP for this

That's quite a different thing, it's about muting the edits rather than forbidding them.

In T165124#3312438, @Nemo_bis wrote:

does anyone besides the owner of that page really need to edit it

Yes, collaboration in user space is very useful on Wikimedia wikis and absolutely necessary in a number of cases (without it, we'd often have to give up on the user, i.e. block or disgruntle them, making our wikis less inclusive). In particular it's important:

• to help newbies with the syntax and content of their user pages;
• to help users improve their sandbox pages before they get into main namespace (if they choose to go the sandbox way);
• to collaborate on smaller personal projects which are not felt appropriate for project namespace but interest more than one user;
• to fix and maintain content of user pages and subpages of "important" or inactive users who don't manage to do it themselves;
• to keep archives on discussions functioning (e.g. fixing broken links or broken wiki syntax), since a lot of discussion relevant for the community or for articles happens in user talks;
• to take care of certain inappropriate content on user talks by other users, such as spam;
• etc. etc.

There is practically no way this can ever work on Wikimedia wikis, unless perhaps it's some special feature which only admins can enable (and disable) for users. In core it could be implemented with two feature requests: one to allow page protection to apply only to a list of users, and another to have page protection apply to all subpages of a page (with some restrictions). Otherwise, it needs to be an extension.

General protocols is unless the user requested help, you really shouldn't be touching or updating user pages. Unless you are suggesting that Wikimedia does not have this...

This proposed idea is not to prevent everyone, it's targeted only towards those that are disturbing or harming a user from communication. Nothing to impact you or regular users. as @TBolliger said, there won't be collaboration if the user quits the project or what they are working on due to harassment

one to allow page protection to apply only to a list of users

that's the main idea and we can go one step further by giving admins, staff overrides. If admins or staff are being blocked on a user individual level then prompt a reason unless there are valid ways to report such users in private/confidential manner. It is at times difficult to report a volunteer admin if they are abusing power for their own benefit., checks & balances are needed as there are two sides of the coin to collaboration. That's just for WMF, a new permission would be best since other independent wikis might have custom user groups. Now implementation would require restructuring protect permissions possibly.

I owe both Ghost and Nemo responses to their comments, but I wanted to temporarily leave a note that I've created T176270: Allow users to restrict which user groups can edit their own user page, talk page and subpages thereof as a variation of this, focusing on groups and not individual users.

@Nemo_bis & @SpookyGhost8;

I'm of two minds if we should split this into two tasks: 1) user page (and subpage) muting & 2) user talk page (and subpage) muting. They are different beasts and need to be thought through differently. A one-size-fits-both feature will certainly fail.

At present, I think the idea of setting this protection only on admin request is the most likely solution at succeeding.

@TBolliger
Splitting this into two tasks is a good idea as they are different enough. Allowing admins to remove offensive content, vandalism and leave talk page message by default is expected. yes, for now admin request would have to do until this is built.

I've split this into T176351: Allow users to restrict specific users from editing their own user page and subpages thereof