Topics

Preventing simultaneous revision of wiki page by more than one member #suggestion

 

Our neighborhood/block group has been having group members going into the name/address directory for the block and adding their info, while simultaneously someone else is doing the same thing, and the end result is that both people's changes get wiped out because when they hit save, the other person's info is not yet in the version they're editing. Their info gets in, and then the same thing happens with the next (within the same minute) person's revisions. When you compare revisions, you see, one after the other, people wiping out each other's additions, shown by their being crossed out in the compare.

It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Duane
 

On Sat, Mar 21, 2020 at 11:03 PM, J_Catlady wrote:
It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
Yeah, that's been around for awhile, https://beta.groups.io/g/main/topic/4993391  It even made it to the Trello page about 3 years ago, https://trello.com/c/4MNUkqic/283

Duane

 

J wrote:

When you compare revisions, you see, one after the other, people
wiping out each other's additions, shown by their being crossed out in
the compare.

It would be nice if this could be controlled.
This sounds familiar...
https://beta.groups.io/g/main/topic/4993391

One way to control this might be to use a warning system (soft locking) similar to the "claim" of a moderator to a pending message. The Wiki is a simpler case because there is no email interaction to handle. The first member to Edit a given Wiki page would "claim" it, causing any other member to see a warning banner if he/she also Edits that page.

One thing to consider is whether this should be a hard lock - preventing any other members from editing the page until the first member Saves or Discards his/her edit. The downside of a hard lock is that the page could end up locked indefinitely if there is no way to "break" the first member's claim.

In my own opinion, an "Are you sure?" type of soft lock would be adequate: warning the user of the other edit in progress but still allowing the judgement call to break an apparently "stale" claim.

Our neighborhood/block group has been having group members going into
the name/address directory for the block and adding their info, while
simultaneously someone else is doing the same thing, ...
Instead of locking, I'd actually prefer to control this by way of an automatic merge function; merging in the concurrent edits in the manner of a distributed version control system (DVCS) like Fossil. For use cases like J's (which I think are common) the various member's edits would (most likely) be non-overlapping spans of text, making it possible to automatically merge the changes without conflict.

Of course merge conflicts are a pain to handle; the challenge for implementing this method for the Wiki would be finding a way to signal the presence of a conflict and a means for manual resolution. A typical approach is to include both versions of the conflicting span with some markup to delimit each version of the span. That leaves it possible for someone editing the page later to resolve the conflict by editing that part of the text down to a single "correct" version.

Groups.io could encourage manual resolution of any merge conflict by providing a notification to both of the members involved in the conflicting edits. Maybe also the group moderators.

Shal

 

Duane/Shal,

That's funny. I read the prior thread you posted and see that I was actively involved in it, even though no group of mine was using a wiki then. For me it was all hypothetical at that point. It became very real tonight after asking neighbors to input their info, and some of them went to a lot of effort to do it, and the result was an unholy mess lol.

Maybe it's time to finally do something about this.


On Sat, Mar 21, 2020 at 10:25 PM Duane <txpigeon@...> wrote:
On Sat, Mar 21, 2020 at 11:03 PM, J_Catlady wrote:
It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
Yeah, that's been around for awhile, https://beta.groups.io/g/main/topic/4993391  It even made it to the Trello page about 3 years ago, https://trello.com/c/4MNUkqic/283

Duane


--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Duane
 

On Sun, Mar 22, 2020 at 01:45 AM, J_Catlady wrote:
It became very real tonight after asking neighbors to input their info
It seems to me that a database/table might be a better choice for this situation, depending on how much information is being added.  I did a quick test this morning and it's possible for one person to be editing their row while another is editing theirs and both are fine, no mingling.  The only time there will be a conflict is if a moderator is making a change while the row owner is also editing.  This results in the "last save wins" scenario.

Duane

 

There are many reasons I decided against a database for this. I won't list them here.
So it's not the issue.
Also, we are almost all done getting the bulk of the neighbor info into the list and we ourselves will seldom run into this synchronicity problem again. I do think something needs to be done about this for the sake of other groups and other use cases.
Thanks.

On Sun, Mar 22, 2020 at 6:20 AM Duane <txpigeon@...> wrote:
On Sun, Mar 22, 2020 at 01:45 AM, J_Catlady wrote:
It became very real tonight after asking neighbors to input their info
It seems to me that a database/table might be a better choice for this situation, depending on how much information is being added.  I did a quick test this morning and it's possible for one person to be editing their row while another is editing theirs and both are fine, no mingling.  The only time there will be a conflict is if a moderator is making a change while the row owner is also editing.  This results in the "last save wins" scenario.

Duane


--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Ken Kloeber
 

A HARD lockout, not a warning. Folks/ignorant/inattentive/malicious can and will ignore warnings. And the downside is that it‘s not detrimental to THEM, but to everyone else.

But in addition to it being hard, the lockout should also (like an online banking session) time out (with a huge warning) so that no one user could inadvertently lock the wiki page “forever.”  Wiki edits should also get plunked into a Draft location so that time-outs are saved.



Ken
 
Sent from my phone