How to organize collaborations? Managing shared library and LaTeX document












9














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.










share|cite|improve this question
























  • Indeed, this question even makes sense for a single person working on a single paper or multiple papers.
    – Somos
    Jan 5 at 23:00










  • ( I answered this question thinking it was about how to arrange an effective collaboration, but on re-reading I see that it's more about file sharing, so I deleted that answer.)
    – Nik Weaver
    Jan 5 at 23:28






  • 8




    I like this tool: overleaf.com
    – David G. Stork
    Jan 6 at 0:24






  • 2




    Sounds off-topic to me, there are more appropriate forums.
    – YCor
    2 days ago






  • 4




    @andrejbauer will probably say: github. math.andrej.com/2013/06/20/the-hott-book
    – Matt F.
    2 days ago
















9














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.










share|cite|improve this question
























  • Indeed, this question even makes sense for a single person working on a single paper or multiple papers.
    – Somos
    Jan 5 at 23:00










  • ( I answered this question thinking it was about how to arrange an effective collaboration, but on re-reading I see that it's more about file sharing, so I deleted that answer.)
    – Nik Weaver
    Jan 5 at 23:28






  • 8




    I like this tool: overleaf.com
    – David G. Stork
    Jan 6 at 0:24






  • 2




    Sounds off-topic to me, there are more appropriate forums.
    – YCor
    2 days ago






  • 4




    @andrejbauer will probably say: github. math.andrej.com/2013/06/20/the-hott-book
    – Matt F.
    2 days ago














9












9








9


2





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.










share|cite|improve this question















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.







reference-request soft-question career






share|cite|improve this question















share|cite|improve this question













share|cite|improve this question




share|cite|improve this question








edited yesterday


























community wiki





5 revs, 2 users 57%
Dal













  • Indeed, this question even makes sense for a single person working on a single paper or multiple papers.
    – Somos
    Jan 5 at 23:00










  • ( I answered this question thinking it was about how to arrange an effective collaboration, but on re-reading I see that it's more about file sharing, so I deleted that answer.)
    – Nik Weaver
    Jan 5 at 23:28






  • 8




    I like this tool: overleaf.com
    – David G. Stork
    Jan 6 at 0:24






  • 2




    Sounds off-topic to me, there are more appropriate forums.
    – YCor
    2 days ago






  • 4




    @andrejbauer will probably say: github. math.andrej.com/2013/06/20/the-hott-book
    – Matt F.
    2 days ago


















  • Indeed, this question even makes sense for a single person working on a single paper or multiple papers.
    – Somos
    Jan 5 at 23:00










  • ( I answered this question thinking it was about how to arrange an effective collaboration, but on re-reading I see that it's more about file sharing, so I deleted that answer.)
    – Nik Weaver
    Jan 5 at 23:28






  • 8




    I like this tool: overleaf.com
    – David G. Stork
    Jan 6 at 0:24






  • 2




    Sounds off-topic to me, there are more appropriate forums.
    – YCor
    2 days ago






  • 4




    @andrejbauer will probably say: github. math.andrej.com/2013/06/20/the-hott-book
    – Matt F.
    2 days ago
















Indeed, this question even makes sense for a single person working on a single paper or multiple papers.
– Somos
Jan 5 at 23:00




Indeed, this question even makes sense for a single person working on a single paper or multiple papers.
– Somos
Jan 5 at 23:00












( I answered this question thinking it was about how to arrange an effective collaboration, but on re-reading I see that it's more about file sharing, so I deleted that answer.)
– Nik Weaver
Jan 5 at 23:28




( I answered this question thinking it was about how to arrange an effective collaboration, but on re-reading I see that it's more about file sharing, so I deleted that answer.)
– Nik Weaver
Jan 5 at 23:28




8




8




I like this tool: overleaf.com
– David G. Stork
Jan 6 at 0:24




I like this tool: overleaf.com
– David G. Stork
Jan 6 at 0:24




2




2




Sounds off-topic to me, there are more appropriate forums.
– YCor
2 days ago




Sounds off-topic to me, there are more appropriate forums.
– YCor
2 days ago




4




4




@andrejbauer will probably say: github. math.andrej.com/2013/06/20/the-hott-book
– Matt F.
2 days ago




@andrejbauer will probably say: github. math.andrej.com/2013/06/20/the-hott-book
– Matt F.
2 days ago










2 Answers
2






active

oldest

votes


















11














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.






share|cite|improve this answer























  • Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
    – Dal
    2 days ago





















10














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.






share|cite|improve this answer























    Your Answer





    StackExchange.ifUsing("editor", function () {
    return StackExchange.using("mathjaxEditing", function () {
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
    });
    });
    }, "mathjax-editing");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "504"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathoverflow.net%2fquestions%2f320179%2fhow-to-organize-collaborations-managing-shared-library-and-latex-document%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    11














    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.






    share|cite|improve this answer























    • Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
      – Dal
      2 days ago


















    11














    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.






    share|cite|improve this answer























    • Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
      – Dal
      2 days ago
















    11












    11








    11






    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.






    share|cite|improve this 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.







    share|cite|improve this answer














    share|cite|improve this answer



    share|cite|improve this answer








    answered 2 days ago


























    community wiki





    darij grinberg













    • Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
      – Dal
      2 days ago




















    • Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
      – Dal
      2 days ago


















    Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
    – Dal
    2 days ago






    Thank you. Your answer is very comprehensive and helpful. However, I'm kind of saddened to see that all these solutions seem to be suboptimal at best. I like the first one the most, but many coauthors have difficulties or unwillingness in using git repositories (or similar tools).
    – Dal
    2 days ago













    10














    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.






    share|cite|improve this answer




























      10














      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.






      share|cite|improve this answer


























        10












        10








        10






        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.






        share|cite|improve this answer














        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.







        share|cite|improve this answer














        share|cite|improve this answer



        share|cite|improve this answer








        answered Jan 5 at 23:26


























        community wiki





        Nik Weaver































            draft saved

            draft discarded




















































            Thanks for contributing an answer to MathOverflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathoverflow.net%2fquestions%2f320179%2fhow-to-organize-collaborations-managing-shared-library-and-latex-document%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            Origin of the phrase “under your belt”?