Write paper with collaborators

[morphemera]

Writing papers usually takes a long time and have many small revision. It is especially true when it comes to collaborate with other people because someone may hold the paper for a very long time. So is there a better workflow for collaborative writing?

One method is to send the email to the collaborators with the revised manuscript. Everyone writes their own part and then pass the partially finished paper to the next one. It is simple, but slow (usually the group leader or supervisor) and no change tracking. Sometimes I find it difficult to work with the flooded email only for small changes.

I have read some methods to the writing collaborative paper at
http://en.wikibooks.org/wiki/LaTeX/Collaborative_Writing_of_LaTeX_Documents
I think the Subversion+latex and Dropbox, are a good solution since it has the many advantages such as version control system (for tracking change) and easy synchronization (for sharing).

Personally, I use the Subversion for my own programming code and benefit much from the branching, tagging and reverting function. Recently, I have also used it to write papers and found it satisfied because I can keep the logic of writing for later revision and use the revert the wrong writing. I have not asked the other to use the Subversion yet because it requires a centralized server, but I will try later the other distributed versioning system such as git and mercurial.

So, I want to know a better method and your experience on how to write paper collaboratively

 

[Mapes]

I'm currently writing a paper in LaTeX with several collaborators. We use Dropbox to share the .bib file and figures, which are updated only rarely. Because Dropbox doesn't allow simultaneous editing, we're also using Google Documents to share the .tex file, enabling simultaneous editing and revision comparisons. But I'm definitely going to check out your link to see if there's a better approach. (My collaborators and I are physicists and material scientists, so we know little about version control in programming.)

 

[morphemera]

Thanks for sharing. I haven't considered the Google Documents cos I don't know that it has the function of simultaneous editing and revision comparisons. I think your current practice is already a good solution for writing paper. Anyway, I have some questions for your approach.

1) Why do you use both Dropbox and Google Documents, instead of using only Google Documents? It seems redundant and the Dropbox need the installation.

2) Are collaborators comfortable with learning how to use those? I think that it should be easy for the collaborators to learn.

3) Have you found some weakness of using Google Documents for collaborating?

For your information, many feature in version control system are not used in writing paper such as branching. But if you need many programming, than using version control can make life much easier as far as you know how to set it up.

Sorry for so many questions.

 

[Mapes]

Yes, I looked at the link and don't think we can improve much more on our current setup (which is both encouraging and disappointing, of course!).

1. I've combined Google Docs and Dropbox so that we can edit the paper simultaneously without overwrite or merge problems (this is the Google Docs part) and also share >100MB of files: all the paper's references in .pdf form, plus the .jpg, .png, and .eps figures and their Adobe Illustrator .ai sources, plus the BibTeX .bib file, the .tex file, and the compiled .pdf (this is the Dropbox part). Everyone can compile (via TeXnicCenter and MikTeX) a new .pdf whenever they desire within the Dropbox folder, and this new .pdf file is propagated to everyone else's Dropbox folder automatically along with any other file changes.

2. People are still getting used to the system. Some haven't used Dropbox before. The biggest hiccup was the tendency to edit the .tex file directly in the Dropbox folder even though the Google Docs file should be considered the current version. To compile, the Google Docs file should be copied-and-pasted into a TeX editor and compiled there.

3. The biggest Google Docs annoyance is checking changes between revisions. Google saves the file automatically with a new revision number every few seconds, so you can easily get thousands of revisions. I don't know of an easy way to query "Show me everything that person X has changed," for example. I can only compare, e.g., revision 342 with revision 1249.

Hope this helps. I find these discussion very valuable for learning new techniques from my colleagues!

 

[morphemera]

You experience is really helpful.

Putting large files in Dropbox and using Google Docs for simultaneous editing latex file is a good method. I will definitely give it a try later if I have time. But what do you mean combing two? Does it mean that there is no need to install the Dropbox, or just use them together?

From your description, I see some minor things that is good for the version control system. The tex file can be generated automatically in my current use of Subversion. It is just a small script with few lines to check the Subversion commit and compile the source code (i.e., latex bibtex latex latex), which is similar to the .pdf generation when you submit to the arXiv.

Also, the revision in Google Docs seems pretty useless because of lacking information. Each commit of Subversion can record of the username, change and user written message. The message is very useful for tracking the change so that we can blame for the poor writer . Plus it can be edited offline.

Certainly, synchronization the material between collaborator is the most important things in writing collaborative paper, so Google Docs is good. Anyway, I think there may be a way to incorporate the above advantage...

 

[turbo]

I'm writing a paper with collaborators in Finland and the US. We each choose a color, and as we make revisions or additions, we make them in our own colors and email the revised document to the others (with the date in the file name). As the changes are agreed upon, they are changed to black before the next revision. Very simple. It works well because we are a small group and we have a good understanding of one another's capabilities.

 

[Mapes]

Also, the revision in Google Docs seems pretty useless because of lacking information. Each commit of Subversion can record of the username, change and user written message. The message is very useful for tracking the change so that we can blame for the poor writer .

Exactly - nothing beats seeing who's to blame for some passage the reviewers didn't like!

I'll definitely take a closer look at Subversion.

By combining Google Docs and Dropbox, I just mean that we edit the .tex file in Google Docs, then need to copy and paste into the .tex file in Dropbox before compiling. Not a "real" functional software combination by any means.

 

[Astronuc]

I've recently been editing a report that had up to 30 contributors. We have been using MS Word with 'track changes', in which various contributors changes and notes are colored. It because untenable when folks started editing/changing deleted material, or only using parts of a file, such that merging became impossible.

To allow merging, contributors must start with the same version. All those changed versions must be merged and the same revised version then used for subsequent editing. Once versions get out of phase, the process quickly deteriorates.

There are ways to edit across networks so that folks are working on the same file simultaneously. I've had limited experience with that. It seems OK for a few contributors.

 

[morphemera]

I'm writing a paper with collaborators in Finland and the US. We each choose a color, and as we make revisions or additions, we make them in our own colors and email the revised document to the others (with the date in the file name). As the changes are agreed upon, they are changed to black before the next revision. Very simple. It works well because we are a small group and we have a good understanding of one another's capabilities.

It is a simple method when everyone writes their own part and the number of revision is small. Otherwise, you will have a stock of files and emails. Also the pages fill with alternating color and the information is lost after each revision. It might seem ok when the people have similar background. However, I have found that even my supervisor can rewrite most of my sentences sometimes. There is certainly better method.

Exactly - nothing beats seeing who's to blame for some passage the reviewers didn't like!

I'll definitely take a closer look at Subversion.

By combining Google Docs and Dropbox, I just mean that we edit the .tex file in Google Docs, then need to copy and paste into the .tex file in Dropbox before compiling. Not a "real" functional software combination by any means.

For the blame, you can see a web interface 'websvn' for Subversoin:
http://www.websvn.info/
http://demo.websvn.info/blame.php?repname=WebSVN&path=/trunk/diff.php&
You can track all the revision and the author of all lines.

I have just tested for the Google Docs for a while and it seems easy to learn, so I can use it temporary before I find another simple yet better solution.

I've recently been editing a report that had up to 30 contributors. We have been using MS Word with 'track changes', in which various contributors changes and notes are colored. It because untenable when folks started editing/changing deleted material, or only using parts of a file, such that merging became impossible.

To allow merging, contributors must start with the same version. All those changed versions must be merged and the same revised version then used for subsequent editing. Once versions get out of phase, the process quickly deteriorates.

There are ways to edit across networks so that folks are working on the same file simultaneously. I've had limited experience with that. It seems OK for a few contributors.

Thirty contributors for one report sounds horrible, is it about the high energy physics? I have ever seen a paper with few hundred of authors listed in the two full page, but I sure most of them do not write the paper and they have their name on it cos they are one team.

The 'track changes' in MS word is quite good for small change. But I still remember that my supervisor has rewritten almost all part of the introduction in my first paper because of poor writing. The page is full of strike for deleted words. After few different revision, it becomes messy and the words fill with different colors because we have edited it on few different computers...

Then how do you handle the report actually?

 

[fasterthanjoao]

http://lifehacker.com/5513760/googl...wing-editor-real+time-collaboration-and-speed

Real-time collaboration, you say?

I haven't tried it yet, but I shall.

 

[morphemera]

I have played the google wave with friends and its simultaneous editing feature is, well, fancy but not useful. When you are typing, you can imagine many characters appear one by one at random location on your screen. Also, your cursor is pushing right and right and sudden appear at the beginning of the next line... It is really distracting.

But keeping one consistent document is a big advantage though, and most of the time, people do not edit at the same time so it is not a big problem.