[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