One changeset per session

[porjo]

Currently a new changeset is created each time I click 'Save'. There should be one changeset per session (lasting up to 30mins after last edit?) with an option to create a new changeset if required.

[tmcw]

Hmm, not sure how doable this is for a browser tool: we need to actually issue the changeset create / add / close commands, so we can't really have a rule like 'commit after 30 minutes of no editing' since the user will simply close their browser before that.

[jfirebaugh]

I've always found Potlatch 2's behavior (open a changeset on first save, append to it with every subsequent save) counterproductive. It leads users, new and old alike, to create monster, continent spanning changesets with unspecific or inaccurate descriptions. So I'm a definite 👎 on this.

[porjo]

I think this is an important question that deserves some consideration as it could potentially mean a fundamental change in the way data is historically referenced in the OSM database.

With users saving often (which they should), the current implementation will shift the changeset away from grouping related changes to making it simply a mechanism for commiting data to OSM.

While I agree that massive changesets spanning large areas is to be discouraged, when done properly the concept of a 'set of changes' is a useful thing which should be preserved.

[DerKarlos]

Only the user is able to decide wether he appends to the same changeset or starts a new one.But he/she needs information about the amount and geographical extension of changes and the time since the set started.Also the comment of the used changesetAfter "save" that button may be replaced to "start new changeset" until the first edit is done. If iD is started again or after a certain time without user activity, a dialog may ask: "continue or new changeset?"-- -karlos-

    Gesendet: Sonntag, 10. Februar 2013 um 18:51 UhrVon: Porjo <notifications@github.com>An: systemed/iD <iD@noreply.github.com>Betreff: Re: [iD] One changeset per session (#703)


    I think this is an important question that deserves some consideration as it could potentially mean a fundamental change in the way data is historically referenced in the OSM database.

With users saving often (which they should) then the changeset will shift away from grouping related changes to simply becoming a mechanism for commiting data to OSM.

While I agree that massive changesets spanning large areas is to be discouraged, when done properly the concept of a 'set of changes' is a useful thing which should be preserved.

          —
          Reply to this email directly or view it on GitHub..

[tmcw]

Okay, so to round up: the objective of having one changeset per session or appending to changesets Potlatch2-style is so that users don't use the 'Save' button after each micro-edit and instead OSM has a 'logical group of edits', like 'all edits in a specific town' together. And the benefit of logically grouped, larger changesets is that they're more convenient to review a user's work or possibly revert it.

Is that accurate?

Would it help to resolve this issue if we documented how often users should save and how they should think of saving the map?

[porjo]

This is one way saving could work:

• user is prompted to save after 5-10mins of activity
• if they ignore the prompt, keep prompting every 10mins or so
• once they save the first time, the changeset is created and it's id stored somewhere internally
• auto-save every 5mins to the changeset, with an unobtrusive 'saved' message
  • set a visual flag to indicate that auto-save is active (modify the save button in some way?)
• users can optionally save at any time using the save button
• the changeset is only closed if the user explicitly asks for it to be, otherwise a changeset is left to auto-expire according to OSM policy (after 1hr of no activity)
  • the exception might be if the user comes back after 30-60min of inactivity and starts editing again, we should prompt them about starting a new changeset.

Something that bugs me about Potlatch is the inability to modify a changeset comment after setting it initially. It'd be great to allow the user to change the comment at any time while the changeset is open. The same window could also display some basic stats on the changeset: number of nodes, ways, bounding size etc

[jfirebaugh]

Strong 👎 on any kind of periodic autosaving behavior. I think it will discourage experimental edits, teach users that they must work in five minute increments, and lead to all kinds of unfinished changes winding up in the database.

[jfirebaugh]

I think we should simply keep the existing save behavior. It has simple, understandable semantics that match up well with iD's target audience of new to intermediate mappers. The only addition I would suggest is an unobtrusive P2-style "you might want to think about saving" reminder.

[porjo]

OK, so autosave = baaad idea.

Regarding the changeset, I take it localStorage would be the preferred way to store the changeset id over the duration of the session?

[tmcw]

Closing: not seeing a clear pattern for changeset-flexible saves that isn't outweighed by UX and documentation problems.

[brycenesbitt]

Perhaps the users pressing "save" are simply looking to checkpoint their work, and simply changing the button name might change behavior.

iD silently auto-saves, but has a big button marked "SAVE" that actually publishes.

Perhaps the button could read something like ("publish 62 saved changes"), merging the current SAVE button and the rather obscure little counter to the right of it.

[daganzdaanda]

Perhaps the button could read something like ("publish 62 saved changes"), merging the current SAVE button and the rather obscure little counter to the right of it.

I like that idea!