It is technically impossible to choose what happens on computer run by someone in such case.
They could have configured their computer so Libre Office Calc is opened on using remote control edit button.
It is not “don’t care”, it is “computers are not working this way”.
(it is possible that I am mistaken)
Technical I agree with you. So, it might be the remote control function can’t comply with the such policy.
Remote control is not an editor. It doesn’t have to comply with the editor inclusion policy.
The difference is you have to install the app first.
Technically this is correct, though I don’t think the understanding of the users is the same. For a normal user currently there are two links in the Edit-menu, one is directing to iD the other one to jOSM (since P3 and Merkartor are more or less just a niche). It’s not obvious that only one of the two links are part of the Editor Inclusion Policy.
I would say that all items should be covered. I see no issues in restricting the evaluation to the editor as supplied or recommended. Someone sufficiently motivated can compile their own version of any desktop editor which, by default, will do something the community believe should not be done. That’s different than the case where an editor, as supplied and recommended, does stuff that shouldn’t be done.
Apologies if I missed it, but I was wondering if there are any updates on the acceptance of the inclusion policy. I didn’t see it discussed in the January minutes.
Same, the new RapiD release has maproulette integration and a lot of other convenient features
It occurs to me that the policy should have a clause that says if anything changes in an already-included editor, the inclusion might be reviewed any time. We wouldn’t want an editor passing the criteria and then launching, to great fanfare, a new facility whereby unsuspecting new mappers are induced to mass-import low-quality building footprints, for example (thereby violating the “discourage mappers from making harmful edits” rule).
Regarding third-party sources readily offered for use in the editor, I wonder if maybe a group different from the editor maintainers - either the community at large, or the OSMF, or its software dispute resolution panel, or someone - should have the last word on which sources are offered. A source readily offered for selection in the editor will always give the impression that this is OK to use, other than a source where someone downloads a shapefile from somewhere and opens that in their editor - in these cases it is clear the the responsibility lies with the user.
Editor reviews
I get the intent, but this opens the door for endless reviews. A well maintained editing tool will get new features and evolve over time. Your proposed wording indicates that any change could trigger a review. It’s not good for anyone if the developers of included editors have to spend half their time responding to reviews.
Can you think of another way to ensure editing tools are meeting the community bar?
Third-party data sources
Wouldn’t it be a net benefit to just make the sources available and let the community decide whether the data is useful? This is what OSM has always done. We do this for the GPS traces that are shown within editors and the imagery layers they use to map with.
If a dataset is bad, it’s in no one’s interest to keep it and have bad data flowing to OSM.
Sure, the “another way” is called trust, and I hope you see the obvious problem with that.
While this is true for GPS tracks (because special case), it isn’t true for imagery layers and other data sources which in general are vetted before being made available to the community at large through editors.
I’d say the inclusion can be reviewed at any time.
It’s not like if every commit to the editors source code will be reviewed by an army of volunteers. It’s not like there’s a mechanism to revoke the inclusion.
But it seems logical to express a possibility of exclusion should the need arise.
Can anyone explain to the community exactly what issues OpenStreetMap has with the Rapid editor?
Providing an organisation with a preferred spot on openstreetmap.org gives them a lot of leverage and access to OSM contributors.
In the specific case the organisation doesn’t have a brilliant track record, has created an OSM competitor and without doubt is urgently looking for an army of serfs to help with that competitor. I would suspect that most people would be wary about providing that organisation with privileged access for free*.
* naturally a 7 digit $ amount could make things a bit easier.
You’re overthinking this. Everyone who’s part of an OSMF WG or some other OSM admin/dev/ops team is perfectly capable and suited to not let OSM get ruined by prominently featuring editors that will break all the data. You described trust as a problem but this level of distrust is much more disruptive.
I still think that it’s perfectly fine to keep iD and JOSM as the two editors that are shown by default, and we can let mappers enable other editors like Rapid or Vespucci in the list under https://www.openstreetmap.org/preferences.
I didn’t mention “breaking the data” at all, maybe you are underthinking this?
Not really. You already explained your position by calling Rapid a “competitor” of iD that wants to recruit “an army of serfs” 
. If you find Rapid so problematic you can just address the problems directly rather than calling it evil and expecting everyone to go along with that rethoric.
You are confusing things massively. Rapid is developed by Facebook, Facebook is
a) the driving force behind Overture.
b) has a long history in OSM of intentionally not playing by the rules (see the disastrous imports in Eygpt.and SE Asia)
c) had previously decided not to engage with the idea of bringing development and deployment of Rapid back in to the OSMF.
d) … lots of other things … that are not relevant to OSM, but which might bias your opinion of the organisation one way or the other.
The discussion is about what conditions should apply to editors that are added to the “Edit” menu, and if they should be subject to review once they had been added. I simply pointed out that the alternative to reviews is trust in the organisation that is developing and deploying it.
Fundamentally I think the whole concept of trust cannot apply to organisations (FB is really not special in that regard) so reviews it must be.
PS: … putting a price against the spot in the editing limelight was naturally tongue in cheek, but serves to illustrate that it is something of value that we need to be careful about.
So what you’re trying to say is you want this topic to be about a Facebook/Meta inclusion policy rather than an inclusion policy for osm.org editors.
I can get behind the idea of keeping Meta at arm’s length while they’re behaving like suspicious corporate pricks with ulterior motives, but if you want that, then make that the policy rather than focusing on Rapid and other osm.org editors.