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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
--
Markus Kroetzsch
Faculty of Computer Science
Technische Universität Dresden
+49 351 463 38486
http://korrekt.org/