[OSM-talk] Improving iD on osm.org (WAS: Remove validation rule asking to add highway=footway to railway/public_transport=platform)

Michael Reichert osm-ml at michreichert.de
Tue May 28 21:50:37 UTC 2019


Am 28.05.19 um 10:32 schrieb Frederik Ramm:
> I think this would definitely be the healthiest and most common-sense
> approach for the community. Letting an unchecked third party forge ahead
> with iD was good in the beginning but now we need some checks and
> balances in place to ensure that what the OSMF brandishes as the
> "default editor" is actually reflecting community consensus.
> It's totally ok if the developers don't want to be bothered with having
> to find out what the community consensus is(*) - this is hard enough
> even for the community itself.
> Perhaps it is possible to have a forked iD that does not work by
> meticulously cherry-picking every new change that is added to iD
> (because that would be too much work), but instead - a bit like the
> mechanisms when building a Debian or Ubunutu package - we could have
> some patches that we routinely apply to iD before it goes live on our site.
> We could use this contentious "tag upgrade" as a test balloon to
> establish the new workflow: iD releases new version -> patch team
> applies existing patches -> community review -> if necessary, new
> patches are made -> patch team releses -> OSMF website deploys.

I am not sure if pure patching (a hard fork) will work on the long term.
Adding a blocking step in the release process might work in the
beginning but after some time the members of the distribution team loose
interest. In difference to projects with a volunteer dominated group of
contributors as OSM Carto, the distribution team will not produce a lot.
In contrast, its task is filtering. This can be torpedoed by the
maintainers of the parent project by code changes requiring a tedious
and boring application of the patches and the user base will ask what
the benefit of the distribution team will be and why we need such a
group at all. I have been active in WeeklyOSM for almost five years now.
I have seen people joining and becoming inactive after some time. I have
observed myself becoming more or less involved (varies a bit over time).
It needs discipline and a large team to get an issue almost every week.

I am pretty sure that there is another way to enable distributors of iD
to build the iD they want. iD could offer a couple of switches in a
central source file to disable or enable certain, controversial or not
always necessary features. (This idea is inspired by build flags for C
programmes but different) This concept might still need the application
of patches to the central file but patching a single file which is
basically a list of variable assignments appears easy to me.

These build flags enable the maintainers to stay to their personal views
on disputed matters but enables local communities more easily to host
their local iD and therefore foresters diversity. If the maintainers add
another feature which is not accepted for www.openstreetmap.org, the
distribution team can still fall back on patching with all its consequences.

Best regards


Per E-Mail kommuniziere ich bevorzugt GPG-verschl├╝sselt. (Mailinglisten
I prefer GPG encryption of emails. (does not apply on mailing lists)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20190528/5738b282/attachment.sig>

More information about the talk mailing list