> one changeset per building, repeated 20 times my typical use case: House numbering on the street: push the numbers & forget & go to the next house ( fast feedback loop vs. Delayed gratification ) - sometimes the mobil app is crashing, and I don't want to go back 100m to re-enter - the last 5-10 numbers
> Obviously this makes them PITA to review quickly in Achavi or whatever tool you use. imho: it is easier to group the changeset on the reviewer side : by user + by hour ( group by user, hour ) than change the community. Imre 2018-01-17 15:13 GMT+01:00 Michał Brzozowski <www.ha...@gmail.com>: > Certainly not: > - one changeset per building, repeated 20 times > - one changeset for 3 POIs that are 1000 km apart in different countries > > These are real world examples. In the latter Achavi can often refuse to > run. > > That's also why I asked ;-) It's not that easy to formulate the answer > what is reasonable to include in a changeset. > > Michał > > 17.01.2018 2:54 PM "Tobias Zwick" <o...@westnordost.de> napisał(a): > >> So, what is the optimal changeset size, and why? >> >> Tobias >> >> On 17/01/2018 14:26, Michał Brzozowski wrote: >> > Many new users have a habit of e.g. sending one or few objects per >> > changeset, resulting in a dozen or even more changesets per day. >> > Obviously this makes them PITA to review quickly in Achavi or whatever >> > tool you use. >> > >> > This habit is probably caused by non-knowledge of how auto-save works in >> > iD (which makes the work reasonably secure), as well as just not knowing >> > better thus forming their own judgement. >> > >> > How should we teach about optimal changeset size? This is quite tricky - >> > how we would define it? >> > >> > Can the iD nudge users towards better practice? (Linking to Good >> > changeset comments wiki page would be useful as well) >> > >> > Michał >> > >> > >> > _______________________________________________ >> > talk mailing list >> > talk@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk >> > >> >> >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk