Wikidata:Requests for comment/General semi protection for all property pages
An editor has requested the community to provide input on "General semi protection for all property pages" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- 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)[reply]
The grace period proposal has been opposed. Thus, all property pages must be semi-protected.--Ymblanter (talk) 20:51, 2 October 2020 (UTC)[reply]
After a property has been created its property page usually does not need to be edited frequently. If a property has many uses, its labels in particular can be highly visible on item pages, Wikipedia pages and Wikimedia Commons categories that use templates to transclude Wikidata content, as well as on users’ watchlists. Pages using content (usually the labels) from a property page are cached on the servers, and automatically updated after a property page has been changed. For properties with many uses, these changes can take several days to fully propagate.
Property pages can be edited by any user by default, including users without an account (“IPs”) and new user accounts that are not yet autoconfirmed (“newcomers”). This makes them a potential target for vandalism. Most vandalism on property pages comes from anonymous editors, for example see the pre-protection history of properties like country of citizenship (P27) and birth name (P1477). Besides vandalism, we sometimes observe accidental modifications by inexperienced users meant for specific items rather than the property page itself. However, as pages in all other namespaces in Wikidata, property pages can be protected on a case by case basis by administrators to prevent vandalism based on the page protection policy.
As of mid-June 2020, fewer than 50 of more than 7600 property pages (less than 1%) are semi protected, which excludes IPs and newcomers from editing them; most of these protections are indefinite. Around 75% of properties have never been edited by IPs, and another 15% have between one and three edits by IPs. On a typical day in 2020 so far, fewer than 10 edits are made by IPs on all property pages in total.
- Proposal
- In this RfC, it is proposed to apply a general semi protection to all pages in the “Property” namespace (ns=120) by using the $wgNamespaceProtection configuration setting (see discussion in phab:T254280). This means that all property pages are at least semi protected indefinitely, but administrators can still raise the protection level of individual property pages to full protection (only administrators can edit) if necessary. However, the semi protection level cannot be removed by administrators for individual property pages.
This proposal breaches the current protection principles, since most property pages are neither “highly visible” nor have they seen “a pattern of vandalism or spam” which the current page protection policy requires for protection; thus, it can prevent new editors from contributing for instance missing translations on property pages that would not be protected under the current policy.
On the other hand, while vandalism or broken content can persist in caches or is even still unreverted, it can be highly damaging for Wikidata’s reputation, and it can be nearly completely avoided by using general semi protection for all property pages.
This RfC was initiated by Mike Peel and MisterSynergy.
- Support I think this is a sensible proposal. It is a pity that we can't keep everything fully open, but the massive visibility of property labels makes it an unfortunate necessity. It is very easy for someone to deliberately - or, more often, accidentally - change a label on a highly used property, which then appears all across Wikidata, and potentially in infoboxes on other wikis. Because caching can be unpredictable, some of these problem edits can show up to readers for days or weeks afterwards.
- The negative side-effects are relatively low; there are not many edits to property pages which would be caught by this - eg in the last 24 hours there have been about 500 property-space edits, of which only three were by IPs or new users. So I feel on balance this proposal is beneficial. Andrew Gray (talk) 20:25, 15 July 2020 (UTC)[reply]
- Support The only downside I see is we may lose some translation of property labels into some languages. But in general I think the centrality of properties makes this an important step. We already take considerable care in creating properties, as opposed to items which can be created by anybody. ArthurPSmith (talk) 21:09, 15 July 2020 (UTC)[reply]
- I'd like to amend my support vote here, I agree with the comments later on that a waiting period (30 days seems fine; even a year would be ok) would be ok with me, so that newly created properties can be more freely edited than established properties. Or there may be some other sensible criterion than age instead (number of statements using this property, number of languages with labels, ?). Also I have a query - one of the creators of this RFP has voted to oppose it below; does Mike Peel support the proposal as is or in some modified form? ArthurPSmith (talk) 17:33, 24 August 2020 (UTC)[reply]
- @ArthurPSmith: I've added comments below in reply. Thanks. Mike Peel (talk) 17:58, 24 August 2020 (UTC)[reply]
- I'd like to amend my support vote here, I agree with the comments later on that a waiting period (30 days seems fine; even a year would be ok) would be ok with me, so that newly created properties can be more freely edited than established properties. Or there may be some other sensible criterion than age instead (number of statements using this property, number of languages with labels, ?). Also I have a query - one of the creators of this RFP has voted to oppose it below; does Mike Peel support the proposal as is or in some modified form? ArthurPSmith (talk) 17:33, 24 August 2020 (UTC)[reply]
- Oppose the previously applied protection just needs a few tweaks. Some edits by IP are already not possible while still allowing infrequent contributors of Wikidata to add additional translations to these
itemsentities.
It was thought by some staff members that the current protection system is too much resource intensiv in some contexts, but no corresponding data has been provided.
While some may think it's a good idea to protect some or all Wikidata pages, this is contrary to Wikimedia's committment to provide a database that anyone can edit. Unsurprisingly this leads to occasional vandalism or suboptimal edits even by autoconfirmed users. --- Jura 22:45, 15 July 2020 (UTC)[reply]- @Jura1: In your comment you are objecting to the implementation of this on items. The proposal appears to relate to properties only. Can you please confirm if you have typed the wrong word or have misunderstood the proposal? From Hill To Shore (talk) 23:08, 15 July 2020 (UTC)[reply]
- Corrected. I already participated in the earlier discussion. --- Jura 23:10, 15 July 2020 (UTC)[reply]
- @Jura1: In your comment you are objecting to the implementation of this on items. The proposal appears to relate to properties only. Can you please confirm if you have typed the wrong word or have misunderstood the proposal? From Hill To Shore (talk) 23:08, 15 July 2020 (UTC)[reply]
- Support This seems like a sensible approach to protect our most frequently replicated pages. Ill-informed or vandal edits of property pages have much more substantial impacts than similar edits on most item pages. Setting aside the danger of a vandal edit going unnoticed, the effect of replicating the vandal edit and the reversion across potentially tens of thousands of items is an unecessary drain on server resources. From Hill To Shore (talk) 23:08, 15 July 2020 (UTC)[reply]
- I doubt they remain unnoticed. Can you please provide a few samples or confirm that you have misunderstood the proposal? Also, protection isn't meant for most frequently replicated entities. Are properties even replicated? --- Jura 23:25, 15 July 2020 (UTC)[reply]
- Support Property namespace is not a frequent target of vandalisms, but impact of that vandalism can be huge.--Jklamo (talk) 09:37, 16 July 2020 (UTC)[reply]
- Weak support. For often used properties, OK. But Better would be protection only for certain languages - but it is not possible. For new properties i prefer semiprotection after some time, because of translations. JAn Dudík (talk) 09:34, 17 July 2020 (UTC)[reply]
- Comment (not voting yet). It isn't easy to find a useful contribution to properties by an IP or a newcomer. --Matěj Suchánek (talk) 11:12, 17 July 2020 (UTC)[reply]
- Support over the years I looked at IP contributions to the property namespace several times. The number of edits is extremely limited (usually less than 10 a day) and the majority gets reverted. The impact of vandalism is high so this seems like a good step to me. Multichill (talk) 16:40, 19 July 2020 (UTC)[reply]
- Support Like the others, but only if there will be no "only admins" protection. -Killarnee (C•T•U) 15:31, 20 July 2020 (UTC)[reply]
- Comment I don't oppose semi-protection, but some of these concerns could be addressed by expanding Special:AbuseFilter/101, which currently prevents IPs from editing English labels, to cover other widely-used and mostly-complete languages (Dutch, Arabic, Catalan, French) and to require autoconfirmed status. I think this is what Jura is referring to, and this is more or less the "protection only for certain languages" that JAn Dudík wanted. Vahurzpu (talk) 16:37, 20 July 2020 (UTC)[reply]
- Comment I support the semi-protection, only for "Mature Properties". Some properties still do not have property examples, descriptions to disambiguate from similar properties, and have property constraints that are too rigid/open to be useful. There is also a lag/delay in property discussions, where a simple edit can be more effective or other eyes on the property can help form it better. As such, properties that include the above criteria, have descriptions in atleast a few different language families, and are used in atleast a few items (>~100) or are of a certain category of properties like (biographical,scientific identifiers), should be considered "Mature Properties", and they should be semi-protected. Additionally, this can incentivize people to build the property pages better. Wallacegromit1 (talk) 02:29, 21 July 2020 (UTC)[reply]
- Support The founding principles speak about anyone to edit (most) articles without registration. Properties aren't articles. On important difference is that properties get reused fairly wide and thus the damage you can cause via vandalism is higher then vandalism at an article that just applies to that article. Even if the standard would be most pages, protecting a few thousand pages doesn't change the fact that most pages on Wikidata remain unprotected. The quality of the defacto changes matters a lot and as Matěj Suchánek points out, that quality isn't high. The biggest complained from outside parties is that there's too much vandalism in Wikidata and not that it's too hard to contribute to Wikidata. When it comes to property labels in lesser used languages I would prefer if those would be set by people who have a good understanding of how Wikidata works. Requiring 50 edits is a very low bar and I think resonable for demonstrating some minimum of understanding of Wikidata. ChristianKl ❪✉❫ 10:04, 21 July 2020 (UTC)[reply]
- So you are saying "founding principles" don't apply to Wikidata as Wikidata doesn't have any "articles" ;) --- Jura 10:21, 21 July 2020 (UTC)[reply]
- Well said, man. Prahlad (tell me all about it / private venue) (Please
{{ping}}
me) 17:47, 25 August 2020 (UTC)[reply]
- Well said, man. Prahlad (tell me all about it / private venue) (Please
- Comment Wikibase developers are currently working on a feature which allows site administrators outside Wikidata to use Wikidata properties for storing their own data (pinging Addshore or anybody else from the devs). In fact, Commons already uses our properties (but also items). In other words, vandalism of certain parts of our properties may impact more than just Wikidata and the sister projects. --Matěj Suchánek (talk) 15:09, 21 July 2020 (UTC)[reply]
- Support it seems that IPs rarely edit properties with either good or bad result; however, the reuse of properties is wide, so having properties protected is a good way to prevent most vandalisms on them, which would reflect in many places. Maybe, if technically possible, a good solution would be to protect all part of the properties except the label-description-aliases in languages still having them blank, so that IPs can insert translations (good, hopefully). In any case, in the current situation semiprotection is probably the best choice. --Epìdosis 17:21, 21 July 2020 (UTC)[reply]
- Support Makes sense to me, good for preventing damage to the database. - Nicereddy (talk) 02:47, 22 July 2020 (UTC)[reply]
- Oppose per numbers given in the proposal. IP/newcomer edits on properties are a tiny problem, but this is a major shift towards a closed project and community. We should continue with the status quo (use individual property page protections, maybe add some more where necessary), and keep the vast majority of property pages open as a teaser for potential new editors. —MisterSynergy (talk) 05:58, 22 July 2020 (UTC)[reply]
- Abstain,, but if implemented, this should not apply to new (i.e. a under a week or so old) properties, where there is typically a need to add lots of new labels and descriptions in multiple languages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:07, 15 August 2020 (UTC)[reply]
- Weak oppose 10 may look like a small number, but over two years this scale to ~1 edit/property, which is considerable. I believe that semi-protecting all property pages is also damaging to Wikidata's reputation of openness. This would block a new user on a edit-a-thon, for example, to contribute to any property, even for adding a label on their language. I see there are trade-offs, but IMHO, openness speaks louder. TiagoLubiana (talk) 18:51, 15 August 2020 (UTC)[reply]
- Support per above. Wikidata properties could/should be considered back-end infrastructure, similar to MediaWiki pages for example. I'd also like to add on to Andy's comment; perhaps new-property protections could be enabled after a standard period of being open (i.e. 30 days)? Rehman 05:28, 16 August 2020 (UTC)[reply]
- @Rehman, ElliotPadfield, Pigsonthewing, ArthurPSmith: You might want to check on the phabricator ticket (phab:T254280), but I don't think a waiting time is possible with the proposed technical setup - it's either semi-protect all efficiently, or semi-protect some of them inefficiently. Thanks. Mike Peel (talk) 17:58, 24 August 2020 (UTC)[reply]
- Thanks Mike. As an alternative semi-automatic approach, a bot could probably list the properties that need to be protected (i.e. after 30 days) on a given page (for admin action). Or, if technically possible, the property namespace could be protected by default, and the new property creation process could include a step to turn-off protection for 30 days. Rehman 02:22, 25 August 2020 (UTC)[reply]
- @Rehman: Please see phab:T254280 - bot protection was considered but isn't as efficient. Using $wgNamespaceProtection wouldn't allow removing the semi-protection for individual properties. There are existing alternatives here if an unconfirmed user does want to edit a new property - they can meet the autoconfirmed requirements (which aren't that high); they can be manually confirmed (e.g., if they are at an editathon), or they can use
{{Editprotected}}
. Thanks. Mike Peel (talk) 12:41, 25 August 2020 (UTC)[reply]
- @Rehman: Please see phab:T254280 - bot protection was considered but isn't as efficient. Using $wgNamespaceProtection wouldn't allow removing the semi-protection for individual properties. There are existing alternatives here if an unconfirmed user does want to edit a new property - they can meet the autoconfirmed requirements (which aren't that high); they can be manually confirmed (e.g., if they are at an editathon), or they can use
- Thanks Mike. As an alternative semi-automatic approach, a bot could probably list the properties that need to be protected (i.e. after 30 days) on a given page (for admin action). Or, if technically possible, the property namespace could be protected by default, and the new property creation process could include a step to turn-off protection for 30 days. Rehman 02:22, 25 August 2020 (UTC)[reply]
- @Rehman, ElliotPadfield, Pigsonthewing, ArthurPSmith: You might want to check on the phabricator ticket (phab:T254280), but I don't think a waiting time is possible with the proposed technical setup - it's either semi-protect all efficiently, or semi-protect some of them inefficiently. Thanks. Mike Peel (talk) 17:58, 24 August 2020 (UTC)[reply]
- Support per above. Like Rehmans proposal with 30 days open after creation.--So9q (talk) 07:39, 18 August 2020 (UTC)[reply]
- Support Vandalism of properties has the potential to largely impact data both on and off-project. There is little need for non-auto-confirmed users to edit properties. ElliotPadfield (talk) 10:04, 21 August 2020 (UTC)[reply]
- Oppose per MisterSynergy. - Premeditated (talk) 12:46, 23 August 2020 (UTC)[reply]
- Oppose I think this isn't necessary. I know many experienced editors who choose to stay anonymous, and strongly agree with MisterSynergy's reasoning. I, however, support the semi-protection of highly visible properties (instance of (P31) for example). --Prahlad (tell me all about it / private venue) (Please
{{ping}}
me) 22:22, 23 August 2020 (UTC)[reply] - Support as proposed, I think this is important to improve Wikidata's reputation with regards vandalism and its impacts on projects that use the data here. Thanks. Mike Peel (talk) 17:58, 24 August 2020 (UTC)[reply]
- Support. This proposal prevents cross-wiki vandalism in large scale and, per Mike Peel, would increase Wikidata reputation in other Wikimedia projects. --Joalpe (talk) 12:26, 26 August 2020 (UTC)[reply]
- Weak oppose. From what I have perceived so far while combating vandalism, most vandalism happens in main namespace and just a tiny percentage in property namespace. While I see that properties need special protection against vandalism, I'd disagree that semi-protection is necesarry for all properties. Extending existing Abuse-filters might just as well do the trick, while preserving the general opennes of our project. -- Dr.üsenfieber (talk) 02:28, 31 August 2020 (UTC)[reply]
- Quite neutral for now on the overall proposal, but this make me think that vandalism should maybe be fighted in another way in Wikimedia projects. Unauthorized edits on semiprotected or on protected entities (here and in other Wikimedia projects) should maybe be recorded (visible on the page revision) and put on hold for potential validation from an authorized user. This will avoid the vandalism and will avoid to lose a potential good contribution at the same time. Sorry to have deviated from the subject a little. Regards, Christian Ferrer (talk) 20:29, 5 September 2020 (UTC)[reply]
- Weak support but I would prefer pending changes like dewiki uses them. --Rschen7754 23:33, 19 September 2020 (UTC)[reply]
- And as a side note, we already do limit property creations. --Rschen7754 23:35, 19 September 2020 (UTC)[reply]
- Support Useful against incompetence and vandalism. Akela (talk) 11:51, 25 September 2020 (UTC)[reply]
- Support --Trade (talk) 16:02, 25 September 2020 (UTC)[reply]
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- As there was no activity for more than two days, and the consensus below is for the absence of a grace period, we are back to the original proposal--Ymblanter (talk) 20:50, 2 October 2020 (UTC)[reply]
I start this discussion to make the above conclusions more precise. It has been proposed above that properties only get semi-protected after a certain period of time since their creation. This grace period will give a chance to users who are active in the projects but who are not autoconfirmed on Wikidata to add descriptions in their language. This discussion is to determine the duration of this grace period. Currently the period of 30 days has been proposed; I concluded that it is unlikely that this period is going to be longer than a year, and the default value i currently a year. Please add your opinions below what this period should be. Put 0 days if you think it is not needed. Please do not put unreasonable grace periods like 500 years, this would contradict to the consensus found above, and we are not going to have the same discussion again. You may motivate your choice, but unmotivated votes from users in good standing will be taken into account as well.--Ymblanter (talk) 19:54, 25 September 2020 (UTC)[reply]
- Comment: manual protection management was intentionally not offered in this RfC in order to make this process—in case it passes here—less error-prone and to save administrative resources that are very limited anyways. It is frustrating to see that there is now this outcome that was not really up for discussion at all. —MisterSynergy (talk) 20:17, 25 September 2020 (UTC)[reply]
- It is still a possible outcome of this discussion, just vote 0 days.--Ymblanter (talk) 20:21, 25 September 2020 (UTC)[reply]
- While I appreciate you closing this, @Ymblanter:, I think you've done so in a way that answers 'Are apples good?' with 'bananas are tasty'. I've posted an updated to phab:T254280. Maybe the developers can figure out a way to implement this, but I personally can't see how this solution (which was NOT what was proposed) would be at all feasible. Mike Peel (talk) 22:13, 25 September 2020 (UTC)[reply]
- Again, if this part converges to no grace period, then we are back exactly at the original proposal.--Ymblanter (talk) 05:56, 26 September 2020 (UTC)[reply]
- @Ymblanter: A dev has commented at phab:T254280 that this isn't possible with the proposed system. Given that most people below are !voting 0 days, can we close this and get on with implementing the originally proposed solution, please? Thanks. Mike Peel (talk) 20:21, 28 September 2020 (UTC)[reply]
- Again, if this part converges to no grace period, then we are back exactly at the original proposal.--Ymblanter (talk) 05:56, 26 September 2020 (UTC)[reply]
- 0 days I don't think a significant number of users who are not yet autoconfirmed will add labels and descriptions to properties shortly after creation. Therefore I don't think it is worth the additional adminstration resources. --Pyfisch (talk) 10:10, 26 September 2020 (UTC)[reply]
- 0 days As Pyfisch above + users that are not autoconfirmed can ask for necessary changes on the discussion page. Wostr (talk) 13:52, 26 September 2020 (UTC)[reply]
- I Support 0 days. ChristianKl ❪✉❫ 19:26, 26 September 2020 (UTC)[reply]
- 0 days per above. --Rschen7754 20:13, 26 September 2020 (UTC)[reply]
- Weak support 2 weeks, as some labels and descriptions may be usefully translated; anyway, 0 days is not so bad. --Epìdosis 21:11, 26 September 2020 (UTC)[reply]
- 0 days per Pyfisch. Any user of any level may translate labels and descriptions. ミラP 02:18, 27 September 2020 (UTC)[reply]
- I would give my weak support to the 2 weeks as Epìdosis says; however, as long as we don't implement an open source bot that runs on the Toolforge and ensures that grace periods longer than 0 days are respected and then protects the Properties automatically, the most reasonable solution is to opt for $wgNamespaceProtection ( 0 days), which is also the simplest one, it doesn't generate editing noise, and its functioning is secure, transparent, efficient and well tested. --abián 10:00, 28 September 2020 (UTC)[reply]
- Didn't we have another RFC a while ago on semi-protecting frequently used items? I assume that also has an administrative burden, unless managed by a bot (which I would guess this could be also?) Anyway, I am in favor of at least 30 days, and up to a year grace period, but if the consensus is no grace period, that's fine too. ArthurPSmith (talk) 13:29, 28 September 2020 (UTC)[reply]
- There is neither a bot, nor does it have an administrative burden. Wikidata:Requests for comment/semi-protection to prevent vandalism on most used Items is simply being ignored because we as the community do not have the tools and insight to evaluate the numbers that are required to implement it. The status still is that the indefinite item protections (some thousands) that User:Abián had installed *before* that RfC had been started are still in place, have never been reviewed, and there have never been serious efforts to look for new items which need protection based on that RfC. It was clearly a non-starter. —MisterSynergy (talk) 14:53, 28 September 2020 (UTC)[reply]
- I admit that I thought this topic was over and I know that this page isn't the place to talk about it. However, as I commented on other occasions, and for the record, it's not true that "the community do not have the tools and insight to evaluate the numbers that are required to implement it". We do have access to the numbers (see [1] and [2]) to apply that consensus, and of course everyone is free to review my semi-protections, which didn't violate any policy and were only a subset of those approved by the community in the vote. --abián 15:18, 28 September 2020 (UTC)[reply]
- There is neither a bot, nor does it have an administrative burden. Wikidata:Requests for comment/semi-protection to prevent vandalism on most used Items is simply being ignored because we as the community do not have the tools and insight to evaluate the numbers that are required to implement it. The status still is that the indefinite item protections (some thousands) that User:Abián had installed *before* that RfC had been started are still in place, have never been reviewed, and there have never been serious efforts to look for new items which need protection based on that RfC. It was clearly a non-starter. —MisterSynergy (talk) 14:53, 28 September 2020 (UTC)[reply]
- Weak support for 2 weeks, 0 days are acceptable as well. --Jklamo (talk) 14:42, 28 September 2020 (UTC)[reply]
- 0 days, as the simplest option. Andrew Gray (talk) 18:28, 28 September 2020 (UTC)[reply]
- 0 days, or 2 weeks, either works for me. Anything longer than a month seems quite excessive. Nicereddy (talk) 04:21, 29 September 2020 (UTC)[reply]
- 0 days --Alaa :)..! 13:48, 30 September 2020 (UTC)[reply]