As noted on the talk page, a plain reading of https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Protect_user_pages_by_default doesn't seem to find consensus to make such a drastic change. The option that received the most supports numerically was option 1 (no change), as far as I can tell.

Yeah, this is not something MediaWiki allows us to do.

Per MZMcBride comment here, and Andy Wang on the RfC talk page.

+Consensus-needed tag as it has been questioned

I've filled a task, T149484, to separate the development of the feature (there), and the en.wikipedia request of this feature (here).

Created subtask T149501

Maybe an edit filter can do this.

In T149445#2754577, @Urbanecm wrote:

Maybe an edit filter can do this.

@MusikAnimal i know you at least used to manage filter whats your input on this?

The only problem will be the 5th point.

Yes, we can do this with an edit filter quite easily, and that seems like best solution as I suspect there's a lot of work involved to get this functionality in MediaWiki core. I agree with others that there doesn't seem to be a clear consensus for this, though, and we definitely will need that.

Should we run an inital test to see if this infact would work as intented say like on wikitech or mw sites? @MusikAnimal

In T149445#2755139, @Zppix wrote:

Should we run an inital test to see if this infact would work as intented say like on wikitech or mw sites? @MusikAnimal

I've created a log-only filter on enwiki at Special:AbuseFilter/803. It's true the 5th point (user pages of nonexistent user) may not be enforceable with the filter, and while we can enforce the 6th one (IP user pages), doing so would be somewhat expensive. I believe both are very much an edge case, and I find the appropriateness of creating a userpage for a nonexistent user on par with editing that of an existing user. Creating IP user pages is by itself is very rare, but the filter would still allow that IP user to create it. The only use case I can think is where one of our many anonymous patrollers might want to tag an IP user page as a "suspected to belong to User:Sockpuppet", but they can put that on the talk page.

Filter is working great, so I've gone ahead and disabled it until we know what we're doing. Unconfirmed edits to someone else's talk page happens frequently, and indeed most of what I see is bad-faith and/or vandalism. There are some legitimate uses where an anonymous user, perhaps the actual user while logged out, is helping with a draft article they put on their user page. This is something we've already tried to deter, e.g. try creating a user page (example) and you'll see the edit notice encouraging creating a userspace draft instead of using their user page. That edit notice could probably use updating (telling them to use the Draft namespace, etc), but that's beside the point. All in all I think the edit filter solution will suffice, if we do have consensus to set it to disallow.

More advantages to the edit filter over actual semi:

• All disallowed edits are logged, so we're able to track abuse and good-faith attempts
• We can show a customized friendly message, e.g. "Editing of another user's userpage is disallowed to prevent against abuse. If this is your userpage, please log in to edit"
• We can alternatively issue a warning then allow them to save, or simply tag the edits. Doesn't have to be disallow.
• We can still allow editing from privileged users who are locally unconfirmed, such as stewards, global-rollbackers, etc. (they may already be able to edit semi-protected pages, not sure)

Note some other wikis are already have similar filters, such as Korean Wikinews

In T149445#2755368, @MusikAnimal wrote:

More advantages to the edit filter over actual semi:

• All disallowed edits are logged, so we're able to track abuse and good-faith attempts
• We can show a customized friendly message, e.g. "Editing of another user's userpage is disallowed to prevent against abuse. If this your userpage, please log in to edit"
• We can alternatively issue a warning then allow them to save, or simply tag the edits. Doesn't have to be disallow.
• We can still allow editing from privileged users who are locally unconfirmed, such as stewards, global-rollbackers, etc. (they may already be able to edit semi-protected pages, not sure)

Note some other wikis are already have similar filters, such as Korean Wikinews

I like the idea of showing a friendly message, and logging to track how many of these edits are abuse vs good-faith.

ETA: I should note though that the closer of the RfC specifically said that the consensus was for semi-protection, and this filter option sounds like it would still allow very new accounts to edit (essentially, option 1.5 of the RfC). I do understand that the close is being questioned, and the admin has been pinged for clarification.

In T149445#2755428, @Funcrunch wrote:

ETA: I should note though that the closer of the RfC specifically said that the consensus was for semi-protection, and this filter option sounds like it would still allow very new accounts to edit (essentially, option 1.5 of the RfC). I do understand that the close is being questioned, and the admin has been pinged for clarification.

The filter is currently set to target unconfirmed users, so would effectively be the same as semi-protection

In T149445#2755468, @MusikAnimal wrote:

In T149445#2755428, @Funcrunch wrote:

ETA: I should note though that the closer of the RfC specifically said that the consensus was for semi-protection, and this filter option sounds like it would still allow very new accounts to edit (essentially, option 1.5 of the RfC). I do understand that the close is being questioned, and the admin has been pinged for clarification.

The filter is currently set to target unconfirmed users, so would effectively the same as semi-protection

Thanks for the clarification. Though I like the advantages of a simple filter, a complication I could see is if someone did want to keep their own user page open to anonymous/new user edits. With default semi-protection, they would be able to request that an admin remove this restriction from their own user page. Would they be able to opt their own user page out of this filter?

In T149445#2755532, @Funcrunch wrote:

Thanks for the clarification. Though I like the advantages of a simple filter, a complication I could see is if someone did want to keep their own user page open to anonymous/new user edits. With default semi-protection, they would be able to request that an admin remove this restriction from their own user page. Would they be able to opt their own user page out of this filter?

We could add support for some sort of null template, {{unprotected user page}} for instance, which when present on the page makes it open for editing. That of course would need to be well documented, and I suppose it's a bit hacky, but it'd work. Actual semi-protection is more suitable in terms of performance and the use case you present here, but at the loss of logging and a custom notice. I've no strong feelings on either solution, but I do believe it will take considerable time to get this into MediaWiki core, given both the engineering challenges and lack of consensus.

@MusikAnimal Thanks for your work in writing up the filter and testing it out!

I agree that a filter is a better approach here in terms of implementation; there still appears to be some unknowns in terms of how easy it would be to change the code underlying page protection and otherwise. Using a filter also addresses concerns voiced during the RfC about these changes taking up programmer time that may be needed elsewhere. Logging is also a valuable feature that would allow tracking of the quality of edits being made.

The closing admin has responded here repeatedly regarding questions over consensus. Given their responses and that this discussion closed over a month ago, I'm removing the consensus-needed tag and recommending we move forward using a filter approach.

Not a matter of configuration.