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 (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.
Note that any blocks longer that 96 hours are actually applied by the System Administrators, though the DWG may ask for such a block (via the process described in the linked document).
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.
Who we are
- Peter Barth (Germany; also on OSMF Board)
- Deanna Earley (UK)
- Ethan Nelson (USA)
- Vladimir Marshinin (Russia)
- Toby Murray (USA)
- Paul Norman (Canada; also on OSMF Board)
- Nelson A. de Oliveira (Brazil)
- Tom Pfeifer (Germany)
- Frederik Ramm (Germany; also on OSMF Board)
- Guillaume Rischard (Luxembourg)
- Grant Slater (UK)
- Andy Townsend (UK)
- Sidorela Uku (Albania)
- Ben Abelshausen
- Matt Amos
- Tom Hughes
- Sylvain Letuffe
- Mikel Maron
- Roland Olbricht
- Eugene Sandulenko
- Henning Scholland
- Dave Stubbs
- Jo Walsh
- Richard Weait
- Serge Wroclawski
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:
- DWG Activity Report for Jan-Jun 2013
- DWG Activity Report for Jul-Dec 2013
- Data Working Group/DWG 2015-12-18 Resolution Banning PeterDRS
- DWG Activity Report Q1 2016
- DWG Activity Report Q2 2016
- DWG Activity Report Q3 2016
- DWG Activity Report Q4 2016
- DWG Activity Report Q1 2017
- DWG Activity Report Q2 2017
- DWG Activity Report Q3 2017
- DWG Activity Report Q4 2017
- DWG Activity Report Q1 2018
- DWG Activity Report Q2 2018
See also the OSMFoundation's policies and documents page.
Please send an email to firstname.lastname@example.org.