Hi, 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 Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk
