Re: [tlug] Linux Format magazine

["Lyle (Hiroshi) Saxon" <ronfaxon@example.com>]

Josh Glover wrote:

>So for a workflow like this, the correct steps should probably be:
>
>1. Create a distributed SCM repository for TLUG projects, which allow
>for semi-public commits (by "semi-public", I mean, password-protected
>with a common TLUG password)
>2. All TLUG members can commit their revisions
>3. At the end, the document owner locks the document so no further
>semi-public commits can occur, then creates the final revision
>  
>

But no matter how automated it becomes, the editor is faced with same 
task of looking through all the suggestions and deciding what to keep, 
what to delete and what to incorporate in edited form.  If the editor is 
good with standard text editors, then there isn't any need for 
automation?  But I haven't worked with this type of automation, so I 
don't know.  Still - the editorial process should be the same.  The day 
the machines are making editorial decisions regarding text is the day 
we've gone brain-dead!

Mind you - I'm not saying this to go against automation, I just want to 
stress that all versions should be readily viewable and changes from any 
one of many contributers should not be made automatically to the master 
file.  Writer-A's file is one thing, Writer-B's file is another.  It's a 
disaster to have them editing each other's work if they're working from 
the same file.  In this automation you mention, does it leave the master 
alone and save each incoming file as a separate file?  Probably so - in 
which case it's not so different from incoming e-mail?  Of course, with 
a large file, changes should be clearly marked so the editor knows 
exactly where the changes are.  I guess this is the good side of the 
automation?  Does it show both the old and new side-by-side, or just the 
new text highlighted, underlined or indicated in some way?

Lyle