[Osmf-talk] Toward resolution of controversies related to iD

[Frederik Ramm]

Hi,

here's my comments on the document.

> iD is the simple, friendly, default web editor for OpenStreetMap, centrally important software for the project. 

True, but not set in stone; it is possible that a different editor
becomes the default editor in the future. It could make sense to think
about what a "challenger" would have to deliver and who would decide
whether to switch, and on what basis!

I think that most of what follows is, while *especially* important for
the editor we crown as the "default" on our web site, also important for
other editors, doubly so if they are not someone's niche hobby project
but furnished with enough capital-backed PR power that they become
widely adopted.

> While there have certainly been times when major and minor decisions in iD have triggered conflict, the vast majority of development discussions are non-polarizing and productive.

True. iD is, insofar as I can judge, well engineered and tremendously
useful.

> OSMF will establish an appeal process

Basically, this process already exists and is as follows: People who are
unhappy with what the default editor does, and who are not heard by the
developers, can complain to the board and the board can then, if they
agree with the complaint and are not heard by the developers either,
choose to have a different version of the editor (either an earlier
release that did not have the unwanted features, or a branch
cherry-picked by the community) rolled out on the web site.

Of course, this is a variant of the default appeal process that
essentially puts the board as the last resort. "Outsourcing" this to a
group can work, however the group must consist of very diligent and
experienced OSM community members. We have to keep in mind that as
things currently are, iD development is corporate-driven and hence
decisions made by the iD team can draw on plenty resources to "make
their case" before an arbitration committee, whereas the complainants
who can come from all parts of OSM might find it harder to make a
compelling case with a common voice. This must mot be allowed to result
in a skewed arbitration process.

> OSMF will support development of better systems for tagging decisions; iD documents status quo and separation of concerns

As Simon Poole said earlier, if the iD editor had a way for people to
load tagging presets from some kind of repository or from remote web
sites, then many problems would be solved. The default setting on the
OSM web site would only load a smaller set of well-established presets,
and additional presets could be loaded by users. This would also have to
apply to validation rules and things like the "name suggestion index",
the latter seeming to be somewhat of a grab-bag of what random people
have suggested to add!

The iD developers could then concentrate on building the infrastructure
needed to execute tag presets and validation rules, and third parties
could build their preferred toolboxes. These third parties would then
have to convince the OSM users to use their presets, instead of (as it
is now) having to convince the iD maintainers to include them.

I think that the question of "developing a better system for tagging
decisions" is out of scope here. It is something that can be looked
into, but the problems we had with iD are not down to a lack of good
tagging documentation, they are down to a lack of communication skills
(or willingness).

> Institute quarterly planning meetings, and publish bi-weekly sync time and notes

I am not super fond of meetings but if others like the idea, why not.
Personally, I would find it a great step forward if new iD releases were
to run through a community review phase before they go live on the web
site. I.e. announce the new release with a list of features etc. as it
is done now, but have it up somewhere for testing for like 4 weeks
before it goes live on the web site (or, if significant problems are
identified, perhaps hold it and re-think).

> iD can improve clarity on decision making and communication

It is probably quite common among projects the size of iD to have no
clarity on that. With iD we have the unusual situation (compared to
other core OSM software projects) that development is corporate-driven;
it is not a hobby project but we have Mapbox respectively Apple footing
the bill for full-time development work. It is therefore harder for an
up-and-coming hobbyist to participate in development on a level
comparable to salaried developers. (And I am *not* saying that other OSM
projects have an abundance of developers - the OSM web site, Nominatim,
osm2pgsql, or the OSM carto style would certainly all welcome someone to
do some work, not even mentioning stuff like renderd and mod_tile which
is central to today's tile serving and is essentially unmaintained. But
once in a blue moon these projects do attract new people.)

I would welcome clarity on the part of the iD team about who "we" are
(the "we" that explains the rules in CONTRIBUTING.md) and how to become
part of that "we". At what point does one rise from an annoying
supplicant whose pull requests have to be rejected to someone who is
part of the team? And how would the companies paying for development
react if other people where to start calling the shots?

This is, as I said, a bit hypothetical as we suffer from an acute lack
of interested developers, and I wouldn't ask for a huge documented
engagement process with multiple levels of contributors and all - but as
one of the most user-facing parts of OSM where you can actually have an
impact, iD would not be the least attractive project for people to start
contributing to. So if the CONTRIBUTING.md could be expanded a bit to
list not only the technical parts of how to submit a pull request, but
also who the team is, how it runs, and so on, that would be great.

> Document how Code of Conduct is handled

The Code of Conduct is a joke and has been breached multiple times, with
impunity, by at least one of the maintainers in the past. I am not one
of those people who think everything needs a code of conduct, but adding
one to your project and then thinking it is only valid for *other*
people is certainly not the way. I suggest to get rid of it.

After going through your points, I have one of my own which fits partly
within this iD topic but may also be a bit broader:

All OSM editors must strictly adhere to existing and documented
policies, and take appropriate steps to ensure users do that too.

What I mean by this is that we have three important policies on data entry:

* automated edits
* imports
* organised editing

iD has in the past - for a very short time I believe as this was quickly
fixed - tempted its users to make large automated edits without looking
at details (via some validation rules combined with the offer to "fix
automatically").

Periodically there have been efforts to "make it easier" to load
external data sets into iD and upload them to OSM which can result in an
import in disguise. Of course, the "Rapid" variant of the iD editor does
this with low-quality AI-generated data, running it through a fig-leaf
"user verification" that is often handled with the same diligence as a
"I have read and agree to these terms" dialog box. And pushing out a new
release of an editor saying "hey we've now added support for $DATASET
and you can easily see which bits have already been loaded into OSM and
which still need work" is a way of starting an organised editing campagin.

*All* editors, not just iD, must respect these guidelines and be held to
the highest standards in this regard (if your editor has a function
clearly designed to upload stuff from an external shapefile in an
automated fashion but doesn't tell users that such an import needs prior
discussion, then the editor writer who knows better is at fault and
cannot say "why, it's not my fault if the user abuses this harmless
feature...").

In the medium term, I would like to see us create a list of "approved
editor software", where the "approved" status depends on upholding these
values (and probably on participating in the arbitration process you
mentioned earlier), and can be lost if what the software does goes
against what the community wants. In the long run, I would like to
disallow editing that does not come from an approved editor.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"