Data Working Group
One of the OSMF working groups, the Data Working Group mainly concerns itself with:
- the resolution of issues in copyright violation, disputes, vandalism, and bots, beyond the normal means of the community;
- helping to set policy on data;
- detecting and stopping vandalism and imports that do not comply with guidelines.
What we do
What do people ask us to do?
We will take action when we're informed that data that isn't license-compatible with OpenStreetMap has been added to the database.
We sometimes get complaints about how things are mapped within OSM, or more usually, how a particular map displays it. This might be the "standard map" at the OSM website, or a completely different one that uses OSM data.
We're also one of the groups emailed when the OSMF receives a DMCA notice through the official form.
We get quite a lot of general requests for information, but generally refer these to the more usual sources of information such as help.openstreetmap.org and IRC, where questions are often answered already and can be more easily shared.
When there are boundary or language disputes (e.g. both country A and country B claim an area) we often get involved. The OSMF has a policy document that covers this. Dealing with these can be difficult and time consuming (since by their own definition both protagonists are "correct" and one of them is bound to be disappointed), but we do try and treat such cases as fairly as we can.
We get asked quite often to deal with "vandalism", which often is not so much real vandalism, but rather a misunderstanding of what OpenStreetMap actually is - for example, some new users don't realise that their edits are shared with everyone else and may try and delete everything that they don't want to appear on "their" map. We do also get real examples of vandalism of course, sometimes politically motivated, sometimes commercial and sometimes neither of those, but thankfully it's relatively rare.
Inadequately discussed data imports and mechanical changes to data are another source of requests for help that we receive; we try and help the importer understand the process they should have followed (and why - OSM contains freeform tags with freeform values and people from e.g. a computer science background may not be used to working with such a database or aware of the impact of their actions).
We get requests for technical help (for example, to revert a changeset that is so large that it can't be downloaded from the API without a timeout).
Probably the single most common action that we take is to try and help mappers to communicate better with one another. Usually, that suggests the use of good changeset comments and mapper to mapper communication via changeset discussion comments (the GSoC project that delivered that feature was mentored by a DWG member). Changeset discussions are public; which definitely helps elevate the politeness of discussions - also other interested parties can comment too.
What can we do that other mappers can't?
All of the above actions are carried out without any special privileges on the OSM website. There are however a few things that we can do that go beyond what normal users are able to do:
If data was copied from a non-licence-compatible source then it's not good enough just to "revert" the change to OSM (since OSM maintains a history of objects); the problem data must actually be redacted. After redaction a version of an object will no longer be displayed and instead users see a message such as "Version 3 of this node cannot be shown as it has been redacted. Please see Redaction 6 for details.". The list of redactions used can be seen at http://www.openstreetmap.org/redactions/ .
Hiding offensive material (e.g. notes)
Some textual data within OSM such as notes and changeset discussion comments can be hidden. We do this when requested to, such as when someone has inadvertently shared personal information that they did not plan to (perhaps via an application that they did not expect to create a public note), and when someone writes something offensive.
The Data Working Group can force users to read a message before they continue to map and can optionally impose a short (usually up to 96 hours) moratorium on editing. The OSMF Ban Policy document goes into more detail about how and when these are used. The vast majority of blocks imposed do not consist of any "blocked from mapping" period; they are simply messages that have to be read, usually to indicate that other people have tried but failed to get in touch with a particular person. Blocks don't imply that users have done anything wrong, and often contain friendly language to try and communicate that fact. Usually before any block is applied (even a "0-hour message that has to be read") attempts will be made to contact the mapper, such as via changeset discussion comments.
The list of user blocks (of all kinds) is public.
I've seen a problem; what should I do?
Firstly, if possible, please do contact the mapper concerned and let them know there's a problem, such as via a changeset discussion comment. There will be cases where this isn't possible of course - perhaps a mapper's actions make you uncomfortable about contacting them directly.
If that doesn't work or isn't possible please contact the Data Working Group, preferably by email on email@example.com. In the email try and explain the problem, and if you can link to specific examples of it (e.g. "this mapper has changed something incorrectly and the item they have changed is http://www.openstreetmap.org/way/1"). The more examples you can provide of a specific problem, the better. As well as explaining what is wrong, try and explain why it is wrong (perhaps "mapper has changed all examples of 'foo' in the database to 'bar', not understanding that 'bar' means something very different to 'foo'). If there has been discussion on a country- or language-specific mailing list or forum please link to that too. Don't worry if it's in a language that isn't directly understood by DWG members; we'll work it out.
I feel that I have been treated unfairly by DWG
In order to handle our workload efficiently, related complaints will often be handled by the same DWG member. DWG members will often discuss the issues with other members informally but formal votes are the rare exception. A DWG member may hand off issues to colleagues if they feel that another pair of eyes would help the situation. But if you - either as the complainant or as the person subject to a block or revert - would like a different DWG member to evaluate the situation, you can tell us and we'll accommodate that request if at all practical.
If you have raised a complaint that way and you are still unhappy with the result, please take a moment to consider what you have been told. By this time at least two, possibly more, DWG members have independently reviewed your case. It is very likely that they will have a point. Consider also whether your issue is of such significance that more OSM volunteers should be spending their time with it! If you believe you have been wronged by DWG, and your matter is of great importance, then you can raise a complaint to the OSMF board of directors, who might try to mediate, or could even overrule a DWG decision.
Who we are
- Rafael Avila Coya (Spain)
- Michal Brzozowski (Poland)
- Dennis Raylin Chen (Taiwan)
- Graeme Fitzpatrick (Australia)
- Claire Halleux (DRC)
- Andrew Harvey (Australia)
- Anton Khorev (Russia)
- Lukasz Kruk (Poland)
- Lucas Longour (France)
- Jesús López Témez (Spain)
- Vladimir Marshinin (Russia)
- David Morais Ferreira (Luxembourg)
- Toby Murray (USA)
- Rihards Olups (Latvia)
- Tom Pfeifer (Germany)
- Elliott Plack (USA)
- Shawn K. Quinn (USA)
- Frederik Ramm (Germany)
- Guillaume Rischard (Luxembourg)
- Andy Townsend (UK)
- Marc Zoutendijk (Netherlands)
Minutes, Reports and Resolutions
The Data Working Group currently has a bi-monthly meething schedule. We use email, a wiki and IRC for regular communication and occasionally produce resolutions or documents:
there were no further meetings as
See also the OSMFoundation's policies and documents page.
Please send an email to firstname.lastname@example.org.