The SDRP was founded on the idea that it would be up to the software devs to cooperate (or not) with the SDRP, and this would not impact OSMF decisions. Foundation members might have voiced different opinions when the SDRP was proposed if they knew this was not going to be the case.
I strongly feel that it should be up to the foundation members, not the OWG, to decide if this panel that was created with voluntary cooperation and no influence on OSMF decisions in mind, is also competent to have a say in if an editor is in compliance with the OSM.org editor inclusion policy.
Certainly it would be terrible if an editor built into osm.org would surreptitiously help build up a competing database that doesnât share the same spirit of openness. Ironically, the mechanism youâre describing is technically how Public Domain Map works in the context of the Tasking Manager, though thereâs nothing particularly sinister about what theyâre doing. (As far as I know, they arenât seeking placement on the main site.)
I wonder if your formulation would also preclude a hypothetical âtransfer this abandoned railway to OpenHistoricalMap for safekeepingâ shortcut that mappers keep clamoring for. Presuming that the legalities are resolved beforehand, consent and transparency would be critical to the legitimacy of any such feature, whether or not the editor is built into osm.org.
I like this in principle, but I think something like âmarking a task as completeâ should be OK if implemented transparently. That way software could provide e.g. shared to-do list functionality where the todo list data is stored externally. So âchanges to map dataâ rather than just âchanges to dataâ needs to be solely in OSM.
As an aside I would love to see Potlatch running in browser on OpenStreetMap.org again if compiling to WebAssembly or an embedded emulator becomes viable.
I think any proposed editor should be appropriate for a general audience. However, we should also be open to allowing special-purpose editors to be included in OSM.org if it makes sense. This is particularly true if the special purpose editor might belong somewhere else in the UX outside the âEditâ pulldown.
How about: The editor must pull all data from OSM (like no AI generated stuff and other imports) and push all data to OSM. With explicit user consent the editor can additionally push data under OSM-Licence to other services. It will make sure that all data gets transmitted to OSM and allow additional publishing to others.
So the editor must always push all changes back to the OSM-DB (in your case of abandoned railways no changes, nothing to push) and if the user agrees it would be ok to push the data to a third party (in your case the user could agree, that he wants to push that data under ODbL to OHM). Afterwards the railway could be deleted and this change will be pushed to OSM.
Could this be considered a rule that blocks built in tasking managers or (vector) cadastral layers for alignment? The UK Cadastral layer is currently a raster, but it is essentially data from another source.
The editor must pull all data from OSM (like no AI generated stuff and other imports)
We shouldnât invent requirements that go against how OSM works. Using other data is an established part of OSM practice, assisting our work. The key requirement is that humans are editing, and datasets are documented.
OSM has pretty strict policies regarding imports and automated edits. In my opinion a OSMF-featured editor should not contradict those policies by easily allowing imports or automated edits. Additional I would assume a higher workload for DWG.
But as added in my second post, I could accept as well âOSMF/DWG approved sourcesâ as a condition.
I thought the policy should be discussed in general terms and not with having a specific editor in mind. If thatâs not the case, the policy should clearly state " RapId Inclusion Policy"
But thats not @Friendly_Ghost point. He stated that the SDRP was established under the condition, that its existence will not effect any OSMF-decision. I donât know whether thatâs the case, but I would assume there will be a MoM and this can be simply checked. Now this policy requires the membership in the SDRP in order to get added to the Edit-dropdown, which will be decided by OWG. Based on this policy the existence of the SDRP will effect OSMF-decissions.
Either this policy only suggests the membership in the SDRP or SDRP needs to get approved to effect OSMF-decissions.
Iâm also quite uncomfortable with the requirement to participate in the Software Dispute Resolution Panel (SDRP).
For one thing, the SDRP is completely unproven. If the group had built trust and respect with the community through years of effective work in handling iD disputes, I might be more open to an initiative to expand its scope. Thatâs not even remotely the case, though. Maybe @Minh_Nguyen can correct me on this, but to the best of my knowledge, the SDRP has never actually resolved a dispute for its entire existence.
And on a more principled matter, I do believe the OSMF should honor the commitment made as part of the creation of the SDRP that participation would be voluntary, and that not opting in wouldnât be held against a software development team as part of OSMF decision making processes. (âOpting into cooperation with the Panel is voluntary and will not, for example, factor into OSMF decisions related to funding.â)
OT: Excluding the OSMF from requiring whatever it wants from applicants that want funding from it is patently silly.
Back on topic:
Iâm not convinced that adding a further body that could potentially be involved in removing an entry for an app that is unwanted does anything more than provide well resourced players with more opportunities to game the system.
In the end the discussion boils down to: do we want a policy that creates an explicit right to an entry or do we want a policy that lays out some minimum requirements for being eligible, but outside of that the OSMF is free to do whatever it wants? Iâm obviously in the later camp.
Back to re-iterating what Iâve pointed out multiple times: messing around with the menu/button can have, depending on how it is implemented a massive impact on the newbie to engaged mapper funnel.
~80% of all new mappers start off by editing by clicking on the edit button, but more importantly > 90% of all mappers that stay on to make any kind of larger number of edits originate there (thatâs ignoring the special case of mappers that start off with JOSM which would need more investigation). If we are providing more options we need to put some thought in to how we steer new mappers to which options, and how we measure the effects. The current only non-iD option,âremote controlâ has had a natural barrier to being used, so canât really be used to deduce anything about what might happen.
Correct, the SDRP has never heard a case. Depending on how you look at it, that could mean the developers skillfully avoided conflict with the community, or community members resolved disputes before they escalated to the panel, or the developers havenât had to make any hard decisions during these last few years, or people stopped caring as much. But it does leave me empty-handed as to the accomplishments of the panel I sat on. (A wiser functionary wouldâve stoked some controversy every now and then, to prove how essential they are. )
Out of curiosity, do we have any statistics on how many used Potlatch 2 back when it occupied the second spot on that menu? It wasnât so long ago.
)