I disagree with this. A revert is putting right the wrong of an
undiscussed mechanical edit or automated import. *All* undiscussed
imports should be reverted. That will be part of the enforcement of the
mechanical edit guidelines.
If we want high quality data (and I certainly do) we must enforce the
widely discussed and accepted mechanical edit guidelines and when
someone has flouted those guidelines a revert is to be expected, and as
quickly as possible.
The idea that a bad quality data should be cleaned up so the revert is
not needed is opening the door to yet more poor quality data imports,
some of which inevitably doesn't get cleaned up. Clean it up *before* it
is imported.
OSM is not a database to dump any old data into in the hope that some
kind soul will tidy up later.
Bad feeling comes from leaving too long before a revert is made. If the
revert is made quickly then the importer will realise they have to sort
the data out before it is imported.
I fully support Frederik in his continued efforts to keep the quality of
data in OSM as high as possible.
--
Chris Hill (chillly)
On 04/01/2017 21:18, Mikel Maron wrote:
Reverts should be held to the same standard as imports (outside of
obviously urgent problems). That means a well documented and visible
plan, community discussion. Rob's comment shows that it is not
possible for someone eyeing a revert to judge this from a quick look
at the data or discussion on talk@. Right or wrong, the communication
I've seen from community members making reverts has left a lot of
rough feelings. I don't believe that this thread meets a community
friendly threshold for reverts.
Can we hold off on the current revert regime across the board until we
have as good guidance and practice in place as we have for Imports?
* Mikel Maron * +14152835207 @mikel s:mikelmaron
On Wednesday, January 4, 2017 2:50 PM, Frederik Ramm
<[email protected]> wrote:
Hi,
On 01/04/2017 07:25 PM, nebulon42 wrote:
> I would revert it then.
> Violations of the automated edits policy should not be tolerated.
Some automated Wikidata additions have been reverted by me in the
past,
mainly where they came from an algorithm that used proximity (and not
existing wikipedia tags) to match OSM to Wikipedia.
As for Yuri's edits which are based on matching Wikipedia tags, I
asked
him on 18 November to stop making un-discussed automated edits:
http://www.openstreetmap.org/changeset/43775555#map=6/54.750/35.752
to which Yuri replied (last comment in the list)
"Woodpeck, I have already stopped changing any objects except the
admin
levels regions 1-6, and even those I have greatly slowed down, and
began
reviewing most of the auto-resolved wikidata IDs. I will cease further
automodifications, and instead concentrate on getting wikidata tags
quality review for the admin levels."
Contrary to what he wrote there, he's modified more than one hundred
thousand objects *after* that exchange - newly adding, instead of just
quality reviewing, Wikidata tags.
I think that at in a first step, those wikidata tags added by Yuri
after
18 November need to be removed. It is rather brazen to ignore our
existing rules outright, especially after I had made it very clear to
Yuri that his edits *are* automated edits according to our rules.
I was
a bit hesitant because there's quite a few people in OSM who think
that
low-quality Wikidata tags are better than no Wikidata tags at all, but
hearing here that the express desire of other community members
has been
blatantly ignored just like our automated edit rules have, I'm leaning
towards reverting the lot and making a clean new start.
We're not in a rush here - we can afford to wait until someone who
actually knows the area they are working in has the time to add
Wikidata
tags. That will yield much higher quality data than some automated
matching.
Bye
Frederik
--
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
