2016-07-14 6:12 GMT+02:00 tuxayo <vic...@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 ?
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Reply via email to