Writing Collaboration With Source-Control And Microsoft-Word

Question

[Will]

This is not specific to "Bioinformatics" but I bet that most of us have come across this problem at one point. I was wondering if anyone has come up with a cool solution.

I've started collaborating with numerous "non-technical" writers lately. My general writing workflow is to use source-control (usually git) and a latex document. This helps me keep track of changes, reasons for them, reverting back to old versions if necessary, and seamless collaboration. However, these new members would rather quit the project than even try to learn latex.

I'm trying to avoid the problem where everyone has their own version of a manuscript and then having to e-mail them around and merge 12 different files at the end.

Does anyone know of a meaningful source-control system for Microsoft-Word documents? Or any way of converting latex to .doc files (and vice-versa)? Or any other suggestions. Google-docs may be a viable solution for dealing with the "text" of the manuscript and then just dealing with equations, figures and references afterwords.

I've thought of using a shared DropBox folder but this "locks" files that are in use by other users to prevent clashes when saving. The only way around this is to have a different file for each person and then have one person in-charge of "merging" them into a single file after every batch of revisions. However, this may make things more difficult.

Has anyone had this problem and come up with a reasonable workflow/toolset?

Thanks, Will

[Mike Dewar]

This doesn't really answer your question, but I've found that, amongst heterogenous mixes of tech/non-tech people, sometimes the best idea is just to have someone in the group be the `editor'. This person will keep track of everything in their document, which will be the canonical version. They request contributions to the document from other team members and incorporate them. Proof reading is done traditionally, or on draft-version Word or RTF documents. I've found that people that don't "get" version control/shared documents (i.e. googledocs) do "get" the concept of someone being in charge.

[Pierre Lindenbaum]

http://13c4.wordpress.com/2007/02/24/50-reasons-not-to-change/ :-)

[Will]

by "non-technical" I also have the issue of "Old dogs don't want to learn new tricks" ... so while there's all sort of cool things like google-docs and google-wave these people don't want to learn anything new ... I'm trying to find a way to integrate what they already use.

Answer 1

[Fgibson]

This is not a technical problem, its a social problem. The solution as to how to allow collaborative writing via word documents is easy. You place the document and the reference library in a code versioning system of your choice and apply sensible working practice such as locking and logs.

The problem occurs when the collaborators refuse to contribute in this manner. There are probably three options.

1. Take the time to Educate them in this working practice and explain the benefits,
2. Refuse all submissions unless it is via this system,
3. Give up, and concede you will have to apply insane (or lack of even insane) information management techniques.

At the minute, as far as collaborative word document methodologies go, for the "why-am-I-even-using-word-chalk-and-slate-work-fine-for-me" lower social demographic then the most sensible solution is to use Office Live as it allows them to work in an environment that they are comfortable in.

If you are forced to do it via email and receive multiple copies of the same document, then you can actually handle this sensibly by using the built in "merge documents" feature of word, along with Track changes. However, this still requires a final editor to go through and accept or reject the changes.

Unfortunately, you can only work as efficiently as your weakest link - or become a dictator.

[Marcin Cieslik]

Although I agree with your diagnosis I disagree that locking (and presumably manual logs) is a sensible working practice. I think that distributed version control over latex documents with "% please do not edit this paragraph its far from ready" comments and word based diff merges makes it easier.

[Fgibson]

The original question was about word documents which are binary files. As you say that would be ok to do with latex because the version control system can work out the changes. It is less than efficient to merge or diff binary files

[Marcin Cieslik]

... but the new Word docx are zipped XML files

[Fgibson]

same principle applies, unless you keep them unziped for the duration of editing. I am unaware of a versioning system that can diff content of zipped files

Answer 2

[Giovanni M Dall'Olio]

There is a SVN extension for openoffice, but I have never tried it. There is also a plugin for git to handle open office documents.

As an alternative to google/docs, I recommend you to try Zoho, which has a much better interface and many more options.

Personally, I only use collaborative tools for small documents, like tables or summaries, and for big texts I prefer to use a git repository with the git plugin.

[Will]

i like the git plugin .... I never searched for that, how well has it worked for you?

[Egon Willighagen]

I was not aware of these plugins... cool! Thanx for the tip!

[Daniel]

also didn't know about those plugins.. thanks giovanni

Answer 3

[Neilfws]

Has anyone had this problem and come up with a reasonable workflow/toolset?

Yes and no, respectively. Receiving yet another version of a Word document by email is, in my experience, one of the scenarios most likely to make a bioinformatician explode with rage :-)

I think that you have already covered the best solutions. Dropbox at least has the advantage of keeping one "master copy". This, for me, is the main issue - I would just forget about concurrent editing and inform other users about the file lock issue.

Google Docs is an excellent collaborative solution but unfortunately, Word users will take one look (assuming that they even bother to log in), exclaim "where's the EndNote?" and go away again.

In my experience, it is more or less impossible to (a) encourage biological scientists to learn any new document preparation software outside of Microsoft Office and (b) prevent them from emailing multiple versions of documents. Anything that requires them to create an online account and sign in - forget it. Your only options are:

• grit your teeth and put up with their ridiculous workflow
• refuse to have anything to do with the writing process
• take complete control and do all the writing yourself

[User 59]

We do this for collaborative writing. When someone wants to edit the file they just email the other users and claim the magic 'editing token'. Whilst this token is in their possession, no-one else edits it. When the token is released in a subsequent email, another user can claim it and continue to edit. Low tech and works just fine with a document in Dropbox.

[Simon Cockell]

I have used an empty file in the DropBox folder called 'NOT_CURRENTLY_EDITING' which is renamed to something like 'SIMON_EDITING' when you want to take the magic token. You then revert the filename when you relinquish the token. Saves anyone missing the mail where you claimed the token.

[Neilfws]

That sounds good. I realise this is not one of my better answers; I'm afraid this topic just trips my trigger :-)

Answer 4

[Egon Willighagen]

About Word + Git

I would suggest to use the .docx format. Set up an environment that zips up and unzips the archive content, and put it unarchived in the repository. That way, you should get meaningful commits. I do not have .docx files around (as Microsoft refuses to release Office for Linux), but this post gives further practical information, talking about indexing the content of .docx files.

About LaTeX + Git

We recently started a book on pharmaceutical bioinformatics, to complement the course. Our group leader really preferred Word too, but we tricked him into using Git + LaTeX.

The key argument here was that collaborators can write their bits basically just as plain text. They only need to learn to ignore the stuff the do no recognize. (In that respect, a LaTeX editor that could hide markup, just like in the old WP 5.1 days, would be welcome.) And the second thing is to keep the text they need to work on with as little format as possible for as long as you can.

To me, the real blocker is, to get an environment working for them that creates the PDF. That was the harder part, not so much convincing them to learn to read LaTeX sources.

[Aaron Statham]

Office 2007 plays pretty nicely with WINE these days

Answer 5

[Pierre Lindenbaum]

Can you ask your collaborators to share a document on google doc ? you could then download it as an openoffice document and transform it into Latex (I guess some tools have been written to do a oowriter2latex)

[Will]

very nice ... I'd actually never come across this tool. Maybe in my git reposititory I could have a "built" .doc file that non-techies can download, edit, and then e-mail back to me. I can then integrate the changes (almost like a "patch") and then re-build the document. If I keep a little marker in the built-document with the version# then it'll make it even easier to figure out which document they made their changes from.

[Michael Schubert]

You might also want to look into Google Wave if that hasn't crossed your mind before.

[Khader Shameer]

I would like to mention about a strange behavior of 'google doc' with EndNote when I tried to add references to a document saved from 'google doc'. EndNote was not inserting references to the doc. Once I copied the content to a text editor and copy it back to word it worked.

Answer 6

[David Quigley]

A quick and dirty method for writing papers when using Word documents is to use the Track Changes tool within Word. This is not full-blown source control, and it lacks the sophistication of being able to fork, roll back, etc. Users still have to pass a copy of the document around. Each change is associated with the editor who made the change and the time the change was made; changes can be accepted or rejected. You can see the changes within Word; this gets over the enormous (to non-technical users) hump of having to use a separate tool to manage versions. This is not an ideal answer to your question, but in practice I've found it gets the job done.

[Chris Miller]

If I email copies to users X Y and Z, and they all make and track changes, I now have three copies, with different changes, and no way to merge them. This is exactly the situation that the poster wants to avoid

[Chris Miller]

If I email copies to users X Y and Z, and they all make and track changes, I now have three copies, with different changes, and no way to merg ethem. This is exactly the situation that the poster wants to avoid.

[Will]

this is the method I currently use ... and it leads much to be desired

Answer 7

[Chris Miller]

As I understand it, Microsoft now has Office Live which allows for web-based concurrent editing, sharing, and collaboration using an online version of Word.

In my mind, this is less than ideal, and I'd much rather use Google Docs, but if your old dogs refuse to learn new tricks, this might be a viable option.

[Pierre Lindenbaum]

nice, I didn't know Office Live

[Will]

although that makes me change my workflow ;) ... but i guess its far easier for me to adopt something new then it is for them.