[OSM-talk] Automated edits code of conduct

[tuxayo]

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?
Because clarifying the AECoC about the law vs guidelines philosophy
would require a reasonable amount of legitimacy (there is no hope of
true consensus here) to edit the AECoC in a way making it clear that one
of these philosophy is chosen.
Currently we have "guidelines that must be followed at all times" which
is ambiguous.



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

Nice analysis, warning about the second approach because it makes harder
to review that the automated changes were correctly executed. While also
making hard to review the manual changes as they are buried in the many
automated ones. These make a reviewability (and therefore quality) issue
that should be avoided.

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.


Cheers,

-- 
tuxayo