Wikidata talk:Requests for comment/semi-protection to prevent vandalism on most used Items

You can left comments on the content or structure of the RfC on this talk page.

Since this ostensibly is for the benefit of other Wikimedia sites that use Wikidata, and affects the ability of their editors to make changes to the WIkidata items they use (they would need to be auto-confirmed on Wikidata before they can change anything, including any sitelink changes as I understand it right now) I think it's important this proposal be communicated to those editors for their input. Is this really something they would find helpful? Are they willing to accept the need to become autoconfirmed on Wikidata to edit frequently used items?

I agree, we should send a massmessage at least to all Wikipedias

Very good questions! My short answer is yes, it's helpful to have as many comments as possible and we'll probably be able to analyze the profiles of the participants once the RfC is closed (i.e., are they Wikipedians, Wikidata editors, both?). Now I'll go with the long answer.

The interests of many Wikipedians are different from those of many Wikidata editors. There are still too many Wikipedians who don't care about Wikidata (and they don't intend to actively edit Wikidata, they just won't use Wikidata while they continue considering it unreliable or an easy target for vandalism) while there are some Wikidata editors who don't care about the purpose or external use of Wikidata (and they don't see the point in measuring Item usage or in preventing some edits instead of reverting them). That's a very negative gap that we should be closing gradually by increasing the percentage of people who know and care about both Wikidata (as a project that provides data to Wikipedia) and Wikipedia (as a project that consumes data from Wikidata). Since this RfC is a meeting point between both sides, I think we should make the most of it and welcome any opinions, regardless of its origin; however, the interests and experience of each participant should be considered ("only cares about Wikipedia" vs. "only cares about Wikidata" vs. "full vision") once the RfC is closed to draw more accurate conclusions about the problem and about this bias in our communities.

Only loosely related to this RfC draft: as statistical overview how we use page protection in Wikidata.

• Since the beginning of Wikidata in October 2012, administrators have used page protection in main namespace (items) for ~5200 times (on average 2.3 times per day)
• However, almost 3000 of these protections have been applied by User:Abián in four batches (plus a couple of individual protections for the same reason) since September 2018. Details: country items on 27 September, some head of states on 31 October, some hundred "high risk items" on 9 January, and most of the rest on 26 January. Without Abián's protections, there would have been ~2200 item protections since Wikidata was set up, which is a little less than one per day on average.
• Without the protections applied by User:Abián recently, we have around 130 items which are indefinitely semi-protected as of now 1. There has been excessive vandalism in (most of) those cases.

I think it would be good also to have some indicative quantification of "Excessive vandalism" (I would add a question in the RfC), and perhaps it would be good to create some automatic connection between this indicative quantification (e.g. a certain number of rollbacks in a certain period of time) and page protection. Example: after the 5th rollback in 2 months, the page is automatically indefinitely protected. @Abián: What do you think?

I disagree on the quantification of "excessive vandalism" (as someone who otherwise likes making things well-defined), because there are qualitative factors to assess when making such page protections. Recently, I made many such protections in the user and user talk spaces because of an LTA adding very gross things; the same amount of benign vandalism would probably not warrant an "excessive vandalism" protection.

The severity of the vandalism is just as important as the amount when deciding to protect.

(Edit conflict) The RfC is just about semi-protecting Items according to their usage, it's important that we don't extend the scope too much so that people don't digress and some clear conclusions can be drawn from the process. Anyway, I'm not very enthusiastic about fully automating administrator decision making but, hey, rather than protecting automatically, I think it would be great if some tool notified us of persistent vandalism or edit wars (for example, by adding requests to the administrators' noticeboard) so that we could act quickly. :D

Certainly my proposal would regard only items, not other namespaces. Automating the process for high number of vandalisms in a short period of time doesn't exclude that administrators can also apply protections in other cases. Anyway, we can also not insert a question about this topic.

More specifically but generally, I do not advocate for protecting pages without a demonstrated need to do so. No nontrivial metric will have no "false positives" without being unduly restrictive (and thus not of much use).

• Make clear that you aim for indefinite semi-protection for items if this RfC is accepted.
• Describe what "semi-protected" exactly means as not every editor might be aware of such terms; also explain how to become "autoconfirmed" (AFAIK: 4 days and 50 edits); optionally: describe how to request the "confirmed" right, and how to request an edit on a protected page using {{Edit request}}.
• Include a hint that any form of accepted protection management would very likely be automated by an admin bot. Which account would be used?
• How often is the protection status re-evaluated (e.g. weekly or monthly)? Is the protection of an item going to be lifted once it falls below accepted thresholds?

Hey, thanks for your suggestions! I think points 1, 3 and 4 are implementation details and they unfortunately depend more on technical limitations than on our will. Talking about indefinite semi-protection might be misleading because each semi-protection should last as long as it exceeds the decided threshold, if any. Maybe it would be good to clarify this, the fact that Items that stop being above the threshold would be unprotected if there are no other reasons to keep them semi-protected?

"indefinite" (without temporal limit) is different from "infinite" (forever). protections always only apply until they either expire (not planned here), or until they are reviewed and lifted for whatever reason.

We could better add your question, "Is the protection of an item going to be lifted once it falls below accepted thresholds?", as a new question of the RfC. What do you think? :-)

I would automatically lift protections of items which fall below the threshold, in some way. Maybe we should wait until it falls by 10% below the threshold, in order to avoid on/off protections for items which linger near the threshold. If 3B or 3C is chosen, this will be somewhat important.

We should also think of the computational overhead of implementing this. This is nearly impossible to maintain in real-time (the metrics take too long to compute). I'm generally not a fan of the overall idea of preemptive protection because the need for protection is not a function of solely page views.

Editors of a language wikipedia may not have made many edits on Wikidata, but may still want to link a page to a Wikidata item, or rename such a page. Does semi-protection prevent this?

Yes it does.

Semi-protected items can be edited by users in the "autoconfirmed users" user group, which requires a four days old account (locally at Wikidata) and 50 edits on that account to be auto-promoted into that group. Newer users and users with less edits would have to ask to become confirmed users at WD:RfP, or alternatively place an {{Edit request}} on the talk page which would add the item talk page to Category:Wikidata protected edit requests.

I would add in the RfC the proposal of (asking a technical intervention on protection mechanism regarding) excluding link-addings and page moves from semi-protections. In this way all users could do these actions also in semi-protected pages.

Very interesting points! We have phab:T143486, which intends to solve the problem with moves and deletions; that's more like a bug and the consensus about fixing it in some way is clear. If we also consider the use case of adding sitelinks, we may be talking about phab:T189412, so we could add a question like "Should these semi-protections exclude changes to sitelinks when this option is available?" with an explanation. What do you think?

I think the option should regard only moves, deletions and addings; regarding changes and removals I'm dubious, sometimes they are vandalisms. However we can add a comprehensive question in the RfC.

I understand your point, but this would lead us to several problems. On the one hand, we should be able to undo our own mistakes, which would mean removing or renaming only the sitelinks we have added before, but this is probably unfeasible. On the other hand, even if we don't allow ourselves to undo our mistakes, the technical complexity necessary to prevent certain actions with the sitelinks while allowing certain others could make us never see this working anyway. Even with the basic option of semi-protecting all or none of the actions with sitelinks, I'm not sure when the development team could address the request, since the Phabricator task about granular protections hasn't made any progress in a year. Regarding the amount of vandalism that sitelinks suffer, ~30% of vandalism by unregistered users focuses on sitelinks according to https://doi.org/10.1145/2766462.2767804, which means that most of the time vandalism doesn't focus on sitelinks but also means that vandalism on sitelinks is significant. Since the possibility of applying granular protections of any kind is probably far from being a reality, I'm thinking now that we could even avoid the question, which maybe doesn't make much sense right now, and talk about this when we have more features available and know better what we'll be able to do.

Would a possible workaround be to grant "autoconfirmed" status on Wikidata to any user that is "autoconfirmed" on a language Wikipedia or other site?

Could be, in my opinion

I think some wikis grant the autoconfirmed status by default (in MediaWiki the default threshold to be autoconfirmed is 0 edits), so almost everyone could become autoconfirmed immediately. That was also the case of Wikidata until 50 edits were required in 2013. Even if that weren't the case, there would still be people creating articles without being autoconfirmed users on Wikipedia who would be unable to add the corresponding sitelinks to Wikidata.

Maybe we could use as criterium "mininum 50 edits in one single Wikimedia project"