[OSM-talk] Automated edits code of conduct

Éric Gillet gill3t.3ric+osm at gmail.com
Wed Jul 13 07:25:10 UTC 2016


2016-07-12 19:35 GMT+02:00 Andy Townsend <ajt1047 at gmail.com>:

> On 12/07/2016 17:29, Éric Gillet wrote:
>
> 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?
>

I will summarise what course of action I think would be appropriate to
follow :

   - It's not clear whether AE CoC terms are rules or simply guidelines
      - As Frederik said, rules should be written well in order to have the
      legitimacy to be used strictly (ODbL, Contributor's Terms etc.)
      - Guidelines should contain, well, guidelines that should not be used
      as a direct basis for reversal. They could be used as part as an
argument,
      but just using one item should not be grounds for reversal by DWG.
   - In consequence, a choice have to be made :
      - Either overhaul the current AE CoC, submit it to RFC/voting and use
      it as a ruleset for contribution after a consensus is reached
      - Use the current AE CoC as guidelines, not strict rules.



> 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.
>

DWG members are volunteers, I am too, you surely are too. Contributor's
time is a premium ressources in projects such as OSM. So let's not waste
any of it :)


> Andy (aka http://www.openstreetmap.org/user/SomeoneElse , member of the
> DWG but writing in a personal capacity).
>

Thank you for disclosing that and differentiating between DWG
actions/opinions and yours.

-----

2016-07-13 5:36 GMT+02:00 Nicolás Alvarez <nicolas.alvarez at gmail.com>:

> 2016-07-12 23:08 GMT-03:00 tuxayo <victor at tuxayo.net>:
> > Automated edits should also have a place. For thing like pure tagging
> > errors:
> >   - URLs lacking "https://" prefix
> >   - leading and trailing spaces in names
> >   - common, obvious and non ambiguous typos
> > The error probability is almost null (error in script or typo?)
>
> When I searched for typos and leading and trailing spaces in my area,
> I found lots of unrelated wrong things. For example, many objects with
> trailing spaces in the names were "my house is here" nodes. Or roads
> including the name of the political administration that was around
> when the road was built (typical political bullshit that appears in
> signs sometimes, but it's *not* the name of the road).
>
> Checking them one by one was a great idea.


I agree that often an error is not alone and it would be best to correct
all them while explaining to each individual contributor why it's and
error, but as I said before, time is a premium. Here are other problems :

   - It slows down the actual error correction
   - As I said before : if you lace "completely manual" modifications with
   "slightly automated" (search/replace) and face objections for the
   "automated" part of your changesets, there are every chance that the whole
   changeset would be reverted, or even all the changesets in a time interval
   (just ask Test360 about it)

So what do you suggest :

   - Do one changeset by feature you're editing, where you both correct the
   original subject of the error and othoner problems ? (Very slow, but higher
   quality at the end)
   - Do both the search and replace and correct other errors on multiple
   other errors "completely manually" in the same changeset ? (Time efficient
   but slow, good quality of data, but at risk of reversal of the whole
   changeset)
   - Correct "automatically" what can be automatically corrected, and rely
   on QA tools to spot the other errors ? (Time efficient, quick, but leave
   other errors untouched)

These three approaches seems valid to me, but it doesn't seem to be the
case for everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20160713/2300fa09/attachment-0001.html>


More information about the talk mailing list