[OSM-talk] How to teach novices about optimal changeset size?

[Imre Samu]

>  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.haxor at 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" <osm at 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 at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk
>> >
>>
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20180117/6f2f31b5/attachment.html>