[OSM-talk] Automated edits code of conduct

Warin 61sundowner at gmail.com
Thu Jul 14 11:36:35 UTC 2016


On 7/14/2016 7:14 PM, Éric Gillet wrote:
> 2016-07-14 6:12 GMT+02:00 tuxayo <victor at tuxayo.net 
> <mailto:victor at tuxayo.net>>:
>
>     On 13/07/2016 09:25, Éric Gillet wrote:
>     > 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
>     >       o As Frederik said, rules should be written well in order
>     to have
>     >         the legitimacy to be used strictly (ODbL, Contributor's Terms etc.)
>     >       o 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 :
>     >       o Either overhaul the current AE CoC, submit it to
>     RFC/voting and
>     >         use it as a ruleset for contribution after a consensus is reached
>     >       o Use the current AE CoC as guidelines, not strict rules.
>
>     Should an RFC + vote be made on this? Or is there a simpler process to
>     try to settle (for at least one/few years) this issue?
>
>
> I don't see a simpler process than this other than just accepting the 
> status quo. As you said before, this process is what is used in OSM 
> (for tags), and it seems democratic to vote on rules.
>
>     > 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.
>
>     A fourth approach to fix that would be to have a first automated edit
>     changeset and then a manual fix changeset for the other errors.
>     A variant would be to reverse the order: fix the other errors
>     first when
>     inspecting the selected/searched objects to be automatically
>     edited. And
>     then doing the automated edit.
>
>
> That would be slightly faster to execute than the first approach I was 
> suggesting, but then how would you prove that you checked every and 
> all features ?
One could upload the data for each feature - one changeset = one 
feature. That would at least show a time lag between each. Of course 
this would impose a larger load on both the contributor and the OSM web 
connection, but if that would avoid the continued accusation of 
'mechanical edit' then so be it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20160714/d33eaf67/attachment.html>


More information about the talk mailing list