On 7/14/2016 7:14 PM, Éric Gillet wrote:
2016-07-14 6:12 GMT+02:00 tuxayo <[email protected]
<mailto:[email protected]>>:
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.
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
