openstreetmap / operations

OSMF Operations Working Group issue tracking
https://operations.osmfoundation.org/
99 stars 12 forks source link

Draft Ops policy for adding editor to Edit Button Dropdown #877

Open Firefishy opened 1 year ago

Firefishy commented 1 year ago

The OSM Operations team currently do not have a policy for adding an Editor to the openstreetmap.org edit dropdown menu.

We currently have policies for Info Message and Adding a new tile layer.

We should draft a policy for the requirements / expectations for adding an editor to the dropdown.

Firefishy commented 1 year ago

cc @grischard

Firefishy commented 1 year ago

For a laugh I got chat-gpt to draft a policy, it has some interesting bits: https://gist.github.com/Firefishy/a2aeb106a0a9736a84e654db7614dca5

mvexel commented 1 year ago

The ChatGPT version is actually a decent start 🤖 But does it make sense to have a separate policy for this? How many general-purpose editors exist or could we expect to be built that would be tested against it? The only one existing today that I can think of off the top of my head is Rapid.

If we were to come up with a policy, would it make sense to have it be about links on osm.org to external tools more in general? For example on a changeset detail page you could link to OSMCha, Achavi etc, on a relation detail page to OSM Relation Analyzer, on the history page to Deep History. There's a lot of external tools that could be useful to link to for mappers. A policy to guide those decisions would help.

tomhughes commented 1 year ago

Well if you actually want a decision then I suggest not complicating things!

We have refused to add links to the sort of tools you mention on many occasions in the past and I don't really want to reopen that - the number of such tools which exist is one major reason why they create rather different issues.

One thing I'm still not entirely clear about with regard to the specific request that led to the creation of this policy is whether it was talking about linking to an external instance of the editor or integrating one in the way iD is - it's important because the things we need to consider are rather different for the two cases.

mvexel commented 1 year ago

Well if you actually want a decision then I suggest not complicating things!

Our combined 30+ years experience in OSM would suggest that you are correct.

One thing I'm still not entirely clear about with regard to the specific request that led to the creation of this policy is whether it was talking about linking to an external instance of the editor or integrating one in the way iD is - it's important because the things we need to consider are rather different for the two cases.

Not to veer off topic too much (since the ticket is about policy), integration in the same way iD is would be the goal.

mvexel commented 1 year ago

Specifically for Rapid (the integration I originally asked about): in the meantime I spoke with the Rapid team and they're happy to support with the actual integration work needed.

Back on the main topic, I agree that there needs to be some decision criteria for including new editors more generally. Taking a stab at criteria:

This is just a start, but I would suggest to keep it fairly concise and as objective as possible to actually make it possible to come to a decision.

mvexel commented 1 year ago

I spent some time writing up a draft, borrowing from and expanding on the already accepted tile layer inclusion policy.

It would be great to discuss this in an upcoming OWG meeting. In the meantime the doc is open for comments.

matkoniecz commented 1 year ago

How many general-purpose editors exist or could we expect to be built that would be tested against it? The only one existing today that I can think of off the top of my head is Rapid.

Wat about Vespucci appearing for Android users? What about GoMap!! What about some less general mobile editors?

And note that "general-purpose editors" is already defining a policy.

pnorman commented 1 year ago

@Firefishy to send policy out for initial consultation

Zaczero commented 1 year ago

Just came across this ticket. Why do we need such a complicated policy?

Just do:

Only editors that are widely popular, general-purpose, and compliant with OpenStreetMap's data policies may be featured in the edit button dropdown.

This approach is straightforward and effective. Open source is included in this policy since the OpenStreetMap website's GPL license already prohibits otherwise.

Firefishy commented 11 months ago

Published the draft for discussion: https://community.openstreetmap.org/t/proposal-osm-org-editor-inclusion-policy/106589

eneerhut commented 9 months ago

Exciting! Will this be a topic for the next OWG meeting?

pnorman commented 6 months ago

Changes decided on last meeting (May 2nd)

A generic mobile editor entry would require mobile devs to come to an agreement on how this is best done

eneerhut commented 6 months ago

@pnorman if I understand correctly, a new post is going out to propose Rapid Editor as an additional option on openstreetmap.org. The post will be up for community discussion for 4 weeks. Is this correct?

Is this contingent on the changes above being made first?

tordans commented 6 months ago

… to add a generic mobile editor entry A generic mobile editor entry would require mobile devs to come to an agreement on how this is best done

Can someone describe how this will work from a technical point of view? I am not too familiar with this area but AFAIK it will not be possible to just have one mobile edit button and have the apps or iOS decide which one will be opened. AFAIK – at least for iOS – we need one button per editor.

I started this discussion to answer this question for GoMap in https://github.com/bryceco/GoMap/issues/758. There are a few links with more info in that post.

I don't see an issue from this policies point of view, though, to treat mobile editors like any other editor. We can decide to add some mobile editors per operating system. This would require the edit button to be visible for the right operating system only, which is something that can be added to the website code.

bryceco commented 6 months ago

For iOS you can use a generic URI like geo:44.05404,-123.10062?z=18 which will open whatever app happens to be registered for geo: (maybe an editor, maybe a navigation app, etc). Notably, the user isn't provided a list of apps to choose from: the OS chooses for them, so it's incredibly frustrating in general.

Or you can name a specific website that deep-links to an associated app: https://gomaposm.com/edit?center=47.679056,-122.212559&zoom=21 If the app is installed then the deep-link opens the app, and if it isn't installed it opens the website (for Go Map!! it just has a download button).

I'm doubtful there's a mechanism that works equally well for both Android and iOS. IMO if we're special-casing desktop and mobile we might as well special-case desktop, Android and iOS. That way everyone gets the best possible experience.

tomhughes commented 6 months ago

Can someone describe how this will work from a technical point of view? I am not too familiar with this area but AFAIK it will not be possible to just have one mobile edit button and have the apps or iOS decide which one will be opened. AFAIK – at least for iOS – we need one button per editor.

I don't know the technical details but I believe both iOS and Android have a way for apps to register to handle particular URLs or mime types or such so we would just need an agreed scheme they could register for? Certainly I often get Android ask what app I want to use to handle certain things.

Note that we don't really want to use geo: for this as we already have that in the share tab and viewers register for that as well as editors.

pnorman commented 5 months ago

geo: is also a poor choice because we have a bunch of parameters such as OSM ID, etc that we can end up passing.

tordans commented 5 months ago

Given the way iOS works as described in https://github.com/openstreetmap/operations/issues/877#issuecomment-2119116579 I think we should prepare this policy to allow each mobile editor that we agree to add to the website to be a separate entry in the list of mobile editors.

For iOS that will likely be GoMap!!, StreetComplete, EveryDoor. For Android that will likely be Vespucci, StreetComplete, EveryDoor.

The edit URLs will then link to a domain defined by those editors which is where the editors register their corresponding apps and handle the case of when the App is not installed. (This is what some of them do right no now, already.)

Having such a domain which can handle certain variables like osm_id, osm_type or lat, log, zoom to open the editor in a useful way and provides a fallback for when the app is not installed should IMO be a requirement for the editor to be considered.

tomhughes commented 5 months ago

My memory of the ops call is that our intended wording was that we want a single "mobile" entry if that was technically possible so I think that is already covered.

That said I really, really don't want an edit menu that has dozen entries on it...

bryceco commented 5 months ago

we want a single "mobile" entry if that was technically possible

It isn't technically possible to have a single entry for mobile. At least not for iOS.

I really, really don't want an edit menu that has dozen entries on it...

That shouldn't happen if we properly detect the platform and only show relevant editors, and if the policy limits the editors to only the most popular ones. We show multiple desktop editors when the user is on desktop, why wouldn't we show multiple mobile editors on mobile?