I'm tending toward wanting implicit locking at all times - if someone is working on the file, that fact should be evident to everyone else and no one else should be able to edit the file until it's checked back in. But here's an idea: what if GroupEdit had its own simple chat mechanism, with each document having its own permanent chat space. It would be real-time for anyone who was connected, but the entire history of the chat would be stored permanently with the document and would be viewable by anyone. And with iChat-like time and date stamping of message, it could also serve as a constantly updated blog for the document.

REF: Item 8. In any document creation/revision situation, discrepencies force the involvement of a human editor with intimate knowledge of the subject (best to be the author). Forcing revisions in a simple check-out/check-in in a serial fashion is exactly like the issues of record level and field level locking in a database. I think you must use a serial editing process with check in/out - or you create a nightmare for an editor, reconciling more than one version. It may be possible for the server software to combine multiple documents into one, highlighting revisions by different authors in a unique color. Plus, I'm not sure what "modifiable set of rules" you want for the reconciliation of offline and "live copies." I gues that one such rule would be to force the serial check in/out and revision, which is certainly possible with a limited number of writers, editors, approvers.

Discrepencies are a can of worms. Serial check in/out and editing is best. See my long post in general comments.

I agree with the comment below: separation of form and content is the key to making this work. Writers shouldn't have to think about how the text will look.

Instead, the client program should display a list of block or paragraph tags, each of which has been defined by the editor.

E.g. "Body", "Sub-heading", "Boxout", "Photo" (which would simply display a filename in the client program), "Photo Caption", etc.

The writer would pick from the list. He would not be permitted to add a tag directly, but a mechanism could be put in place to allow him to request or suggest a new tag. (The server could even CC the request to an Art Editor or some such.)

Couldn't 'iterative passes' be accomplished with the version mechanism by simply saving the document to a new version after each (editorial) pass?

Saw someone on TUAW mention subethaedit. I took a look at it. Looks like a really nice app, and almost even close to what GroupEdit could be. From what I can tell it doesn't track or version, and is more real time lots of people typing at once, but it does incorporate multiple inputs (writers, editors), and can track who did what.

Expanding on the iChat thing, not sure if this would lead to feature bloat (the avoidance of which should probably also constitute a feature request), but maybe there could be two ways of using the chat interface - document level chat as well as specific point in a document chat. So, there may be one contentious paragraph that many authors may wish to chime in on. There could then be a chat area set up around this paragraph, or word, or even punctuation mark. Again, it would be obvious via an icon where there was a chat.

I think that some kind of visual representation is important. It can be easy to specify that something should be tagged as Heading2, but sometimes it may be important to see that "oh that is THAT level heading...perhaps level 3 is better".
I would like to see an editor (or art director editor) have the permissions to assign a style sheet to a given document. The author can then choose to work in the unstyled view, or the marked up view. Being able to see invisibles is also very important. And also maybe document-level things such as "allow double spaces after fullstops" (yep, I am Australilan;-) or disallow same, for instance. Again, specified by the editor.

Journalling is really a filesystem or database technology.

GE should support rollback without network access (like Subversion), and safe writes (to a temporary file, which only replaces the previous version after changes are complete) like many other programs.

Given your requirements for network access, versioning, and usability without a network, I think Subversion provides much of the back-end infrastructure for GE. Do you see aspects of GE that don't map well to the Subversion model, or is it just a lack of clients? If the latter, it might be time to look into extending SubEthaEdit (or TextMate). Alternatively, now might be a good time to influence the development of ZigVersion.

http://zigversion.com/

The back-end requirements seem extreme for a clean-sheet approach -- you'd need to recreate at least half of Subversion, which is a very large and serious project with lots of sophisticated talent -- so hopefully you can leverage an existing framework.

And apply one individual change, or a range of changes, using the GUI.

Something I just discovered I really want as a reviewer: GE should offer options to compare against the current version ("HEAD") or the previous ("PREV"), or an arbitrary version, or the latest change/approval by a given author/reviewer.

So I could catch up on all the changes to a document since I last reviewed it, or since another trusted editor did so. Going back through the change history to figure out what version to compare against is awkward and inefficient. Matters more across sets of files than individual documents...

I would define a minimum of 4 levels of access:
Site admin - control of all projects and site settings
Project admin - control of a specific project
Project contributor - read/write on a project
Project visitor - read-only

You should be 8-) I would think about project style permissions where a project can be an article or a group of articles (i.e. an issue). Then you could define different access at each level.

I think it is significantly easier to code for security in advance than to try and hack it in later, so you should at least define some access levels.

I'm starting to agree with Chris that what you might be looking for is a better front-end to Subversion. I've only started touching on Subversion, but I know it has WebDAV support. I just hate WebDAV so I've never played with that functionality.

Your word workflow presumes one person editing at any one time and other user's "locked out" because you have the latest file. However your offline mode presumes you'll be able to just open a file and work on it -- but so will other people that have a copy of the tree with them.

For a true offline mode, track changes will have to be able to track simultaneous changes and do conflict resolution too (or at least warn that conflict resolution needs to take place...)