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

[Gert Gremmen]

Hendrik,

I feel that you take the right approach in
creating concensus.

Do not forget to tackle somewhere the 
unlimited power of JOSM in uncaring hands.

Which in itself is an amazing piece of
software for something written in an
"iterative language" and it's getting
'better and better. 

Gert Gremmen
-----------------------------------------------------

Openstreetmap.nl  (alias: cetest)


-----Oorspronkelijk bericht-----
Van: talk-bounces at openstreetmap.org
[mailto:talk-bounces at openstreetmap.org] Namens Hendrik T. Voelker
Verzonden: Tuesday, September 30, 2008 4:59 PM
Aan: Talk Openstreetmap
Onderwerp: Re: [OSM-talk] Code of conduct for automated (mass-) edits

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


_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk