We may have been doing this since 2001 (next year is our 10th anniversary!), but I found I still have a few things to learn…

This year:

Too many laptops: It turns out you can have too many laptops! In previous years we were always one laptop short (or the group contained someone who wasn’t very comfortably doing a lot of typing). That meant that there was always someone who was doing proofreading or checking or other tasks. This year, we all had laptops, and we all liked to write. So we wrote lots, which meant that when we got to do the checking and proofing, there was an awful lot of it!

Printers: Conversely, we had only one printer with a very limited amount of ink left in the cartridge. So we didn’t really want to print too much in case we ran out. So maybe just having more ink would have solved the problem – if there had been easier to print out then we might have printed more and started our proofing earlier. Or maybe not.

File formats and layout: Due to the various different office suites in our group, we decided to do everything in .rtf files. The problem with rtf is that there are several different versions - and we were finding weird formatting problems (particularly with bold, which was doing some very odd stuff).

Combined with that was my desperate inclination to make everything look nice. I'm sure I started doing that much too early, and once you start it's hard to stop…

So here are three thoughts for next time:

Write everything in ascii (using Notepad) and don't do any formatting until the end. This is sort of tempting.

Use googledocs or some other online system. My main worry about this is the wifi connection at the cottages leaves quite a bit to be desired. It was the best signal I've ever had this year, but not all of us in our group could connect to it.

Download the latest copy of AbiWord Portable onto USB sticks using http://portableapps.com/ Then we can all use exactly the same software - even Linux fans. AbiWord is powerful enough for 99% of our needs - certainly we wouldn't have needed anything more powerful.

We used something slightly different - before sheet writing started, I produced a template that I knew round-tripped well between Office and Open Office, and we had no problem at all. (A discussion on "boiler plate" vs "outline" and when you split is a different topic). At some point, however, "well formatted" becomes part of the writing process for me, even at Peaky, so…

I am a power user of Office, and can do FreeFormy things in it far more usefully than I can in any other competing version - but other writers should not be locked out of the process. I agree RTF is more trouble than it seems. A fully-usable plot-writing database system might bring in (eg) CSS formating, but until then, the current leader is "Office (and probably Office 2003/2007 in compatability mode) <=> Open Office. Almost no-one should end up paying no more than £10 for at least one of those. If your notebook cannot run either….

Google docs does not work for me; I don't like their security and IP rights policies, it is blocked from my work (and only) laptop, and we do not have the reliable connectivity when at Peaky. I suspect they had two access points, and one was good strength, but not accepting connections, and the other was low but working….

Post-Peaky, we have "Veteran's day" on a SubVersion server, and it works beautifully. Arranging a local SVN server as part of pre-peaky geekery might be an answer.

Once you've tried it, it works really well. Get the geeks to set up the server; on my Windows machine, I pretty much have just installed the client software on my machine. I then right-click in an appropriate directory, set the subversion server URL, username and password to that project and sync, and I get the whole project tree under there. After that, all the locking, logging and checking in and out that you would expect with a proper source control system works, and is totally integrated. If your server is publically visible, then it works fully across the internet too

For instance, I can right-click over a controlled file in the subtree (as shown by a tweaked icon), select "properties", select the subversion tab, select the log option and a change log is brought up. I then select the two revisions I want, select "show differences" and Word is launched in Difference mode - it knows I have Office there and uses it properly. Loverly!

There is probably a thread to be had on moving back and forth between Office and Open Office, and preserving consistency. So, from experience and memory:

Word 2007 editing 2003 documents in compatibility mode (ie a .doc, not a .docx) seems more tolerant of OpenOffice-round-tripped documents;

Start a source document in Word as a template;

Defining styles (within the document) and sizes to be consistent helps;

A major nasty is bulleted lists. Putting in examples (eg a placeholder after "Items:", "Goals:", etc, means they can be extended, rather than created, and this preserves initial formatting properly (thought the special bullet characters don't always display properly in OO - they round-trip correctly, though;

Some fields do work - so Title, subject, Date Printed, Page numbers, file name, etc can be used properly - and use of these are strongly recommended in your template.

I've seen an issue with something that looked like a style from OO being used for bolding being completely confusing in Word.

I'd like to know whether Custom Fields/entities (which, for instance, BW's regendering macros use extensively) go across properly. We may need to arrange a test.

In my (sometimes bitter) experience, using styles at all in Word denotes you as a power user. I like to work with decent templates and styles myself, but all too often a collaborator's piece of work comes back as a dreadful hash of ad hoc formatting. And fields can cause complete bafflement… There sometimes seems to be a real conceptual barrier about what the value of these features is, when someone's been using Word happily for years without being aware of their existence.

All this is (as well as a whinge ;-) just to say that even a well-thought-out round-tripping system is at the mercy of its users, so there may be an education task needed first.

But that is exactly why it is a template - get it right (and particularly the Normal matching what you want through the sheet) and the end result should be mostly transparent to italic most authors.

There was one very large document I once wrote, about "best practice", which we polished to within an inch of its life, then sent to the PMO for issuing. When it came back from the PMO document group, they had stripped all indents back to spaces, removed the "this is code" monospaced highlighted boxes, hard page breaks were carefully adjusted numbers of carriage returns, etc,…. I can forgive people not understanding fields in areas they should be editing, but that was a group tasked with enforcing a house style who had no concept of the tool. Styles should be about clarity and simplicity of editing - anything else is later polish.

Among my least favourite collaborators are people who, when provided with a lovely and complete template, insist on eg. when they want to add an extra 3rd-level heading, enter it as Normal and then format it manually so as to closely resemble the actual defined Heading 3 style. I've come reluctantly to the conclusion that the best thing for these is to lock off as much of the document as possible and just let them edit the bits that are plain Normal.

For Epic Experience games we actually use a form interface that handles all textual input and tags it up according to the form field definitions, storing everything as XML. You then can export it via an appropriate XSL stylesheet to obtain the desired styled and formatted output docs. The aim was to totally separate content from appearance (from the user's point of view).

It works very well for us, but it runs on Lotus Notes which may be a bit overkill for most writing groups…

Most people already have Word or Open Office and don't want to learn a new markup language; hence my emphasis on transparency of template. I accept that if we have a "plotwriter" application, it is likely to be markup based, but….

Plain text is OK when importing, but once imported into a document, the round-trip needs to preserve formatting. Or your users need to grok the layout properly. Or the "Power User" has more work to do than in eg a Word Environment.

IMHO, once text is well laid-out and properly formatted, the quality of the proof-reading on it goes up, and the attention span of the users does not diminuish so quickly. Part of the reason I like templates is that it influences writers to think in terms of entities that are beneficial to the authoring process. Flat text does not do this! For most users, WYSIWYG improves productivity. Visual differencing of changes also works really well these day!

(FYI: I have personally used NROFF, TROFF, SGML, similar systems like RoboHelp, naked PostScript over many years in numerous professional roles. Why not lose the front-end source control apps and edit the revision directives directly too?)

I WANT to have an single central repository, so that the default way of working is "one common source". Mercurial is specifically designed to not enforce this way of working - and if you have a single "Peaky copy" initially available locally between different writers' machine, then later made available for remote editing, then you have a server, whether it is "just" a file system or whether it it a specific Service interface. (Whether one model is intrinisically better is a religious issue). And Subversion can work in a File-only mode too. The Server mode works well across the internet.

My main reason for using plain text is it makes looking at diff's in the Revision control system easier. Which ever one you use. I'd only import the files into a WP right at the end - if at all - I 've written many docs in RST and because the Rst can produce nicely typeset documents they are easy to proofread. And you get your style templates as well.

And to be fair I don't have a lot of experience using Word processors - I know what features they offer can can normally find the features I need - but I am much more comfortable in a text editor. - I know that doesn't hold for everyone but the simplicity of text file can't be beaten.

Yes, mercurial doesn't enforce (it doesn't prevent you using one either) a central server - and I can see why you might want one, but my experience of the peaky makes me want to be able to capture the natural chaos of the environment. Not try to enforce the environment to be more structured and risk losing work, or getting confused. When everyone syncs their repos to a memory stick passed around the room it will automatically pick up and sort out the latest changes across all the files. You can then deal with the any conflicts separately.

I wasn't aware you could run SVN in a file mode where we could put the central repo on a memstick, although I still think a DVCS is better because the you can commit before you merge , as SVN sometimes forces implicit merges - as opposed to allowing short lived anonymous branches.

This is not the place to argue this one , it is as you say a religious issue . Or very close to one - given the speed many projects (inc. commercial ones) are dropping SVN for Hg or Git it seems that DVCS are the way forward in the VCS problem space.

One reason I like my TortoiseSVN client is that it is completely and painlessly integrated with both the Windows file system and my Word - so I can just sync, see the differences clearly (in my Word difference view) and carry on. Trust me - it makes the functionality available more cleanly than Office itself does.

At the early stages, an unstructured model could be an advantage. Later on, I want to have precisely ONE version moving forwards - and having written with people who go off-piste, this is actually a discipline I would highly recommend as you approach publication!

Whether SVN is being superseded by other systems, I really have no opinion of, but in the circles I am moving in, it is steamrollering all the non-open-source systems. Yes, it's a traditional model, but for product with a distributed team, that is much easier to manage. Offline parallel editing is something I would appreciate, but that's the part of "distributed" I like. Too much done away from the team is generally bad!

If the writing team has a Power User (of whatever discipline) amongst them, and the team has the discipline to follow that approach, then all is fine.

My concerns are the groups that don't have Power Users (ie, most of them - I don't count myself as a Power User!. For them, I think simple solutions that they can easily follow and won't screw up are needed.

I agree that there is a need for a consistent writing format and platform, but I don't think the answer is to use either a different techy word-processor rather than ones we're used to using, or using rtf or plain text, because you lose all formatting, which is the problem we're trying to solve. AJ used html when we were writing All's Well, which also allowed him to do hyperlinking easily, but that's too techy for most.

We managed to get by with a mix of Word and Open Office this past Peaky, and it wasn't too bad. It would be nice if everyone just used one program (I'm happy with Word), but it doesn't look like it's going to happen.

I think in terms of writing for the weekend, the most important bit is to have a standard format for the character sheet, by which I mean, what parts to have and in what order, rather than format like Heading 1 and Normal. If you agree at the start that you'll have a character sheet with, for example:

What People Know About You
What People Don't Know About You
Background
Goals
Who You Know
Abilities
Items

That should be enough to produce standard sheets to play with. Other than that, you should agree on a font to use, like Arial 10, but the rest isn't strictly required. When it comes time to take it further after the weekend, you can worry more about headings, etc.

We're using Googledocs now to take The Day the Music Died forward, but already I'm not liking it because it's not like Word and you can't do a lot of things I could do in Word. But we'll see how it goes.

I think as long as the writing group can agree how they're going to do it, then it doesn't matter which particular solution they use. (And as you did, we had a mixture of Word (various versions) and Open Office - and we got by. But we did waste time as a result and I'd rather be more efficient.)

We agreed what was going on the character sheets early in the process, so we knew what we were doing in that sense.

And you're right, for Peaky itself it really doesn't matter if all the character sheets have different fonts and headers (although it's always satisfying if you can get consistency).

I'm intrigued that you find googledocs limiting. I think of it as a tool for collaboratively getting the words right. Layout comes later, using something different.

Separation of form and content is pretty important in collaborative working on this sort of project. If you have the content typed up as text under the agreed headings (like those that Heidi suggests), then putting the formatting on it can be a one-person job and the last thing that's done. That way, while you're all working on the text, you can hand it back and forth as plainly as possible, and different people can use their preferred style of working, without wasting time translating and fiddling with each other's formatting inbetween.

The ideal is to be able to keep the two separate permanently, such that application of the formatting stylesheet is a publication-time-only operation. That way any amendments can just be made to the plain text, no matter how late in the process they arise. But that requires XML or similar, which is probably getting too techy for most people to want to work with.

There are two sorts of style to consider: The first is writing style, the second formatting.

Concerning the first, this time around, we went for notes, which were then expanded by the person doing that character sheet. Compared to the previous year, where we wrote segments, then dropped them in to each sheet, there was a higher consistency of style within the sheet, but more minor errors in terms of how the detail of each plot was written up.

I must admit, I am a fan of having SOME polish in the formatting reasonably early, as I think people read "proper" text more carefully than just a flow of raw ASCII - but I do agree that final polish is very much icing. OTOH, unless you have a style established earlier, then this can be a bottleneck - you want final style to be checked either by one person (unless you are very sure you agree with each other), and I have been the one person staying up late to do that polish before!