$wgNamespaceProtection could be a good option
AbuseFilter and bot protection should probably not be used if the idea is to protect all properties.

We also currently have a user right for altering property terms which could be useful?

Change Property terms (labels, descriptions, aliases) (property-term)

This wouldn't cover changes to statements (but adding that user right could also be an option?

I agree with Addshore: the abuse filter's performance should not be hindered by this kind of "namespace" protection. $wgNamespaceProtection is what's needed here.

In my opinion, if you have no business altering property terms, you have no business editing that property at all. But that should be made the subject of an additional discussion, and thus isn't quite in scope of this request.

@Addshore The property-term user right is something that would have to be granted so that people could edit property labels, right? I think that's going too far for now as it would have to be given to quite a few editors. $wgNamespaceProtection sounds good.

Agreed. Let's go with $wgNamespaceProtection. So I take it you'd like us to set this to allow the Property namespace to be only editable by autoconfirmed users, correct?

@Lydia_Pintscher Yes, editable by autoconfirmed users. The discussion is still ongoing, and I'm not quite sure how to close it, see https://www.wikidata.org/wiki/Wikidata:Project_chat#When/how_to_close_this?

There is now an RfC at https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/General_semi_protection_for_all_property_pages - once that has finished and been closed I'll update this ticket accordingly.

The RfC was closed with " In this discussion, I see rough consensus to generally semi-protect all property pages. The arguments for protection are that properties are highly visible; they are rarely edited by IPs and new users, and most of these edits get reverted, so that there is no obvious benefit. The main oppose argument is that many editors in the projects, who are not autoconfirmed on Wikidata, will not be able to edit properties, and this may affect descriptions on the less common languages. These arguments are valid and clear, they have been discussed for a sufficient period of time, and the opposers are clearly in minority.

An important argument has been brought forward but not sufficiently discussed, that if properties get protected not immediately after creation, but after some period (the proposal was 30 days, one user said they6 would not object against a year), it would significantly mitigate the negatives of the semi-protection, since interested parties can add the descriptions before the protection. This has not been sufficiently discussed, and I add a specific discussion of this topic below. Before this second discussion has been summarized, we should not be protecting properties right after creation. However, I read the current discussion as that in any case, all properties older than a year can be semi-protected.--Ymblanter (talk) 19:48, 25 September 2020 (UTC) "

I don't know how to move this forward now, I can't see how this close is compatible with $wgNamespaceProtection. Any thoughts?

In T254280#6495487, @Mike_Peel wrote:

I don't know how to move this forward now, I can't see how this close is compatible with $wgNamespaceProtection. Any thoughts?

So this close is not very compatible with $wgNamespaceProtection so it looks like we won't be able to use it.
Probably the easiest way to currently get this process implemented would be with an admin bot.

It might be nice to explore the idea of some sort of globally available confirmed / autoconfirmed group that would appear if a user is confirmed on any WMF site.
But we don't have that now / maybe that is a bad idea, but I would continue to see this being a potentially useful thing in the future.
I'll reach out to the core platform team and see what they think

According to the resolution of Wikidata:Requests for comment/General semi protection for all property pages today:

The grace period proposal has been opposed. Thus, all property pages must be semi-protected.--[[User:Ymblanter|Ymblanter]] ([[User talk:Ymblanter|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 20:51, 2 October 2020 (UTC)

So the solution is $wgNamespaceProtection.

Change 631809 had a related patch set uploaded (by Abián; owner: Abián):
[operations/mediawiki-config@master] Require autoconfirmed status to edit Wikidata Properties

https://gerrit.wikimedia.org/r/631809

@WMDE-leszek should this really be applied to Test Wikidata as well? That wiki doesn’t have the same restrictions as Wikidata in general – for instance, anyone (even anonymous users) is allowed to create a property there. I think limiting property editing to autocreated users would be too disruptive, since the typical Test Wikidata user may be autoconfirmed on Wikidata, but not yet on Test Wikidata, and it doesn’t make much sense to require some constructive / good-faith edits on a test wiki IMHO.

If it's about testing what it's like to have the Property namespace with the permission settings of the actual Wikidata, we could also set the autoconfirmed status on Test Wikidata to, for example, zero days and one edit, or zero edits.

@Lucas_Werkmeister_WMDE: the reasoning behind applying the same change to test wikidata was to ensure the same configuration that the production site has, to have at least one stage were possible issues could be recognized and/or reproduce, and not just to learn about problems when they hit production.
This seems like a very strong argument to me. I don't think I know enough about the specifics of edits on Test Wikidata to be able to say how the point you made weights against the argument we discussed.

Well, my point is that Test Wikidata already doesn’t have the same configuration as production Wikidata, and (in order to be useful as a test environment) it shouldn’t have the same configuraion, either, at least not in this specific aspect (property rights).

@Lydia_Pintscher any thoughts on this?

Yeah if we're already that far diverged then let's not do it and instead separately think about the pros and cons of aligning them completely.

Alright, thanks! I left Beta in the AC because that’ll be the default behavior, and Beta already seems to be closer to Wikidata in terms of permissions than Test Wikidata is.

In Test Wikidata everyone including IPs can create new properties, and this is intentional (and required by unit tests).

Beta already seems to be closer to Wikidata in terms of permissions than Test Wikidata is.

This seems to be logically completely the wrong way round, if you ask me, to have Test and Production wikidatas so different. But if it is the status quo, I believe trying to make things right with regard to this task might be not efficient.

In T254280#6526551, @Bugreporter wrote:

In Test Wikidata everyone including IPs can create new properties, and this is intentional (and required by unit tests).

I clearly didn't know it, thanks. Mind pointing me to those tests? I am trying to create a clear picture of the purpose/use of those wikis.

In my case, do I have to do anything with the patch? I always add reviewers arbitrarily, more or less according to the suggestions of the interface; should I add more/other reviewers, or change anything else?

No. All good. Thanks for providing the patch :)

Moving to peer review since @abian provided a patch.

Change 631809 merged by jenkins-bot:
[operations/mediawiki-config@master] Require autoconfirmed status to edit Wikidata Properties

https://gerrit.wikimedia.org/r/631809

Mentioned in SAL (#wikimedia-operations) [2020-10-12T11:18:26Z] <lucaswerkmeister-wmde@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Config: [[gerrit:631809|Require autoconfirmed status to edit Wikidata Properties (T254280)]] (duration: 01m 00s)

I looked at the last created Property just now and looking at the page information it still shows me everyone is allowed to edit:

When not logged in the same Property does indeed not let me edit it as intended in this ticket.

Is the page info just out of date? Does it get overwritten by namespace-wide protection and just doesn't reflect that?

Possibly related, if you try to protect a property (e.g., https://www.wikidata.org/wiki/Property:P7006 ) now you see this:

In T254280#6545624, @Lydia_Pintscher wrote:

Is the page info just out of date? Does it get overwritten by namespace-wide protection and just doesn't reflect that?

Luckily or unfortunately this happens on all wikis (also Wikipedia) and all protected/semi-protected namespaces (also the MediaWiki namespace). The (dis?)information page only seems to take into account the individual protection status of the page.

In T254280#6545675, @Mike_Peel wrote:

Possibly related, if you try to protect a property (e.g., https://www.wikidata.org/wiki/Property:P7006 ) now you see this:

There's no longer an option to semi-protect, but 'allow all users' seems to be possible?

I've split this off into T266394, if it is a general issue.

In T254280#6546354, @abian wrote:

In T254280#6545624, @Lydia_Pintscher wrote:

Is the page info just out of date? Does it get overwritten by namespace-wide protection and just doesn't reflect that?

Luckily or unfortunately this happens on all wikis (also Wikipedia) and all protected/semi-protected namespaces (also the MediaWiki namespace). The (dis?)information page only seems to take into account the individual protection status of the page.

This isn't good, I've filed this as T266395