The OpenStreetMap Foundation Board of Directors seeks to resolve controversies that have periodically arisen around updates of and enhancements to the iD editor. This request for comment is expected to lead to adoption of community structures that will not answer to the Board or be influenced by the Board, in keeping with the OSM philosophy that the Board supports OSM but does not tell anybody what to map or how to map. We ask that comments be made on the OSM-talk mailing list (register to OSM-talk) or -if you are an OSMF member- to the OSMF-talk mailing list discussion (register to OSMF-talk).
OSMF offers and recommendations for iD governance
iD is the simple, friendly, default web editor for OpenStreetMap, centrally important software for the project. There’s a lot of passion about its development, and that appears sometimes to become a problem.
The OSMF Board recently convened a small gathering to discuss how to improve the development environment for iD. While there have certainly been times when major and minor decisions in iD have triggered conflict, the vast majority of development discussions are non-polarizing and productive. The convening focused on the key areas where problems emerge (most often, though not only, tagging), and ways to allow for constructive disagreement and resolution, without their deteriorating into disputes that hurt the project.
Essentially, the maintainers of iD need a productive space to carry out their work; contributors, users and other interested parties need to be heard; the decision-making process needs to be understood and respected; and disputes need a way to escalate and resolve.
There’s no technical solution to this kind of situation. What’s required is process and organization. To that end, below are several offers and recommendations from the OSMF Board that the iD project may consider supporting and adopting. We hope that the iD project finds these suggestions helpful and looks forward to discussing what sounds workable and what does not.
OSMF will establish an appeal process
OSMF is seriously considering creating or identifying a body to adjudicate various kinds of technology disputes, capable of drawing on expertise ad hoc to determine the best path forward for the community. Software projects could opt-in into using this appeal process; it would not be required. This appeal process may simply involve arbitrating the disagreement between different parties or projects and helping to find agreement between them; or might involve making or overruling decisions. This mechanism is under early discussion, yet to be defined.
If disputed decisions cannot be resolved directly within the iD project by its maintainers and stakeholders, then the issue can be escalated to this appeal process.
The role of this group would certainly not be to force developers to add certain features. However, if issues are escalated to the group, it could verify that newly added features (e.g., presets, validation rules, or inclusion of external services) are in line with a consensus view.
If this sounds potentially helpful at this stage, OSMF asks iD to share input and expectations to make the process most effective.
OSMF will support development of better systems for tagging decisions; iD documents status quo and separation of concerns
The only way to assess the “correct” tags is a baroque evaluation of the various sources of OSM documentation – the wiki, tagging mailing list, taginfo. This leaves editing and consumption tools in the position to “decide” on what tags are appropriate or not for OpenStreetMap. When this turns contentious, at best this is an unwelcome distraction; and at worst, development can be blocked. To this end, the OSMF welcomes the development of better documentation, decision-making and a curation process for tags. Where needed, the OSMF is prepared to aid such efforts with infrastructure and other support. This would provide a greater degree of clarity for tool developers. If an action taken on presets in iD is contested, the issue could be escalated to the appeal process described above.
For iD’s part, while work on tagging systems is ongoing, we recommend now adding detail on the status quo approach iD takes to tagging decisions in CONTRIBUTING.md. It’s clear that iD aspires to refrain from making decisions on what tags are appropriate for OpenStreetMap; rather, iD aims to represent the consensus view on tags in presets. “Consensus” is currently subjective, and the iD project strongly (we believe, please say so if otherwise) supports efforts in OSM to bring more clarity to how tags are developed.
Presets can be requested in issues, and in PRs, as well as discussion in the issue/PR. The maintainer of iD reserves the right to include or exclude certain tags/presets on technical or usability grounds, though the goal is to avoid curating tags and making decisions on the merits of tags in general. If there seems to be consensus, based on evaluation of source documentation, and it meets a need for other users, presets will be accepted. If there is not clear consensus, the preset (or validation rule, etc.) won’t be accepted.
Institute quarterly planning meetings, and publish bi-weekly sync time and notes
OSMF recommends iD hold a quarterly (or so) video meeting with iD stakeholders. This meeting is a chance to step out of the everyday work of iD and make sure work is on the right path. The agenda would assess development over last quarter, discuss requirements and priority needs, and make plans for the next quarter and beyond. Additionally if any decisions or topics have proven difficult or disputed over the past quarter, this is a time for direct discussion. Notes will be taken and distributed.
Additionally, iD holds a bi-weekly sync, but it is not well known. iD could raise awareness of the bi-weekly sync by announcing it on additional channels, including https://ideditor.blog/; and make sure notes from the sync are visible and accessible.
iD can improve clarity on decision making and communication
We recommend that in CONTRIBUTING.md iD maintainers add a new section which explains how decisions are made in iD. Some points made here are contingent on adopting other recommendations. The new section would explain the following.
- There are many places to discuss and input on iD development – GitHub issues and PRs, the monthly syncs, quarterly planning meeting, and in response to announcements on https://ideditor.blog/.
- The developers of iD are committed to being responsive and transparent. By default, iDs maintainers determine the sequence and timing of fixes, changes and enhancements in order to optimize technical work.
- Invite stakeholders to join an “acceptance testing” process, where feedback on releases is sought and handled for a time delimited period of time.
- Ultimate decision on accepting PRs is with iD’s maintainer, Quincy Morgan.
- If there is a dispute on a decision, that will be escalated to the quarterly planning meeting and/or an appeal process managed within the OSM Foundation.
Additionally, we recommend that iD publish a roadmap and regularly update status on major iD releases. iD3 plans were last shared at SotM US. The approach has changed, with more focus on updated UI, and more iterative efforts on componentization. It would be good to get a clear idea of where things are, and where things are going (as much as is clear now), and especially where help is needed in order to build momentum on this important effort.
Document how Code of Conduct is handled
iD has a Code of Conduct but it lacks details on how to report a harmful incident within the iD development environment, and how those reports are adjudicated. Previously Code of Conduct complaints were addressed openly by opening an issue on GitHub, but maintainers later directed people towards the private OSMUS committee. Clarity on process is just as important, if not more, in order for a CoC to be helpful to the project. If that process is not well defined, then thought is needed, perhaps within the quarterly planning meeting. Our recommendation is to add a section on CoC process.
Allan Mustard
Chairperson, OSMF Board of Directors
The OpenStreetMap Foundation is a not-for-profit organisation, formed to support the OpenStreetMap Project. It is dedicated to encouraging the growth, development and distribution of free geospatial data for anyone to use and share. The OpenStreetMap Foundation owns and maintains the infrastructure of the OpenStreetMap project, is financially supported by membership fees and donations, and organises the annual, international State of the Map conference. It has no full-time employees and it is supporting the OpenStreetMap project through the work of our volunteer Working Groups. Please consider becoming a member of the Foundation.
OpenStreetMap was founded in 2004 and is a international project to create a free map of the world. To do so, we, thousands of volunteers, collect data about roads, railways, rivers, forests, buildings and a lot more worldwide. Our map data can be downloaded for free by everyone and used for any purpose – including commercial usage. It is possible to produce your own maps which highlight certain features, to calculate routes etc. OpenStreetMap is increasingly used when one needs maps which can be very quickly, or easily, updated.
