Keeping a changeset open

[jgpacker]

This issue will probably be controversial, but I wanted to get it out of my mind.

For understandable reasons, new users tend to make a lot of changesets (and some still do even months later), sometimes with 2-3 minutes of difference between each other. This can be a problem, since AFAIK OSM still has a long way to go on tools that help reviewing changesets, and it can be extremely monotonous.

My suggestion would be to add the following rules to iD:

When submitting a changeset to OSM, look at the last changeset the user made.

If it's still open, and the comment of the last changeset is the exact same as the one being submitted (or both are empty), then send the new changes to the last changeset made.
It would be helpful to hint what happened to the user, to avoid some confusion.

If the last changeset made isn't open (or if no changesets were made before), then submit the changes made as a new changeset, and keep it open.

Perhaps this behavior could be configurable, with these rules as the default.

There rules would have as their only reason to make the number of changesets submitted by new users smaller, and thus make their reviewing easier.
If there are good tools to easily review there changesets, then I think these rules wouldn't be very helpful.

[jfirebaugh]

Previous conversations regarding save behavior happened in #1598 and #703.

This proposal has the advantage over previous suggestions that in cases where there's no existing open changeset, the UI can remain exactly the same as it is now. The user would not need to evaluate whether or not to select an option with potentially unfamiliar terminology ("keep changeset open") at save time.

In the case where there is an open changeset, I suggest the following implementation:

• Below the comment textarea, add a checkbox with the label "Combine with the previous edits (saved x hours ago)", initially checked.
• The comment textarea defaults to the comment from the open changeset.
• If the user changes the comment, the checkbox is automatically unchecked. The assumption being that changing the comment is usually an indication of a logically separate change. If they really want to change the comment of the existing changeset, they can re-check the checkbox.

There rules would have as their only reason to make the number of changesets submitted by new users smaller, and thus make their reviewing easier.

On the flip side, it has the potential to combine edits in different areas, producing changesets with large bboxes, which are also problematic. But I think the above behavior would strike a good balance.

[bhousel]

I feel like since this issue has been proposed, the pendulum has swung back the other way on long-running OSM changesets. From what I understand, current preferred practice is to keep them small and atomic.

Keeping changesets open interferes with:

• Changeset Discussions
• Tools like "who is editing now"
• Realtime QA and vandalism protection

I don't have strong opinions about this, so feel free to reopen if I'm wrong.

[naoliv]

But a lot of small changesets also makes it difficult to review them.
Some new users create 100+ changesets in one day.
It's much easier to review one single changeset (even if it's bigger) than a lot of smaller ones.

[bhousel]

But a lot of small changesets also makes it difficult to review them.
Some new users create 100+ changesets in one day.
It's much easier to review one single changeset (even if it's bigger) than a lot of smaller ones.

That's more of an issue with your review tool.. Besides, if that user made all those edits in a single open changeset, you wouldn't even know about them until the changeset auto-closes a day later. A real problem that reviewers have today is when a user does exactly this and nobody can stop a vandal (read: import) until they have already done considerable damage.

Somebody (I forget who) semi-jokingly proposed that OSM API v0.6.1 should be exactly the same as v0.6, but with changesets that close immediately.

[naoliv]

The problem with open changesets already exists with P2 (but they get automatically closed in 1 or 2 hours). While it's not possible to comment on the changeset while it's open, it's possible to see what has been done and detect possible vandalisms. I still think that it's harder to detect malicious (or even ingenuous but wrong edits) spread among a lot of smaller changesets.

Not related with this issue, but I don't have (nor I know) a good review tool for multiple changesets. I view each changeset with achavi or download the osmchange and review using JOSM. Maybe using a better workflow/tool could change how I view this, of course.