<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/07/2016 17:29, Éric Gillet wrote:<br>
</div>
<blockquote
cite="mid:CAPr1vj_OTny-MQFAEWZ4y_Tjbqry3qNhcYEjaMXKKAGaYJ166w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div>So at least one user should reach out to the
contributor before involving the DWG ? That would be great
but that's not currently the case in my experience.</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
The vast majority of my DWG interactions with other OSM users are
"if you see something amiss, please comment on the changeset
discussion so that the person making a mistake knows there's a
problem". It's actually rare for DWG members to see something and
act immediately; most are reported to us directly, often by multiple
users.<br>
<br>
What might happen is that we jump fairly quickly on obvious
sock-puppets (see for example the ones at the top of the
<a class="moz-txt-link-freetext" href="http://www.openstreetmap.org/user/SomeoneElse/blocks_by">http://www.openstreetmap.org/user/SomeoneElse/blocks_by</a> list - but
even in that case the recipient has a clear route to engage with the
DWG to say "you made a mistake").<br>
<br>
To my mind, the biggest and most important requirement in
<a class="moz-txt-link-freetext" href="http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct">http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct</a>
is "document and discuss". It's important that large-scale edits
(especially worldwide ones) catch the ear of those mappers and data
consumers that they're going to affect. Also, sometimes
well-meaning tag-changers sometimes don't have as much domain
knowledge as others about the things that they're proposing to
change (the "trees" change mentioned upthread was a good example of
this - most needleleaved (coniferous) trees are evergreen, but not
all, and the person making the (undiscussed) change didn't know
that). Discussing proposed changes in the open means that everyone
can benefit from that wider knowledge. <br>
<br>
It's also important to remember that OSM is supposed to be something
representing the real world, not a bunch of data that is
semantically described by the wiki. Essentially, it's a geography
project, not a computer science one*. There will be cases where the
data that's in OSM is "a bit woolly", and doesn't quite get the
sense of a real-world entity across (but without an on-the-ground
survey it's difficult to say what the problem is). Sometimes the
fact that OSM mappers have captured something that "doesn't quite
fit" OSM's frequently used categories is really useful, because it
identifies something that we should categorise better - so it's
important that the _sense_ of what the original mapper reported is
kept, rather than their square peg being hammered down into a round
hole**.<br>
<br>
I've read through your posts in this thread, and while it's clear
that you have an issue with the way that things work now, I can't
see what that problem actually is. Can you provide some specific
examples of DWG actions that you think were inappropriate? What do
you think should have happened instead?<br>
<br>
However do bear in mind that just like the vast majority of people
in OSM everyone in the DWG's a volunteer. Some volunteered; others
were asked to join but everyone's unpaid. Also bear in mind that
everyone in OSM's a human being and deserves a basic level of
respect - even new users creating invalid POIs simply because they
don't realise they're editing a worldwide map. <br>
<br>
Best Regards,<br>
<br>
Andy (aka <a class="moz-txt-link-freetext" href="http://www.openstreetmap.org/user/SomeoneElse">http://www.openstreetmap.org/user/SomeoneElse</a> , member of
the DWG but writing in a personal capacity).<br>
<br>
<br>
* full disclosure - I'm part of the problem here, as I'm a computer
scientist rather than a geographer by trade.<br>
<br>
** part of my background was in statistical analysis of
electromechanical data (while that was still a thing), and a key
lesson from there is that you need to keep as much data as possible
in order to be able to detect odd or expensive events as they occur
- part of this has since been described as "black swan theory", but
there's a bit more to it than that.<br>
<br>
</body>
</html>