Mfrhtyj

What is an effective way to organize collaborations with several people on the same paper? How do you arrange the $LaTeX$ document, the shared (digital) papers library, and other aspects?

More in general, remarks on how to set up an effective collaborations are very welcome too.

I can tell you one arrangement that I don't like so much, used by someone I collaborated with once. The idea was that there would be a LaTex file containing everything we had, all results, maybe some speculations, etc. At any given time one of the coauthors would be designated the "editor" and would have control of the file and be responsible for adding new material to it. Depending on who was most active at the moment, or who was more familiar with the subject of interest at the moment, editorship could change.

It sounded like a good way to do things, with the clear advantage that one always had an accessible summary of what had been done up to that point. But in the end I felt that this method tended to bias the final paper toward a particular style --- an "everything but the kitchen sink" paper. Whereas my preference, usually, is for clarity and elegance, to the extent one can achieve this. And that might mean leaving minor results or dead ends out.

The coauthored papers I'm happiest weren't developed in any special way. Just emails would be sent back and forth, and sometimes you would have to dig through old emails to find something done earlier. When we felt the project was complete one person would volunteer to write it up, and then the other or others would suggest changes. I think this is a personal thing and there's no one right answer.

For writing the LaTeX document, here are several options I've seen used:

• The "cleanest" and safest option is a git repository (on github or gitlab or bitbucket or, the good old way, on someone's server). Example with 3 authors. Example with 1 author (it's useful even then). Now, git isn't magic -- it will not guarantee that everyone writes in a common style, or that notations match; it will not resolve your disagreements about good writing; it also will not merge changes made in parallel to the same piece of the text (it will only alert you that such conflicting changes exist). But it removes various dangers such as losing your changes because your collaborator overwrites them, and it makes the history of the document readily available (though, in order to see the changes on github, your lines shouldn't be too long -- standard "mistake"). Also, branching allows you to experiment and make edits that your collaborators won't like until they see the final form, without raising the ire of your collaborators for (temporarily) messing up the work. I also found it very helpful when responding to referees -- with a clean history, I can easily list all my changes between two given dates. The biggest disadvantage of git is that people have to learn it (naturally, combinatorialists and computer scientists have the easiest time doing so), and that merge commits are confusing (I think, even to experts -- try debugging a merge gone wrong!).




• A classical tactic, mentioned by @NikWeaver, is the "editing baton" (i.e., at each moment, at most one of the authors is editing the file, and the others are made aware that they should not be making changes; once done, the author emails the new version to all collaborators). I have seen it used a few times; my impression is that it works well when there are few authors and few changes to make and the "baton" doesn't change hands too often; but once things get complicated, it's a matter of time until confusion arises as to who is holding the "baton". Also, people forget to download the email attachments sometimes, or download them into the wrong place, etc. I cannot recommend this for projects where you foresee lots of editing.




• The document is kept on the dropbox servers, in a folder that can be accessed and modified by all collaborators. This, per se, is not a safe strategy, since dropbox still allows people to overwrite each others' changes, and even when a conflict (i.e., two parallel changes by different authors) is spotted by dropbox, the way to resolve the conflict isn't particularly explicit (or is it now?). It is best combined with the "editing baton" to ensure that edits don't happen simultaneously. Also, make sure to have dropbox always running, to avoid situations where you edit the file but it stays local to your machine.




• The federalist strategy: Each collaborator is in charge of their own well-delineated part (chapters or sections) of the work. Every once in a while, these parts are glued together into a draft. "Border-crossing" changes are made only when the authors come together (in meatspace or on IRC/skype/discord/whatever). This strategy works well when the project really splits into mostly self-contained parts; still, the result is likely to look heterogeneous.

I have never been involved in a project using Overleaf, so I can't comment on it. I suspect that it's somewhere between the github and dropbox workflows -- not as explicit as github, but you see each other making edits and thus can avoid stepping on each other's toes.

For a shared library of papers, a folder on dropbox will do.