revision strategies [was RE: [Moderator Action] Re: Progress on SVG book]

 
Jeff wrote:

I don't necessarily think the book should be stuffed into a CMS (like
Drupal), I think raw HTML+CSS+SVG is just fine.  However, if it was
put into a version control system like Subversion, people could
download it from the repository, edit the document and then send you
patches.  You (or others you delegate) would review the patches and
approve them or not and fold those patches into your copy and then
commit the changes to the repository.

I think this could become pretty painless with the right tools (I use
the command line, myself though).

This would allow more than document text suggestions but things like
typos, styling, inserting links, etc.

-------------
 
Sounds good to me. I had not heard of Subversion, and  so read about it a bit on Wikipedia. It doesn't necessarily sound trivial to get started,  but if that's the easiest way to go for this sort of project then let's do it!
 
There is also Google Docs (which of course now has SVG) but I gather there is a limit to the size of a given document and the book is hovering at about 750K of HTML right now. I rather get the idea that versioning is not its strong suit, and for version control, Subversion looks a lot better, though I suspect the interface for Google Docs is easier to enter from street level. Another approach: Etherpad, appears a little too concurrent and chatty. 
 
I'm fairly adaptable, though I might not have much time to learn anything new before July, unless it's real easy. So whatever will do the job and whatever most people are comfortable with is cool with me.
 
Until we do get something in place, (assuming that whatver might take more than a week or two to get going) I'd suggest sorta like what Ruud did recently for all simple corrections: 
 
lists sorta like this:
 
[
   1. /original text/revised text/
   2. /more text/more new text/
   .
   .
   .
   n.  /old stuff/new stuff/
]
 
that way I can find the stuff that needs to be changed. 
 
Alternatively, (again assuming that setting up Subversion won't happen immediately), we could have folks from here name  one or two chapters that they'd concentrate on, as another way to avoid duplication of effort. 
 
As you can see I'm sort of working in my mind on both short and long term approaches, with a short term interest in laying my current flurry of activity to rest, for a time to concentrate on other projects like writing a paper or two for SVG Open. BTW, I was thinking of maybe offering a talk just about the status of the book and of whatever collaborative mechanisms for it that we might design and implement between now and SVG Open. Might that make sense to folks?
 
And for new sections, I'd recommend that people volunteer to write any new section, so we don't get multiple people writing the same section. Right now, Shaun Roe has volunteered for an XSLT (/AJAX) section, but all of those topics contained in the Afterword are in need of volunteers. Preferred format until we come up with something else would be
very simple HTML : (limited pretty much to <p> , <img> , <pre><code> and <table>) without CSS, unless you can figure out the styles I've been using which is (alas) not necessarily obvious. Please review that list of topics to see if a) there is a topic or two you might volunteer for or b) if there is a topic missing from the book that really ought to be added to that list.
 
As I mentioned in a previous email I've also not put any live SVG in the document, because of not wanting to crash IE which chokes when more than 100 or so separate SVG's are included. Hence all the images are screen shots in either jpg or png format. Eventually it may make sense to fork the document so that IE users get PNG&JPG and others get SVG, but that is about 60 hours of work I'd guess (just finding all the original SVG files -- 200-300 of those -- , testing them, uploading them and then linking to them).  By then, maybe we'll have new solutions that make ASV obsolete, so forking may be a non-issue??
 
That also brings up another issue: how best to point from the book to more current content in planetSVG ? There are places in which the book will be out of date. Maybe using chunks of it to seed wiki topics and then have the original chunks have pointers to the subsequent and live derivations? I'm not sure quite what other models there are for what we're trying to do here. The recent rather crazy debate about the licensure of HTML5 comes to mind and the possible inappropriateness of GNU or other licenses to stuff which is not software but text comes to mind.
 
Of course, once the infusion of real SVG into the document were done, then one would want to make all the source listings be auto-generated through JavaScript from the live SVGdocument, and that starts making everything a bit more fragile. I believe the SVG IG also sorta agreed back in the summer that that was a bit too much adventure for now.
 
As I write this email I am discovering that I should probably be writing such notes in the planetSVG Blog, or in the SVG IG wiki or something, since I'm finding myself being a bit redundant. Oh well, after more than 30 years of writing e-mail I guess it is a hard habit to break.
 
While I'm thinking of it: a big thanks to Ruud for having given just the right encouragement to get me busy working on this thing again! While finding myself very anxious to end the tedium of editing and revision (maybe 100 hours of just dealing with repercussions of Word - HTML problems) , I'm finding this next phase of collaboration that we're entering to be a fun and exciting one to think about.
 
cheers
David

Received on Wednesday, 15 April 2009 03:15:53 UTC