[OSM-talk] Wikipedia/Wikidata admins cleanup
Chris Hill
osm at raggedred.net
Wed Jan 4 21:33:42 UTC 2017
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 at . 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
> <frederik at remote.org> 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
>
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20170104/e2886637/attachment-0001.html>
More information about the talk
mailing list