+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@tu-dresden.de> wrote:
On 10.06.2016 12:53, Sandra Fauconnier wrote:

On 10 Jun 2016, at 12:39, Yellowcard <yellowcard@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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata