Do we need the editor on the web page to be the latest and greatest? I think a basic editor that allows you to add lines ie highways etc. POIs with tags should meet 95% of a casual mapper's needs if not more.
A trimmed down stable version of iD should meet these requirements. I think the first task is to determine what the requirements are for casual mapping from the web page. My thoughts are it is there as an introductory tool and as such a complex editor may well overwhelm a new mapper. There are other tools available for more complex mapping. Cheerio John On Tue, May 28, 2019, 5:53 PM Michael Reichert, <osm...@michreichert.de> wrote: > 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) > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
