Guest post by my former PhD student Thomas Guillerme on collaborative science.

Recently, along with Adam Kane, Kevin Healy, Graeme Ruxton and Andrew Jackson we published a review on scavenging behaviour in vertebrates through time in Ecography. This paper was my first review paper as well as my first paper written from afar, without ever actually meeting in a room with the co-authors for working on the project.

Difficulty: *

Preparation time:

5 month to submission

Serves:

5 people (but any manageable number of people who you like working with will do)

Ingredients:

An exciting topic

For this recipe you will need an exciting topic. In this case, prior to writing the review, we had often discussed the prevalence of scavenging behaviour through time and what ecological factors influence it. Indeed, it came as a natural follow up to a paper published by the other co-authors earlier this year on the scavenging ability of theropod dinosaurs.

More generally, the topic should be broad enough to allow every person to look for anecdotes (did you know there was once a scavenging bat called Necromantis?) and to bring these together in an interesting, generalisable framework.

Online collaboration software:

As is often the case, coauthors will be based in different intitutions, so online collaboration tools are vital for the smooth writing of a paper. This was certainly true for us. The idea is to efficiently communicate on who does what and when, as well as to identify what still remains to be done.

The classic way would have been to take turns editing the draft and then send around a pdf (or, God forbid, a Word document!) ending with the initials of the last writer. That can easily look as unappetising as this: scavenger_draft_AK_TG_KH_final.pdf (with a folder containing a recycle bin of every version including the ‘‘dead-end’’ ones).

Thankfully, a magical solution exists already: version control! In our case we used GitHub for a smooth and efficient writing experience, where each task could be properly saved and explained.

To version control crack users, the last link may come as a surprise (‘‘what the flipidyflop?! All on one branch?!’’[1]) but such version control heresy was also made smooth ‘n’ easy by using online chatting tools such as Slack.

This tool is nothing more than a glorified messenger but saves sooooo much hassle! As many of you might have experienced, when collaborating, the easiest way to stay in contact might be through email (these have the advantage of being saved and short, c.f. skype conversations) but you can quickly end up with an email thread 350 emails long without the capacity of efficiently searching through them.

By contrast, using a messenger like Slack allows to keep all the messages saved in a single chat conversation where you can easily retrieve all the details regarding which task was assigned when and by who and actually, in our case, who’s working on the GitHub main branch and what is he doing…

Fun

Don’t forget a generous pinch of it!

Instructions:

1. Get everybody to agree to set aside some regular time to work on it (like two hours per week or more).
2. Run the ‘‘sausage making’’ of writing papers the way you like it.
3. Combine the writings of every author into a coherent narrative (under the direction of your favourite lead author).
4. Submit, correct, publish.

Et voilà…

^[1] To the non-crack version control users, a branch in version control is like a specific time-line for your file: it contains all the versions of this file for a specific task. For example, one person can be working on writing the intro (thus working on the ''intro-branch'') while another can be working on the figure (you got it, ''figure-branch''). Once everybody is happy with the development of these two branches, they can be merged together into a single new version (with a nice intro and a nice figure).

Photo credit: Copyright Andre Botha 2015.

Original post