<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-07-14 6:12 GMT+02:00 tuxayo <span dir="ltr"><<a href="mailto:victor@tuxayo.net" target="_blank">victor@tuxayo.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/07/2016 09:25, Éric Gillet wrote:<br>
> I will summarise what course of action I think would be appropriate to<br>
> follow :<br>
><br>
</span>>   * It's not clear whether AE CoC terms are rules or simply guidelines<br>
>       o As Frederik said, rules should be written well in order to have<br>
<span class="">>         the legitimacy to be used strictly (ODbL, Contributor's Terms etc.)<br>
</span>>       o Guidelines should contain, well, guidelines that should not be<br>
<span class="">>         used as a direct basis for reversal. They could be used as part<br>
>         as an argument, but just using one item should not be grounds<br>
>         for reversal by DWG.<br>
</span>>   * In consequence, a choice have to be made :<br>
>       o Either overhaul the current AE CoC, submit it to RFC/voting and<br>
<span class="">>         use it as a ruleset for contribution after a consensus is reached<br>
</span>>       o Use the current AE CoC as guidelines, not strict rules.<br>
<br>
Should an RFC + vote be made on this? Or is there a simpler process to<br>
try to settle (for at least one/few years) this issue?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> So what do you suggest :<br>
><br>
</span>>   * Do one changeset by feature you're editing, where you both correct<br>
<span class="">>     the original subject of the error and othoner problems ? (Very slow,<br>
>     but higher quality at the end)<br>
</span>>   * Do both the search and replace and correct other errors on multiple<br>
<span class="">>     other errors "completely manually" in the same changeset ? (Time<br>
>     efficient but slow, good quality of data, but at risk of reversal of<br>
>     the whole changeset)<br>
</span>>   * Correct "automatically" what can be automatically corrected, and<br>
<span class="">>     rely on QA tools to spot the other errors ? (Time efficient, quick,<br>
>     but leave other errors untouched)<br>
><br>
> These three approaches seems valid to me, but it doesn't seem to be the<br>
> case for everyone.<br></span><br>
A fourth approach to fix that would be to have a first automated edit<br>
changeset and then a manual fix changeset for the other errors.<br>
A variant would be to reverse the order: fix the other errors first when<br>
inspecting the selected/searched objects to be automatically edited. And<br>
then doing the automated edit.<br></blockquote><div><br></div><div>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 ?</div></div></div></div>