Topics

moderated Merge concurrent edits to Wiki pages #suggestion


 

Mark,

I'm sure you'll know immediately what I mean. But I'll detail it anyway in case I've got a detail wrong.

In the wiki (and presumably message edits, and any other place where edits have a revision history) when two (or more) users concurrently open an edit on the same revision then the behavior is "last save wins".

Which means that the other person's edit is lost. Well, not lost exactly, as it is in the revision history, but it doesn't appear in the resulting revision and so is "lost" from the point of view of members simply reading the page.

So, for example:
-----
1) Alice creates or revises a page.
2) Bob begins an edit to the page.
3) Carol begins an edit to the same page.

Carol's edit is working with Alice's text because Bob's changes haven't been saved yet.

4) Carol saves her edit.

The wiki page now shows Carol's revision.

5) Bob completes and saves his edit.

The wiki page now shows Bob's revision. Carol's changes are "lost" --
buried in the revision history, but not incorporated into the resulting page.

In that scenario, had Bob saved first then his changes would be "lost" instead of Carols.
-----

The behavior I would prefer is for the system to automatically merge Bob and Carol's concurrent edits, so that the resulting page incorporates both their work. This behavior would be familiar to people who've used revision control systems designed for concurrent and/or distributed usage. (CVS, GIT, Fossil, etc.)

Automatic merging is tremendously effective for "non-conflicting" edits. Usually this means edits that are separated by one or more lines (or some other easily recognized span) of unchanged text. In an HTML wiki that might be a paragraph rather than a line.

For conflicting edits, "not so much". Usually the first person to save is fine and the second person's attempt to save is blocked by a conflict warning. The second person then must reconcile the conflict before he/she can save his revision.

The key usability difficulty is in how the conflict reconciliation is handled. The examples I'm familiar with are all based on local edits to files, so a marker is dropped into the file at the point of each conflict and the user is left to edit the file and remove the marker. Something like that could be done here (where the Save action by the second person results in a new edit box, containing both Bob's and Carol's changes, with the conflict(s) marked somehow.


There have also been systems with totally different approaches to concurrancy, including some which show everyone's changes live to everyone. In those cases the edit window may be changing to show you other people's typing concurrent with your own. I've only rarely used such a system. It sounds cool, and it is fun to play with, but I'm not convinced it would be a good choice here, even if it were practical to implement.

--
Shal
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


Ro
 

What about simply allowing only one edit to take place at a time??


Ro

with Silk gazing over the fence, and Sally, Handy, Feliz &  Police Kitty patrolling in the Great Beyond.





From: beta@groups.io <beta@groups.io> on behalf of Shal Farley <shals2nd@...>
Sent: Saturday, April 29, 2017 12:50 PM
To: beta@groups.io
Subject: [beta] Merge concurrent edits to Wiki pages #suggestion #wiki
 
Mark,

I'm sure you'll know immediately what I mean. But I'll detail it anyway
in case I've got a detail wrong.

In the wiki (and presumably message edits, and any other place where
edits have a revision history) when two (or more) users concurrently
open an edit on the same revision then the behavior is "last save wins".

Which means that the other person's edit is lost. Well, not lost
exactly, as it is in the revision history, but it doesn't appear in the
resulting revision and so is "lost" from the point of view of members
simply reading the page.

So, for example:
-----
1) Alice creates or revises a page.
2) Bob begins an edit to the page.
3) Carol begins an edit to the same page.

Carol's edit is working with Alice's text because Bob's changes haven't
been saved yet.

4) Carol saves her edit.

The wiki page now shows Carol's revision.

5) Bob completes and saves his edit.

The wiki page now shows Bob's revision. Carol's changes are "lost" --
buried in the revision history, but not incorporated into the resulting
page.

In that scenario, had Bob saved first then his changes would be "lost"
instead of Carols.
-----

The behavior I would prefer is for the system to automatically merge Bob
and Carol's concurrent edits, so that the resulting page incorporates
both their work. This behavior would be familiar to people who've used
revision control systems designed for concurrent and/or distributed
usage. (CVS, GIT, Fossil, etc.)

Automatic merging is tremendously effective for "non-conflicting" edits.
Usually this means edits that are separated by one or more lines (or
some other easily recognized span) of unchanged text. In an HTML wiki
that might be a paragraph rather than a line.

For conflicting edits, "not so much". Usually the first person to save
is fine and the second person's attempt to save is blocked by a conflict
warning. The second person then must reconcile the conflict before
he/she can save his revision.

The key usability difficulty is in how the conflict reconciliation is
handled. The examples I'm familiar with are all based on local edits to
files, so a marker is dropped into the file at the point of each
conflict and the user is left to edit the file and remove the marker.
Something like that could be done here (where the Save action by the
second person results in a new edit box, containing both Bob's and
Carol's changes, with the conflict(s) marked somehow.


There have also been systems with totally different approaches to
concurrancy, including some which show everyone's changes live to
everyone. In those cases the edit window may be changing to show you
other people's typing concurrent with your own. I've only rarely used
such a system. It sounds cool, and it is fun to play with, but I'm not
convinced it would be a good choice here, even if it were practical to
implement.

--
Shal
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum





 

Ro,

What about simply allowing only one edit to take place at a time??
That's an approach.

The usual difficulty with it is that Bob might walk away from his keyboard for an indefinite period and effectively lock out everyone else for a long time or forever.

To prevent that then one also needs a timeout on edit sessions - and that's not a good user experience if you're thinking about your carefully crafted wording when the timer goes off. Does your edit in progress cancel or auto-save? Either way it is disruptive.

It is also not a good user experience for Carol - who is told to come back later. For many users that kind of site behavior is unacceptable and they don't come back.

Shal
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


 

From my point of view, time-outs are better than simply letting multiple editors work on a document that is constantly shifting beneath them and step all over each other. I've always been the sole editor on a document, at least for the period of time I'm working on it, and then I hand it over to the next person. I believe in serial monogamy of editing. ;)
--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

This has been implemented in the pending queue here, right? One mod at a time "claims" a pending message. Without that there would be chaos. But I've already said my piece (or is that peace?;) about this in the context of the Help mockup in GMF, and will bow out of this discussion now. 
--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

J,

This has been implemented in the pending queue here, right? One mod
at a time "claims" a pending message.
That's not a bad idea.

The wiki pages already show a last edited date/time and count of revisions in the upper right corner. Perhaps that could be altered in some way to indicate that there's an edit in progress.

Also like the "claim" in the pending queue that note can be purely advisory - it would not actually prevent another user from opening an edit. In that way the problems with lockouts and timeouts would be avoided.

( or is that peace? ;)
Yes, as in the traditional wedding invocation, "Speak now or forever hold your peace".

Shal


 

Shal,

Well, now that some of this is addressed to me, I'm back in.;)

All was copacetic until I get to the part that read "that note can be purely advisory." NO!!! That defeats the whole purpose! I had no idea the claim in the pending queue was advisory. No WONDER sometimes a draft appears in multiple in the drafts folder. I just emailed Mark a bug report about that last night. I think these claims should be real and binding.

And I was thinking "piece" as in "I've said my bit." ;)
--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

J,

I wrote,
Also like the "claim" in the pending queue that note can be purely
advisory - it would not actually prevent another user from opening an
edit. In that way the problems with lockouts and timeouts would be
avoided.
Of course when that happens, one still needs a means of conflict resolution. I'd prefer something better than "last save wins".

But that does bring to mind another way to mitigate the damage in a "last save wins" situation: Have that last edit/revision count in the upper right of the wiki page indicate that a concurrent edit is open or has occurred. That could give Carol some warning, after she saves, that her changes may be "lost" (if she notices the indication). And Bob some notice that he may have discarded someones changes.

Better still, create a notification email to both Bob and Carol when this happens. Maybe Alice and maybe the group moderators as well. That should fit within the framework of the long-awaited notification overhaul (nudge nudge, wink wink).

But in the end, these are all just ways of alerting humans to do what automation could have done for them (in most cases). I'd prefer to let the automation handle what it can, and reserve the notifications for the merge conflict case.

Shal
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


 

On Sat, Apr 29, 2017 at 01:53 pm, Shal Farley wrote:
Of course when that happens, one still needs a means of conflict resolution. I'd prefer something better than "last save wins".

I'd prefer no conflict in the first place. You couldn't pay me enough money to edit a document that, literally, is changing as I edit it.

And now, I'm out of here. ;)
--
J

Messages are the sole opinion of the author. Especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


 

J,

I've always been the sole editor on a document, at least for the
period of time I'm working on it, and then I hand it over to the next
person. I believe in serial monogamy of editing. ;)
That approach can be practical when you're dealing with a very limited workgroup. But it breaks down rapidly in the face of a larger team or community effort; because of those lockout and timeout issues.

However, I did make an error in my description.

At the point where Bob attempts to save his edits, the save would not occur and he would be given his edit box back, with the changes from Carol merged into it, regardless of whether conflicts occurred. This gives Bob the ability to proofread the merged text and manually resolve conflicts before saving. If there had been merge conflicts in the first save attempt he would be required to remove the conflict markers before his second attempt to save would be accepted.

Shal
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum


 

J,

I think these claims should be real and binding.
You still need a way to unlock the claim in the event circumstances prevent the person who made the claim from completing their action.

In the case of the Pending queue, the unlock mechanism is to simply take the action anyway. Nothing more formal is required (everyone with access to the queue is a moderator, and would have access to the unlock mechanism anyway - absent some new moderator permission).

In the case of a wiki page edit you might make the case that the claims should be binding against members, with only moderators having the power to discard someone's claim and allow another to edit the page. But to me even that requires too much manual intervention, and intervention by a scarce resource (moderator) no less.

I (as moderator) don't need the hassle of dealing with some member who chooses to squat on a bunch of claims, and the complaints from other members. Or, worse, the other members simply giving up and not contributing.

With the merge mechanism the squatter is deterred by the fact that they end up having to do work (resolve conflicts) in order to complete their save (and no harm done if they never do).

In the current mechanism the squatter is rewarded by the fact that their later save obliterates everyone else's work and puts back the version the squatter liked. It effectively gives any member easy veto power on changes to any wiki page. This is not a good thing for a community effort.

Shal
https://groups.io/g/Group_Help
https://groups.io/g/GroupManagersForum