Automated Edits code of conduct
|It has been proposed that this page or section be merged with Import/Guidelines. (Discuss)|
|It has been proposed that this page or section be merged with Mechanical Edit Policy. (Discuss)|
Software that perform Automated Edits are expected to conform to the Automated Edits code of conduct. If you cannot or will not follow these guidelines, then please do not run a bot or make any other large-scale automated edits.
These rules apply both to:
- scripted imports
- people making large-scale edits, even with a standard editor such as JOSM, when they do not look at every individual object edited (e.g. find-and-replace)
While the OSM community does encourage the ordinary user to "be bold" and just try something out or do it halfway if he is not sure, this does not apply to automated edits. Automated edits will often change a large number of objects in large area and affect the work of many other mappers. They should be planned diligently and executed in a professional manner. If you are unable or unwilling to adhere to this code of conduct, then please consider not making an automated edit and ask someone else to do it for you.
Respect the work of others
Mappers are what makes OSM work. They are the ones spending countless hours out in the open collecting data, or hammering their notes into an editor and uploading data to OpenStreetMap. They take pride in their work and often have a sense of ownership for their contribution. If your script changes something that is obviously wrong, e.g. a typo where someone wrote "hihgway" instead of "highway", then it surely does them a service. However, if you start judging their work and modifying it according to what you think is right then you might actually break something that someone has put in there on purpose. Be very careful with such edits and ask yourself: "Am I absolutely sure that I'm not cluelessly interfering with something that is well thought out?"
Beware that even if 99% of your edits are genuine typos, 1% of "false positive" (edits that harm the works of others) can make your bot unpopular. If your bot cannot be sure that it is doing obvious correction, consider contributing to quality assurance tools like Maplint. What your bot find could be really useful for finding potential errors for examination by someone with local knowledge.
Your script does not have local knowledge. It wasn't there with a GPS and a pair of eyes. Neither were you. If you believe that nonetheless you know better than the mapper who has contributed the data, the mapper might well feel a little bit offended by "some guy with a script lording it over" - especially if the mapper is outgunned because he isn't also a programmer and he cannot make changes the way you can. Use tact and sensitivity when dealing with the work of others.
Discuss your plans
If you plan to make an automated edit, outline it beforehand and discuss it on a suitable mailing list (a regional, national or international list depending on the scope of your planned change). We do not require or recommend a formal vote, but if there is significant objection to your plan - and even minorities may be significant! - then change it or drop it altogether.
If you find that your plan is widely accepted but there are a few people opposing it, then try to get them on board by offering to make an exception for their area or for any objects last edited by them. OpenStreetMap can handle a bit of diversity; we will rather keep those people happy and contributing than overrule them and give them a reason to leave.
When your bot has a new feature, execute only a small number of edits, and get feedback on this feature before going further.
OpenStreetMap is very much built on consensus. A majority of voices on a mailing list does not give you the right to do whatever you please to the data created by the minority. Also, things that you may read in the Wiki are not a carte blanche for you to change everything so that it fits the Wiki "rules". Individual mappers have every right to tag things differently from what is stated in the Wiki, and it is not OK for anybody to turn the suggestions contained in the Wiki into strict rules that are applied automatically.
Execute your plans with caution
If you run a script against the database, make sure to minimize the risk of accidentally overwriting something that has been just modified by someone else (i.e. do not simply use yesterday's planet file as a basis for uploading changed objects as this would break changes made in the mean time). Also make sure to keep all data you need in case you have to revert your change when something goes awry. (If you do not feel up to the task of reverting everything you have done, then don't start making changes.)
If you plan to make a very large number of edits (in the six-digit range or more), it may make sense to double-check with the admins (try IRC) - ask whether there is something else going on that you might interfere with, or check the Munin graphs to find out at which time the servers are not busy.
Make sure that there is some way of identifying that a certain change has been made by your script. You could create a special user account for the script, or you could add a "source", "created_by", or "note" tag or something.
Plan your changesets sensibly. If your bot creates one changeset for each edit, that becomes extremely hard to read for people. If your bot creates one changeset for a bunch of changes covering the whole planet, that, too, becomes hard to read. Changes grouped into small regions are easiest to digest for human mappers (e.g. "fixed highway tags in Orange County"). Choose good changeset comments - "Some fixes" is not a good comment!
Always remember that local knowledge beats a couch potato from central command any time!
Avoid edit warring
If someone should revert your changes, do not start a tit-for-tat reversal of edits. This only annoys everyone and blows the database history out of proportion. Seek a dialogue with the people involved, and get someone else to mediate if you cannot find a solution.
This applies to everyone who edits OpenStreetMap, including people who are "combating" automated editing.
Document what you have done, or are doing
Make sure that people who check an object's history later on can find out about your script and what it has done, exactly. Document the exact scope of the change, the geographic area where you applied it, the date and time it was run, and the number of objects affected. If you run your script on a regular basis, or even continuously, then document exactly what algorithms you are using and what triggers your script. Suitable places to document your bot might be
- The page Automated Edits/Log
- The www.openstreetmap.org user page for your bot account
- A wiki page that has the name of your bot
- or any other place if you link there from your changeset comment.
The community expects that you make this documentation available in English or in the national languages of all countries where you edit something. So if your bot runs only in Spain, then it is ok to document it in Spanish. If it runs in Spain and France and Germany then you either have to document it in Spanish, French, and German; or you can opt to write the documentation in English which we presume enough people will understand.