Proposal - OSM.org Editor Inclusion Policy

Foundation
, ,
1

Below is a proposal for the OSM.org Editor Inclusion Policy. This is to define a policy for adding editors to the list of supported editors on OpenStreetMap.org

OpenStreetMap.org Editor Inclusion Policy

DRAFT; see Draft Ops policy for adding editor to Edit Button Dropdown · Issue #877 · openstreetmap/operations · GitHub

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.

Definition

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 desktop GUI map editor aimed at a broad audience of (potential) mappers.

Actively used by Mappers Proven. The proposed editor must have been in active public use for a while and demonstrated its usefulness by attracting an at least X active community of mappers. ? Or Consensus that it will match this criteria once launched ?

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 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.

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.

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.

Internationaliszation. 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.

13 Likes
2

For further background see issue: Draft Ops policy for adding editor to Edit Button Dropdown · Issue #877 · openstreetmap/operations · GitHub

3

what about mobile-only editors shown only when viewed from relevant mobile platform?

I think that would be the most useful change, as currently edit button on mobile is not really useful (and if we want to reach people born after 2000 then some support for mobile users would be useful)

Also, are we missing any actually used general purpose desktop GUI map editors in the current dropdown?

Disclaimer: I contributed significantly to StreetComplete (mobile editor), and received some (relatively small compared to overall effort) external funding to work on it, I also contributed a bit to other mobile editors

also, lets say that we have theoretical “POI editor” editing desktop program, that for this purpose is somehow much better than iD/JOSM. Why exclude it? Is it about risk of ending with 20km long dropdown? Or avoiding triage of various very specialized editors?

14 Likes
4

“Or Consensus that it will match this criteria once launched ?” I would suggest to not allow this, hard to imagine case where useful editor would not find any interest among mappers and be worth featuring at osm.org website

For X: from looking at OpenStreetMap Statistics maybe 500 or 1000 mappers active within last year?

1 Like
5

While the one Elephant in the room is that this is simply the RapiD inclusion policy (there’s no expectation of any other full desktop editor being developed in the next decade).

The not so obvious 2nd Elephant and actually important point, is control over the content presented/available in RapiD. The proposed policy is completely silent on that and therefore needs to go to the round folder.

7 Likes
6

I think it would be helpful if you would elaborate on this. I’m not aware of OSM having control over the content presented in any other editors, sometimes to the frustration of the community. If you’re saying this is a dealbreaker, I think it would help if you were more specific, even if this is covered elsewhere.

2 Likes
7

I think a clarification here is needed if it means installable app (like JOSM) or web-based app (like iD) or both. Plain “desktop GUI map editor” doesn’t really specify on what type of editors people should recommend.

8

The policy would include web-based apps (like iD / RapID etc) and potentially new installable apps.

1 Like
9

RapiDs whole raison d’être is to rapidlly integrate 3rd party data into OSM for better or worse. It wouldn’t really make sense to continue the discussion without that, because why would you even want to use it otherwise.

3 Likes
10

OK - I assumed that’s what you were referring to, but didn’t want to respond just by assuming.

I have two thoughts on that:

  1. I do think that there are reasons people use RapiD other than its integration with third party data sources. The developers have significantly diverged from the iD codebase and are very responsive to feature requests and bug reports. I think there’s an argument to be made that it provides a better experience today than iD does in many cases, though I regularly use both.
  2. Shouldn’t the data be covered by rules other than an editor inclusion policy? If the data they make easier to access isn’t allowed, I wouldn’t say this is the place to litigate that item. If they’re making it easier to add data that’s not allowed, I’d think we’d have more to say than just not including them in the editor list - another policy we can already point to about data that is allowed in OSM. But that’s not my impression - I know not everyone agrees about liking RapiD’s data sources, but the data seem to be allowed per other policies. I think it’d be unreasonable to dump this editor policy on that basis.
8 Likes
11

Agreed, it seems very odd to explicitly limit it to desktop editors. I’d be curious to know the reasoning here.

(Note: I edit almost exclusively from GoMap on my phone :smile:)

6 Likes
12

This might simply be a technical nitpick, but shouldn’t there be the equivalent of JOSM’s remote control feature? Adding another editor to the “Edit” menu wouldn’t make sense otherwise.

13

I agree with those who have said mobile should be a priority. Over half of all web traffic is mobile, that’s a lot of potential new contributors, and all these people will never even see an edit button.

6 Likes
14

Is there a reason to require general purpose editors? I believe it would make sense to allow editors focusing on specific areas like PT-routes, cycling routes, house numbers…

1 Like
15

Some relevant feature requests:

There’s also this idea for promoting an editor as the website’s companion application on iOS using Safari’s standard app banner:

Personally, I don’t edit from my phone very often – the device is mostly for note-taking – but I certainly understand the motivation and promise of making mobile editors more discoverable/accessible to the site’s visitors.

3 Likes
16

That is what I was suggesting: no point in a policy covering a one off, but regulate what’s presented there. It needs to not just conform to the letter, but to the spirit of the import and automated edit policies.

Ah yes and no ODbL licenced troyan sources.

1 Like
17

Performance.

iD 2.x is based on D3 rendering framework, which has always made the app somewhat sluggish and basically unusable on a mobile device. RapiD at least got the potential to be useful and to be the general purpose editor on mobile (with UI changes), too.

4 Likes
18

This should really be done with a geo: URI or some other scheme, then the mobile user can pick their choice of editor through the normal interface for multiple apps which can handle a protocol. Ideally JOSM would also work with the scheme and then it could be renamed “Open External Editor” or something.

5 Likes
19

Without allowing this, neither iD nor P2 would have been listed on the website.

20

We’re discussing integrating the current version of RapiD not a hypothetical future one that does something else.

A rewrite of iD or a fork of RapiD maintained by the OSMF have all been discussed in the past and might or not might happen at some time in the future. Neither is dependent on the policy in question.