In my understanding, this policy should define criteria under which an editor can apply to be shown in the “Edit” menu.
I fully agree that any editor should be removed as soon as it does not comply with the criteria any more. So if at anytime anyone have concerns, that editor must be reviewed.
3 Likes
You can’t separate it, since the policy-thing is driven by Rapid want’s to be shown there and we should not have double standards. We (OSMF and OSM community) should make sure we having the control about which editors we feature.
1 Like
I’m pretty sure the people who like to map with Rapid would also not say “no” to a “Map with Rapid” button on osm.org. Personally I’d love to see a proper editor inclusion policy that goes beyond our “corporates are bad, mkay”-crusade, so we can also feature other editors in the future if we want to.
We can also make a parallel or even integrated “corporates are bad, mkay”-policy, but I have yet to read how read how and why that would result in the disqualification of Rapid from being featured on osm.org.
1 Like
Nobody is saying that, and trying to reduce the argument to that does no-one any favours (including you). As I’ve said elsewhere, OSM has benefited hugely from corporate involvement over the years, and the corporates have too.
However, we have to understand that different organisations have different goals, and “adding good quality data” might not be among them**. I’ve personally bucket-and-shovelled data from a number of corporates, trained their staff for free, etc.
** as opposed to “never mind the quality, feel the width”
3 Likes
I was replying to Simon, who clearly wrote:
So if I understand Simon correctly, we must base our opinion about featuring Rapid on osm.org on our opinion of Meta.
What I would like to know is what any of this has to do with the proposal for an osm.org editor inclusion policy, other than “we are generally suspicious of the corporates”.
1 Like
The whole point of creating the policy is so that we can allow additional editors, for example Rapid, to be included on osm.org in a fashion that doesn’t put the project at risk.
You are saying we should simply take Facebooks word for it, I’m saying that the rules need to be robust enough that we don’t get taken advantage of, regardless of which party wants to have their editor placed in the limelight.
4 Likes
So far I 100% agree with you. I just re-read this draft, and to me it looks decent enough, but it sounds like you also want an extra check in place specifically tailored to editors introduced by large organisations like Meta.
I am not strictly against such an extra check, but I am wondering what it would mean in practice (beyond going after anything the corporates propose with sharpened pitchforks).
I hope you realize how far you are off the deep end here, for example I would take FB over most, if not all non-profits. You just seem to fail to understand that *trust" isn’t a concept you should use in dealing with organisations and it isn’t as if they would rely on it for a second the other way around either.
You still haven’t answered my question of WHAT IN PRACTICE IT IS THAT YOU WANT to ensure we won’t have any issues in the future.
What Simon says makes sense. I think that Casper is deliberately
misunderstanding him. It is obvious that the inclusion of any editor in
the webpage dropdown must be easily revokable as soon as fishy stuff
starts happening.
That fishy stuff doesn’t necessarily have to reflect bad intentions on
the part of the editor maintainers; it could just be different judgement
- for example, the editor maintainers could be of the opinion that they
know better what tags to use and the community is unhappy about newbies
being led towards using certain tags. Or the editor could offer
automatic “fixing” of stuff that runs counter to our automated editing
policy, or automatic “loading” of stuff that runs counter to our import
policies, or the editor maintainers could decide that any edits made
with their editor are uploaded to another (possibly competing) platform
as well. All this could happen with any editor provided by anyone. And
it is of course us who have to judge whether we believe that fishy stuff
is happening. I don’t see how anyone in their right mind can question
this, hence my statement above that I believe Casper is deliberately
trolling here.
3 Likes
To clarify: I am not trolling. My point is that I agree we don’t want “fishy stuff” going on in editors that we feature on osm.org, or any editors for that matter, but I want to know what measures Simon and others would like to see to prevent it from happening, or what we should look out for in terms of fishy stuff, so we can explicitly include it in the editor inclusion policy. So far I’ve just heard a lot of “we shouldn’t blindly trust them” which to me sounds like “did you know that water is wet?”, while I’m actually asking about specific things we can include in the policy to prevent or halt fishy stuff from happening.
3 Likes
I totally agree with Casper that any specific concerns should be clearly stated in the inclusion policy.
Without this clarity, it seems like there’s room to reject or remove proposed editors without having to explain the reasons to the community, which is concerning.
7 Likes
I think it’s fair to say that, for the purposes of this policy, the editors should be reviewed with an eye only toward the editing platform itself, not any biases, assumptions, or spidey-senses community members may or may not have about parent organizations or past organized edits on their behalf. So in that sense, I see talk of Facebook/Meta or any other parent organizations as off-topic for this discussion.
I’m confident that the OSM community is smart enough and active enough to identify if/when changes to a featured editing platform begin inappropriately “corrupting” users’ edits or intentions. I would call that a type of continuous review, not just trust. If that means including some vague “promoting the best interests of the community” requirement to the policy as a get out-of-jail-free card against this purely hypothetical threat, then maybe that’s worth considering.
8 Likes
er… yes? If an organisation wants their software on osm.org, it’s perfectly OK to think about what sort of organisation that is, what are they goals, what is their history, incl. within OSM.
8 Likes
Again I need to point out that I was responding to Proposal - OSM.org Editor Inclusion Policy - #91 by eneerhut which was asking why reviews are necessary. With other words the text already includes those measures that I consider necessary.
I would note though that throughout the whole discussion you seem to be focusing on the default editor setting (aka what is started when you click directly on the “Edit” button), vs everybody else and the policy discussing the contents of the associated dropdown menu (what is displayed when you click the down arrow).
I suspect that nobody really cares about the former, and I would be completely OK with that being free form in the setting so that you could start anything (in practical terms this isn’t so simple and it might need JS plus access at least to the current bounding box).
PS: just making the settings field more configurable would have the advantage that it also avoids the whole onboarding quagmire that adding more options potentially could cause, see Proposal - OSM.org Editor Inclusion Policy - #59 by SimonPoole from December. Which is something that is outside of the scope of the OWG and hasn’t really been discussed afaik by the CWG/board.
How would that look as part of an editor inclusion policy?
Proposal - OSM.org Editor Inclusion Policy states what an editor should fulfill to be added. Additional there were some comments in this thread. An editor should always fulfill those conditions and anyone doubting that, should be able to raise the hand, which should result in a check, which might end in the removal.
1 Like
The same criteria they needed to fulfill to be listed in the first place.
Frederiks point was just about adding, that the editor needs to fulfill the stated criteria always and not only in order to get listed.
1 Like
Which criteria are you referring to here?
I mentioned before, maybe take a look in the first post (initial proposal of the policy) here. 
Though there have been several comments with additional criteria and/or modifications.