[OSM-talk] Code of conduct for automated (mass-) edits

[M. S.]

Le Tuesday 30 September 2008 16:58:48 Hendrik T. Voelker, vous avez écrit :
> Guys,
>
> after we now had a longer discussion I guess several things are clear:
>
>    We agree that as a first step a code of conduct concerning mass changes
> is a very good idea and maybe Frederik can draft one and add it to the wiki
> as a proposal.
yes it is more then urgent, I noticed today that 2 OSMers have screwed up 
100's of my work hours and changed place names and coastlines shapes bringing 
them back to innacurate/false state

cheers



>
>    Following that most agree that a code of conduct alone might not be
> enough and we would need to define some more potent means to prevent
> disasters. Several were named, like a sandbox and test suit for verifying
> the tool works, like some kind of certification and authorisation for mass
> changes, and including the self-evident things like logs and undo files.
>
>    It has become evident, that to most feared problems are stupid edits and
> the loss of data because older sources (planet files) are used as the
> change base.
>
> In today's IT business it is normal in these kinds of situations, to not
> only work on most current data sets - like Paolo's approach does - but also
> to lock the record being worked on to prevent race conditions.
>
> If we all the names requirements we maybe could think about the following
> solution:
>
> OSM is providing the framework and execution means for mass changes.
>
> To get something done, one has to create a Java class that described the
> bot. That then is submitted to the OSM bot execution facility - or what
> ever you want to name it. The framework that executes that class provides
> for record selection and locking, and also provides the means to roll back
> instead of commit the changes in case of errors. And also the means for
> logging and presenting the results officially on the wiki or where ever. As
> this can run directly on the DB this is faster and more reliable than an
> HTTP(S) connection.
>
> The developers for the bot class can be provided with test means like sand
> box, test data and JUnit frameworks.
>
> Granted, that might limit the development to Java programmers but hey, if
> you know one iterative language, you can easily learn another. And yes, it
> might prevent a fast hack - but then, that's what we want, isn't it?
>
>    And yes, I know that it takes time to agree upon this, time to implement
> it,  time and money to set it up, time to certify all the classes, ...
>
> In the end, this is just another idea :)
>
> Cheers
>
> Hendrik
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk