Question

Has anybody considered a more nuanced locking and multiple-editing feature?

The main thing I'd like to see is a strategy that (a) eliminates the hour-long default lock, and (b) does not depend on the editor's explicit release to allow others in.

This, along with a notification feature by topic (CurrentStateOfEmailNotification) would enable more rapid-fire give and take. Also, there are many applications where a lot of people need to contribute in a short period, and the hour's wait, compounded by people forgetting to release imedaitely, woud really impede things. For example, if I send a question to a team of 50 asking for quick responses or opinions on a topic, then most everybody will want to answer within a few hours, or at most a day or so. But human nature (forgetting to release) and simple arithmetic (there aren't 50 hours in a day) practically insures that many, if not most people will be repeatedly locked out when they try to respond, and will get frustrated enough that they won't ever answer.

So, here is a suggestion. Basically, have parameterized locking policies and...

• make locking policy (and parameters) settable by the page author
• in addition to the standard policy (the existing one, say) have this parametrized policy...
• the page is released immediately upon saving, or after a time parameter, typically a small number of minutes to allow reconsideration before someone else gets in.
• when trying to edit a locked page, the user can ask to be placed in the edit queue (the queue could be viewable); this might be the default
• when a page with a queue is released from edit lock, the person at the head of the queue gets an e-mail notification with a link and the privelege to edit the page
• that privelege times out after a settable time, again a small number of minutes, and the next person in the queue is notified that the privelege has passed to them

To deal with people spacing out or getting distracted, see my other suggestion at EditingTimeOut

Make any sense? Is there anything like this implemented or contemplated?

Thanks. -- DavidJLewis - 06 Mar 2004

Environment

-- DavidJLewis - 06 Mar 2004

Answer

This sounds like a good idea, you might want to move it to the Codev web and make it a FeatureBrainstorming topic. This would probably be best implemented as a plugin unless you can interest anyone in the CoreTeam in it.

-- SamHasler - 09 Mar 2004

Such a feature sounds an awful lot like a doc review process. We're looking at implementing such a thing where a REQUEST (aka topic) is routed to reviewers for comment and/or approval. There is a product called CuteFlow http://sourceforge.net/projects/cuteflow/ that handles document routing. We're looking to see how easy it would be to marry this with TWiki as a plugin -- but we're having to fit it in amongst multiple other things.

-- SteveRJones - 10 Mar 2004

Maybe it would be both easier and more flexible to go to a more CVS-like behavior for TWiki: Multiple concurrent or quasi-concurrent edits are allowed, but when someone tries to save changes based on a version that is by now outdated, s/he is sent back to the editor with the other changes merged in to perform a review and possible conflict resolution.

-- LutzPrechelt - 21 Apr 2004

Possibly not ideal for all cases, but there are two simple solutions available now:

• In your TWikiPreferences, Set RELEASEEDITLOCKCHECKBOX = checked="checked"
  • This will have the release edit lock checkbox checked by default. There is a risk of confusion (overwritten revisions) if a user goes back in the browser to make some more changes on an unlocked topic.
• Use the CommentPlugin to gather feedback in a chronological manner

-- PeterThoeny - 22 Apr 2004