How to effectively write a paper of N>2 co-authors? [duplicate]

Question

We are writing a manuscript with 7 people. I am not sure what is a good tool to write a paper collaboratively. Other than overleaf or sharelatex which cost money.

What do you do if you have technology inclined collaborators?

Answer 1

Git! Or more generally, version control systems, if your co-authors are technically inclined enough to know/learn how to use one.

If not, probably... write the text in google docs first and designate someone who will do the formatting in the latter stages, and decide what to cut to make the page limit.

Answer 2

Short answer: it is a pain, unless you can all agree to use a single way of working, which is unlikely. I will describe my own workflow below in case it gives you ideas.

In my experience, each author wants to use their own tools. Depending on the field this is usually Word or LaTeX. In biophysics, almost nobody uses version control and most of the people I worked with are not willing to learn it.

I am not saying you should do what I do, or claiming that this is the single best way, but my workflow is as follows:

1. I write the paper as very basic LaTeX (almost plain text). I use version control.
2. I paste it into libreoffice and do some basic formatting (otherwise some co-authors will start "correcting" the formatting). I email everybody the draft of the paper.
3. Co-authors suggest changes, all at the same time. I ask them to highlight or track changes and, importantly, leave comments and tell me WHY they propose a change. You'd be surprised how many people make changes without letting you know why.
4. I manually merge the changes of all authors into my version of the paper, and deal with conflicts (if necessary by discussing via email with the co-authors in question).
5. Repeat from point 2 until done. For me, typically 2 or 3 iterations are enough but with difficult people this number can go up dramatically.
6. Convert paper to final format (decided by journal requirements). Make sure you do this only once, at the very end.

If this sounds complicated you are right. But to me this is the least complicated way unless everybody agrees to use the same software and version control (which is rare). Especially if reference management software is involved it can become a terrible mess when co-authors start to add/mess with references.

The main advantages of this method:

• There is a single current version of the paper and I (as first author) always have it.
• I can use version control, even if nobody else does.
• Everybody can use whatever tools they want.

I found that one person being in control of the writing and merging avoids endless discussions and ending up with multiple versions of the paper.

If people take too long to reply I send them an updated version with the others' corrections: this will show them that others have done their job and hopefully incite them to reply as well. Also, some of their potential comments may already have been addressed in the new version.

Answer 3

Use Google Docs or a Wiki (see http://www.wikimatrix.org/ )

Agree on a detailed style guide. Agree on one voice. Decide on who should have the final say over edits. Know the requirements from your desired publisher, or journal. And decide on who should format everything. It will be more consistent if only one person does that part too.

To use the wiki matrix, start with the choice wizard, then refine your choice based on special features you might need, like MathML, file uploading, and/or a markup language that can easily be exported to LaTeX.

To track changes, make the "Recent Changes" page of your wiki your home page, or turn on email notifications assuming you don't mind the deluge of emails.

Your manuscript may not look that great on a wiki, but that can be a benefit too. There is no point in obsessing over the formatting of the content until the content has mostly been finalized.

Answer 4

In case you are working with LaTeX, there are two very good (free!) sites offering collaboration functionality: Overleaf and ShareLaTeX. In fact, they are in the process of merging their services. Overleaf apparently does not restrict the number of collaborators. Additionally, it features git support!

Both offer online compiling (no need for local installation). You can simultaneously edit your document with several authors at once and even track their cursor and what they type. It has a chat, comments and version history. Which one of them you are using will most likely not matter, they have a very similar feature list and will eventually become one.

Downside: One of you might have to purchase a paid subscription to have a higher number of collaborators. But usually you get a better deal when you are from a university or similar institution. Referral links (at least on ShareLaTeX) can also get you to a higher number of collaborators without paying, but you will need to send referral links to your co-authors.

I recently used ShareLaTeX to work with one co-author and it was really pleasing. I even use it for myself, just because I dislike most Tex editors.

Answer 5

From my experience and to elaborate on @buzjwa's comment:

I have used overleaf to collaboratively write papers multiple times. As mentioned above, the free version allows an unlimited number of collaborators and even contribution without an account is possible (more on that below). And while overleaf is far from perfect, I have not yet found a better option, especially when cooperating with researchers form other fields.

After you created a free overleaf project you get (long and cryptic) links to read-only and read-write version of the document that you can pass out to contributors. Please note that the free version does not support protected repositories, so everyone who gets his hand on that link can view/ edit your document.

Additionally each overleaf project has a git repo that you can check out and a rich text mode. This allows people with different preferences to work together. (I for myself prefer working offline and pushing my changes with git.) One downside of this is that git implementation used does not support branches and tags.

Answer 6

I routinely am a co-author on papers with 10-16 authors, as is the norm in my field (biology/molecular biology; I just counted, and in the past 12 months, about a dozen papers, I averaged 11.1 authors). The process I use is by no means ideal, but it is very much a standard in my fields.

With more than three or four authors, it's not expected that most will be heavily involved in the writing process. A "middle" author -- that is, one other than the last author (senior) and first author (who did the bulk of the work) -- typically gets a near-final draft and is asked for input on that. They'll often find a block in the Methods and the Results section commenting something like "JESSICA - please fill in details of mouse examinations" or something like that, and we expect a detailed couple paragraphs there, but the implication is that aside from their specialty, we're looking for typos and minor changes and not much more.

(If a middle author has serious concerns, of course we pay attention. But if the draft is accurate and reasonably well written, it's not expected that a middle author will offer major revisions.)

That means that you're really doing the bulk of the manuscript prep with two, or perhaps three, main writers, which makes life a lot easier; which is important, because what just about everyone does is pass Word documents back and forth and use "Track Changes". Sometimes we use shared folders (Dropbox equivalents); sometimes we use email. In either case we typically keep a list of drafts; one set of revisions come back, we save as "v3" and then "Accept revisions" and call that version "v4", and so on.

We never work simultaneously. One person makes all their comments, tells the next "Your turn", and waits until all those changes are made.

Eventually, usually after three or four passes, this turns into a draft that can go out to middle authors. Here, because we don't expect major changes, we typically do get simultaneous changes, and just incorporate them all together.

We often send to the couple of authors who we know are likely to make more changes first (Jessica is really good at identifying logical flow problems; James is British and has language eccentricities), incorporate changes from them, and after that send to the people who are likely to just catch typos.

Again, this is all using Word Track Changes, which I know has many problems, but it's a de facto lowest common denominator; everyone has it, everyone knows how to use it, it's easier than trying to teach one (or 11) people how to use Git or whatever. More computation-heavy fields probably use different approaches. When I'm a middle author on a paper, this is what I expect, and it's what I invariably get. It sounds like it should be a mess, but since it's what everyone is used to it generally goes pretty smoothly. It's been years since the logistics of working with co-authors has been an issue for me.