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

Hendrik T. Voelker hvoelker at nutrimatic.de
Tue Sep 30 15:58:48 BST 2008


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.

   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





More information about the talk mailing list