Dear all,
Many interesting views were expressed here. I agree that it would be great if we could technically limit protection to certain statements or properties. However, let us be careful not to overuse this. I have read several people expressing that "only trustworthy" or "experienced" editors should be allowed to edit certain things. In my view, this is fundamentally against the way in which Wikipedia is working. Protections in Wikipedia are used in extreme cases (unresolvable disputes, repeated vandalism, etc.) -- never as a precaution to keep out "untrusted" editors from a large number of pages. This would send a completely wrong signal.
The power to edit is the foundation of all Wikimedia projects. It confers to every literate person the capacity to participate actively. Any attempt to shut out some "undesired" users will also reduce the inflow of competent, well-meaning users. It will make our life easier for a while, but it will deeply hurt our progress in the mid and long term. Wikipedia and Wikidata alike are built upon the bet that there are more things to be gained than to be lost by being open. Are we going to win this bet? -- I don't know. But it is our very business model and the thing we are good at. Closing off editing in large scales, even in part (e.g., on all ethnicity codes in Indonesia), would make us gradually change our model to that of a curated database with strong editorial control. There are such databases, and they are doing a good job, but is it not our strength to try to be like them.
Large-scale protection would also create new positions of power and require more governance. Gatekeepers and policies would be needed to ensure that these rights are used "correctly". The control will not be with the people who are asking for protection now (if you are the main editor, you should not also have the power to shut down editing for others). So who knows who will be allowed to edit in the end? Once you have introduced domain-wide statement protection as a valid means to prevent accidental modification by people who are not in a white-list, you can use this instrument for basically everything. They won't need much of a reason to shut you out, since this is the default (everybody but a few experts are blocked) and since a wikisystem always experiences some noise from unwanted edits (so there is always a reason). Such a system would not be a wiki any more.
Similarly, a system where multiple approvals are needed to make a change in a statement would only work if such approvals happen very quickly and reliably. If we can solve this, we can probably solve the vandalism problem too (the thread started with a case of vandalism not noticed since 2014 -- a legit edit that remains unapproved for such a long time would be just as bad). Without speedy approval, editors would again be repelled and our community would suffer.
So with all these issues surrounding protection, how can we still guard our system against random noise and support our expert users in focussing on the content (rather than on keeping off misguided users and vandals)? Here are some ideas of things that could be realised in software:
(1) Statement- and property-level watching for changes (seeing problematic changes should come before disallowing them) (2) Statement- and property-level history (it's currently really hard to find out who last changed a property, e.g., to contact the person or to look at their other edits) (3) Statement- and property-level protection (for the hard cases, mostly temporarily, same policies as for page-level protection) (4) Statement-level patrolling (can I approve a more recent change to P31 without approving an older change to P580?) (5) Query-based watching: if you want to watch all property changes for a large set of articles, you need better tools (6) More work on edit filters (preventing some edits based on content, e.g., the use of shortened URLs as a homepage) (7) Better UIs to prevent accidental edits (e.g., I can see a lot of cases where people have entered qualifier information as new statement values) (8) Further work on easy-to-customise quality analysis and display of related results (the constraint service is great, but hard to use in a targeted way to find errors in a specific area). While data-vandalism can have far-reaching consequences, it also is much harder to hide if the community has the right tools at hand. (9) Better data importing infrastructures (some problems mentioned in this thread seem to be caused by a multi-stage data import approach that only works if nothing changes in the meantime; I am sure one could get this fixed without relying on user-editable data).
Many of these could also be built in external apps. Some of these might give us inspiration for what to do in SQID, for example. Others are quite challenging and may not be so easy to do for technical reasons.
Best regards,
Markus
On 09.06.2016 06:42, Biyanto Rebin wrote:
Hello,
Wikidata is a great collaboration of database, I love it, but sometimes when I encounter some vandalism, it makes me so angry. Just like today, I've found Q879704 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else andit was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
Now, I'm just curious, will everyone agree if (maybe) in the future Wikidata team can lock some cell that already fix? For example Javanese (Q33549) = P31: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (/Chair/) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id mailto:biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata