[OSM-talk] Automated edits code of conduct
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
> > 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
> > 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
> > 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
> > 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...
More information about the talk