+1000 to Markus K's main arguments above. Yes noise will be introduced as
different people come in to make edits. Administrators locking them out
isn't the best way to solve that problem in an open system. There are
other options, as he raised - both technical and social.
Our group maintains hundreds of thousands of items on Wikidata with bots
that import data about genes, drugs, and diseases from a large variety of
'trusted authorities'. We have also experienced some frustrations when
users make changes that don't fit our views (e.g. there was a thread here
about people merging gene and protein items that caused some major
headaches for us). But, we resolved it by engaging with the people doing
the problematic edits via the talk pages and by adapting our bot code in
various ways - both by automatically fixing things that we judged to be
clearly broken (producing edits that could be tracked and argued with), by
educating community members about why things were modeled the way they
were, and by fixing processes that led to the confusion. We could have
argued that because of our PhDs or whatever, we should 'own' these claims
that are "clearly facts...", but that would have been a huge mistake.
Looking ahead, we see that there will be an increasing challenge to keep
things in order as more and more people get involved. Figuring out this
process will entail a lot of work for us - much more than if the 3 _total_
people that are writing the gene, disease, drug bots currently were left to
their own devices to create our own little data warehouse. We are here
because we want to be a small part of something much more profound than
that - that will take not 3 people in a closed room, but 30,000 people
collaborating and fighting it out together. We are a long way from 30,000
here (at least in our part of this). Lets keep the gates as open as
possible.
-Ben
p.s. In terms of 'making our data more reliable for re-use'. The formula
for me here is (1) get references on statements (2) develop code that
automates the processes of checking them, (3) provide the re-user with
straightforward ways to filter the data based on the combination of 1 and
2. This can even be accomplished directly inside of Lua code that builds
Wikipedia templates from Wikidata - we have already started prototyping
that.
On Fri, Jun 10, 2016 at 4:26 AM, Markus Kroetzsch <
markus.kroetzsch(a)tu-dresden.de> wrote:
On 10.06.2016 12:53, Sandra Fauconnier wrote:
On 10 Jun 2016, at 12:39, Yellowcard <yellowcard(a)wikipedia.de> wrote:
However, there are single statements (!) that
> are proven to be correct (possibly in connection with qualifiers) and
> are no subject to being changed in future. Locking these statements
> would make them much less risky to obtain them and use them directly in
> Wikipedia. What would be the disadvantage of this, given that slightly
> experienced users can still edit them and the lock is only a protection
> against anonymous vandalism?
I agree 100%, and would like to add (again) that this would also make our
data more reliable for re-use outside Wikimedia projects.
There’s a huge scala of possibilities between locking harshly (no-one can
edit it anymore) and leaving stuff entirely open. I disagree that just one
tiny step away from ‘entirely open’ betrays the wiki principle.
I don't want to argue about principles :-). What matters is just how users
perceive things. If they come to the site and want to make a change, and
they cannot, you have to make sure that they understand why and what to do
to fix it. The more you require them to learn and do before they are
allowed to contribute, the more of them you will lose along the way. If a
statement is not editable, then the (new or old) user has to:
(1) be told why this is the case
(2) be told what to do to change it anyway or at least to tell somebody to
have a look at it (because there will always be errors, even in the "fixed"
statements)
These things are difficult to get right.
There is a lot of discussion in recent years as to why new editors turn
their back on Wikipedia after a short time, and one major cause is that
many of their first edits get reverted very quickly, often by automated
tools. I think the reasons for the reverting are often valid, so it is a
short-term improvement to the content, yet it severely hurts the community.
Therefore, whenever one discusses new measure to stop or undo edits, one
should also discuss how to avoid this negative effect.
I completely agree that there is a lot of middle ground to consider,
without having to go to an extreme lock-down. However, things tend to
develop over time, and I think it is fair to say that many Wikipedias have
become more closed as they evolved. I am not eager to speed up this
(natural, unavoidable?) process for Wikidata too much.
The pros and cons of flagged revisions have been discussed in breadth on
several Wikipedias, with diverse outcomes, so it is probably a tricky thing
to settle on a conclusion here.
Best regards,
Markus
--
Markus Kroetzsch
Faculty of Computer Science
Technische Universität Dresden
+49 351 463 38486
http://korrekt.org/
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata