On Fri, 1 Oct 2004 06:36:38 -0500, Randy Becker lemnar@gmail.com wrote:
This is part of the reason I'm swaying away from the current course I've taken, and towards a cleaner approach, but I will bring up the "stable time" to see if it's an acceptable solution. Also, part of the problem with this is how does it reach a stable point, as *all* evidence of an edit by a user should not be evident from the wiki, except to sysops or the like. (editing should display the previously approved entry, and only approved entries should appear in the history etc.) Because of all of this, I'm thinking of trying to implement a kind of queue of edits, which would bee looked at, and then approved or rejected, and if rejected, just dropped, if approved, added as if the user which submitted them had added them themselves.
The only drawback to this kind of "invisible queue" is that you might get the same edit submitted multiple times, because it hadn't been approved yet. Also (and potentially even more annoying) you might get edits that cause edit conflicts even though they happened hours apart, e.g.: Current text: "This s a senntence" Alice edits this to: "This is a senntence" Later, Bob edits it to: "This s a sentence" Carol the admin pops these from the approval queue, and the software goes "whoops". No different from a current edit conflict, but potentially a lot more common.
The only way I see round this is to only make the queued edits *partially* invisible: a user asking to edit the page sees a message saying "the following edits have already been submitted for approval" with either a whole load of diffs, or a set of links to diffs (labelled with the edit summary, perhaps). Then they can choose to build on one of those to create their own version.