On Tue, 29 Dec 2009, Russ Nelson wrote: > > My opinion is probably skewed by using source code repositories but > > imho changes should not be grouped by bboxes, instead they should be > > grouped logically under the changeset whose comment best fits the type > > of change out of those you have open. Grouping by location carries > > very little information, is an easy task that could be done > > automatically and is only slightly better than having no changesets at > > all. > > Rule #1 of HCI: have sensible defaults. If you were just editing > somewhere, and noticed something you missed, and go back and fix it, > it should be in the same changeset, no? So, the default should be
No. Like in sourcecode repositories this is a different action. > "don't close changesets" and "upload using a recent changeset that > covers the same area". Defaults, not fixed policy. The default of JOSM is to take a working session as one session and also upload it as one session with a given description text. Everything else like opening multiple changesets, not closing them and the like are advanced options and not default. This way most users will understand and handle it correctly and they also will be able to give meaningful descriptions. When the software starts to automagically join changes, then you must be very experienced again to use it correctly. Let's assume I'm a little bit advanced user of JOSM - means I understand the idea that changesets are used to group related changes (which is the best we can expect except for some OSM gurus). I change something in area 1 and during these changes I detect other problems. I finish my changes, upload them with a comment and now change the other issue and upload it as well with another comment. For most users this is the best we can hope to reach. Now your suggestion would make this separation worthless, as you would group these unrelated changes into one changeset automagically. Althought Karls work at changeset support gives JOSM a great power I don't think most users will ever use these features. This is ok, as we now have an interface which allows novice and expert users to use it. And JOSM tries to fullfill both needs. JOSM is the only editor supporting power features in many areas, but the defaults must be novice oriented as it is now. Ciao -- http://www.dstoecker.eu/ (PGP key available) _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
