The Clunky Mechanics of Collaborative Writing
Forget the myth of the lone genius: science is a collaborative enterprise, requiring cooperation within large teams of people. Often, this is both a joy and a necessity: many hands make light work in the lab or the field, and collaborations massively extend the scale of research questions we’re able to address. More and more, however, writing of papers, reports and funding applications is becoming collaborative too, and that’s seldom so pleasant; the best writing is personal, and writing by committee is difficult. There are counter-examples - the teams of writers beavering away on blockbuster US sitcoms spring to mind - but attempting to write something coherent when authors are scattered over multiple institutions, sometimes across many time zones, brings significant challenges. Although this post has been triggered by big collaborative writing project that's consuming my time recently, it would be inappropriate and hugely unfair to comment on some of the issues of content that plague all such enterprises; what I want to focus on instead is the actual mechanics of how we write. Some of the orthodox habits of academic collaborative writing seem incredibly frustrating, but I’m unsure of how to address them in a way that is accessible to all.
The first issue feels like it should be a non-issue, given that content is platform-independent: what software do you use to write? For almost everyone I’ve ever worked with, the answer is: MS Word. My view is that Word is fine for individual writing. Sure, ‘features’ like its habit of second-guessing your formatting choices or its eccentric decisions regarding wrapping text around figures are frustrating. But as a simple typewriter it’s OK, and although I’m trying to shift to Scrivener more for my own writing (using it now), I do still use Word daily. The commenting system in Word - comments and tracked changes - also works fine as long as the number of commenters is small. But in a team of 20 or so, and with a heavily edited document, it becomes very unwieldy and, more importantly, very unstable - I’ve lost so many annotations through crashes.
What are the alternatives? I’ve never really got on with Google Docs, or at least haven’t seen anything that would place it substantially above Word. I know papers are now being written with full version control in GitHub, but even the advocates of this approach admit that, for now, the technical barriers to entry are too high to expect all collaborators to use it. And to be honest, a 20-author document is always going to be unwieldy, regardless of the platform. Perhaps we just have to learn to live with this.
Then there is the profusion of files which again, inevitably results when lots of people are simultaneously working on different parts of a complex document. How do we track these? Emailing individual docs around is a recipe for disaster, so some kind of file sharing system needs to be adopted. I’m a big fan of dropbox, but not everyone is (some institutions actively block it, I’ve recently discovered). On this application we’ve been using MS SharePoint, which I have to admit I’m not a great fan of, perhaps because it’s just more of an effort than dropbox. Perhaps if we used its full features, e.g. signing out documents for editing, rather than downloading and re-uploading everything, it might have won me over. Upshot anyway is that I have both a SharePoint site and a Dropbox folder each containing close on 200 files, with many combinations of initials and dates appended, which must be suboptimal… (Incidentally, sticking a date at the end of a filename is useful, but if you do so yy-mm-dd format allows for the most logical sorting.)
That’s a lot of problems raised, with little in the way of solutions. So if you have any killer tips, do let me know! But I will finish with two more constructive points. First, I said I didn’t want to talk about content, but I think there is one thing worth emphasising: Nothing is Sacred. There is no place in a piece of collaborative writing for egos and intransigence. By all means argue your corner if you feel a coauthor has completely missed your point. But think: if your coauthor doesn’t get it, no chance that a reviewer will, or any other reader. So don’t just dismiss their concern; take their criticism on board, re-work your text, and get back to them. In this sense, collaboration is the first stage of peer review. (A related aside on comments and tracked-changes, in the context of multi-author documents: comments can be useful, if they take the form of “X please write two sentences on that thing you know about here…”. But before adding comments like “This needs more detail” or “This doesn’t work for me”, stop and think whether you could preempt your own comment by actually editing the document.)
Second, a couple formatting tips. Every proposal I’ve ever been involved with has ended up bouncing off the page limit, and so it’s useful to be able to make maximum use of available space. One tip I got from Twitter (whoever it was, thanks!) is to turn on automatic hyphenation in Word (Tools > Hyphenation…), which gains a surprising amount of space. Apart from that, I’m a bit wary of pushing font size and margins right to the limit, simply because confronting your reviewers with massive blocks of dense text is not going to do you any favours. The key then is to edit, edit, and edit again (see also the point above about nothing being sacred).
I take a strategic approach to this: any paragraph that ends with a line less than half full is ripe for reduction by one line, easily, simply by cutting unnecessary words and rephrasing. Be really harsh on repetition, verbiage, impressive-but-meaningless words, and repetition. (See what I did there?) Use short words like ‘use’, no need to utilise longer synonyms like ‘utilise’; this will help readability too. Funnily enough, this is an area where Twitter really helps, as it gets you used to fitting ideas into a strictly delimited space.
So anyway. I now open this to input from coauthors…