Below is an updated proposal for the OSM.org Editor Inclusion Policy. The is to define a policy for adding editors to the list of supported editors on OpenStreetMap.org
Inclusion of “Acceptable to Website Maintainers” section.
The OSM Operations Team will be discussing the Editor Inclusion Policy on our 8th August 2024 fortnightly call and hope to move forward with the policy.
Proposed new editors that will be featured on the OSM website should follow the following guidelines. Anyone may propose new editors for consideration and any such proposed additional editor should be added to the proposals section of the Featured Editors page.
The acceptance of an additional editor is not automatic and must be assessed on a case-by-case basis using the following criteria as a guide.
Definitions
Editor: A GUI application that provides its users with the capability of downloading, reviewing and modifying current OSM data, and committing changes to the data back to the OSM database.
Criteria for possible inclusion
A proposed editor must satisfy the following hard criteria:
Internally Supported. The editor’s maintainer must be in favor of having their editor included on the OpenStreetMap website.
General Purpose and General Audience. The proposed editor must be a general purpose GUI map editor aimed at a broad audience of potential mappers.
Actively Used by Mappers. The proposed editor must have been in active public use for a while and demonstrated its usefulness by attracting an active community of mappers.
Best Practices. The proposed editor should make a reasonable effort to support widely accepted best editing practices to discourage mappers from making harmful edits to OpenStreetMap data.
Open Source. The proposed editor’s source code and supporting code must be published under an open and permissive license.
Community Feedback. The proposed editor must have an open community feedback channel where its maintainers actively respond. The editor must be part of the Software Dispute Resolution Panel.
Reliable Service. The proposed editor must be reliable in terms of uptime and availability.
Privacy Policy. The proposed editor must publish a Privacy Policy that clearly lays out how any PII is stored and handled.
Acceptable to Website Maintainers. Web based editors must be embedded on openstreetmap.org in a way that is acceptable to the OpenStreetMap.org website maintainers. If the editor is not embedded the method by which the editor is called must be acceptable to the OpenStreetMap.org website maintainers.
A proposed editor should satisfy the following soft / arbitrary criteria:
Open Contribution. The proposed editor’s maintainers should be open to receiving community contributions to the code and adding new people as maintainers.
Internationalisation. The proposed editor should offer languages other than English for its graphical user interface.
Help and Documentation. Help and / or documentation should be available to aid mappers in using the proposed editor.
Unique. The proposed editor should offer something unique in approach or execution.
Additional notes
Requests for new editors to go to the Operations Working Group who will use these guidelines to evaluate the proposed editor and, if accepted, implement the change.
There is a practical limit to the number of editors presented. That limit is currently undetermined.
Editors are not guaranteed a permanent place on the website, they may be removed at any time.
If a large number of new editor requests is being made, the strategy will have to be re-evaluated at that time.
As far as I’m aware, iD is the only editor that participates in the SDRP.
Now, this policy is written to apply to new editors, but I find it notable that three editors are featured on OSM.org that do not meet this criterion.
If we applied the requirement to participate in SDRP retroactively, then JOSM et al would need to either join the SDRP or else their listing and/or Remote Control entirely would need to be removed.
Now, Potlatch and Merkaartor are essentially dead relics from the past which are no longer in active development that we kept on the list because it’s zero effort on our part – the remote control function is just a redirect to localhost sitting on a certain port with the map lat/lon in the querystring. We would lose nothing if those two names disappeared from the edit list.
Is there a good reason why a new editor should comply with the requirement to adopt SDRP but JOSM gets a free pass?
Not really. Remote Control is a protocol that any desktop application can use. “Featuring” desktop editors would mean at the least providing download links etc. The text in parentheses here is really just explaining context by giving examples.
This is a sidebar … but, we could easily create controversial decisions pages for every aspect of OSM, software or not! I always thought it was unfair, but now especially I find continued use of that page unhelpful, as we have quite different management of iD since the time of its origination.
More to the point, yes, issues around iD led to the SDRP. I don’t believe the SDRP has ever been evoked. That doesn’t mean it doesn’t have a job to do – I think knowing there is an ultimate arbiter is helpful for resolution of issues before they escalate.
The original proposal for the SDRP states the following: “Other OSM-related software products may also use this Panel if they choose to opt-in.”
So since this is designed as an opt-in thing, I think it is unfitting for the OSM.org editor inclusion policy to make opting in a requirement.
I originally thought this as well when seeing the editor inclusion policy update. But I think this is a different situation, as we’re looking at editors in prominent position on the site, and we want to make sure there is stability there. And just because the policy is opt-in to other projects in general, does not mean it can not be mandated in other situations.
The SDRP specifically says: “Opting into cooperation with the Panel is voluntary and will not, for example, factor into OSMF decisions related to funding.”
The SDRP was not approved with the idea of mandating opting in in order to comply with other policies in mind. The SDRP will have to be rewritten as a compulsory thing and receive a new round of voting if we want to go ahead with this.
It is not a requirement for any project to opt-in to the SDRP. However, it is also not required that OSM.org accept an editor into the main page that has not chosen to opt-in.
Relevant comment here expressing intent to “drop reference the desktop editors because they already handled by the remote editor protocol”. In that case the menu item would just read “Edit with Remote Control”.
You’re twisting the logic here. Featuring editors based on other criteria is totally fine, but basing the decision on cooperation with a panel that has been approved as a voluntary, opt-in thing for which cooperation is explicitly stated to not factor into OSMF decisions is outside the mandate that was given to the panel by the OSMF and not what people have voted for when the SDRP was approved.
Not really. All of the requirements are essentially voluntary. It’s entirely within bounds for OSM to require minimum standards of governance for projects that they partner with.
For example, when Americana partnered with OSM US, we had to opt in to the OSM US Code of Conduct.
I’m sure you can think of some examples of OSM adjacent projects that suffer from governance challenges that we would want to avoid going forward.
This is well beyond any minimum, though. This essentially says that editors which want to be featured on osm.org have to comply with a panel with members picked by the OSMF board, a panel for which cooperation was supposed to be voluntary and which was explicitly designed and approved to not factor into OSMF decisions.
Alternative governance standards that I can come up with would be to either let the OWG judge if the other requirements (including the presence of an open community feedback channel) are properly followed, or the SDRP can be voted on again with the amendment that cooperation with the panel can be a requirement for software that wants to be directly linked to OSM / can factor into OSMF decisions.
How does these two match? iD is general purpose and kind of universal. A PT-only editor would be unique but not general purpose. Another general purpose editor would not be unique to iD.
In V1 of the draft I asked for clarification of that term. Why this can’t state in simple English: The editor should offer English and other languages. I assume, that’s the intention of that.
To me it makes more sense to request, the editor must offer a method, where the translations can be maintained externally.
Since the webservice would be hosted by OSMF or at least be part of the OSM-website, that policy should clearly state, that the editor must fullfil the OSMF Privacy Policy.
(Speaking as an individual who happens to be on the SDRP, but not formally on behalf of it.)
As I understand it, the OWG feels that the SDRP is better positioned to judge non-technical matters of tagging policy and the like. Conversely, if a purely technical matter were to come before the SDRP that seems like one of the OWG’s core competencies, we’re authorized to consult the OWG about it. The current wording would formalize that division of responsibilities. That would have the benefit of providing both the complainant and the editor’s developers with more predictability versus an ad hoc arrangement.
The board has the final say on whether the panel would be competent to oversee a project as a condition of this policy, just as it has the final say on any of the OWG’s proposals. I would expect – and you should demand – that no decision by the SDRP would hinge on whether the project submits to the panel on its own volition or as a condition of this policy. That would be a strange violation of impartiality.
Generally I think this is pretty good. Two suggestions:
Clarify (para 2) that the criteria are the minimum to be accepted, and that the OSMF board still has the ultimate decision whether to accept or reject.
Clarify (‘Definitions’) that changes to data must solely be made to the OSM database, and that those changes must be made under the OSM licence and Contributor Terms. As an example, I could in theory compile Potlatch to WebAssembly; add some features that contributed certain map data to cycle.travel only, under a proprietary licence; and submit it for inclusion. The current draft doesn’t prohibit this.
