Hi Micah,
I think you came up with a good answer to your conundrum in an earlier
post in this thread: Don't explain what an optimal changeset IS, explain
what it is NOT:
Something like:
"It helps other contributors understand your edits if you group what you
are doing in a local area into one changeset. For example, if you are
creating the outlines of 20 buildings, group them into one changeset. On
the other hand, if you are adding 3 POIs, (points of interest), that
are 1000 km apart in different countries, then it is more useful to put
them into 3 changesets. Of course, if you are creating the outlines of
1,000 buildings in your town, you do not have to do them all at once!
If you worried about losing your data, our data editor software allows
you to make incremental saves to the OSM server as you go along. iD does
this automatically. Potlatch and JOSM have buttons that allow you to
save partial work into a changeset and then keep adding to it until you
are done."
[This could probably be improved for readability by non-native English
speakers. And the editor text should be fact checked, I am a die-hard
Potlatch user.]
Mike
(first post for a long, long time)
On 1/17/18 4:13 PM, Micah Brzozowski wrote:
Certainly I am not intending to change the community and require every
mapper to comply. If you're an experienced mapper, you're fine.
I mean new users, who are not yet integrated with the community. Their
work should be checked thoroughly (in Achavi, osmcha...). All novices
make mistakes, after all. Better to give them good habits. By
extension, smaller number of changeset will lead to less recycling of
same changeset comments.
I made this thread because I found it difficult to convey what is best
practice in short form in changeset comments.
Maybe I should simplify things when explaining to them? No need to
tell all the conventions, just what is a good start - but hoping it
won't backfire ;)
17.01.2018 3:35 PM "Imre Samu" <pella.s...@gmail.com
<mailto:pella.s...@gmail.com>> napisał(a):
> 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
<mailto: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
<mailto: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 <mailto:talk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk
<https://lists.openstreetmap.org/listinfo/talk>
>
_______________________________________________
talk mailing list
talk@openstreetmap.org <mailto:talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk
<https://lists.openstreetmap.org/listinfo/talk>
_______________________________________________
talk mailing list
talk@openstreetmap.org <mailto:talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk
<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
