Methods of writing and collaboration


Just recently I’ve been having to send lots of short reports and essays to my supervisors, to get their comments on things before I start writing my confirmation report for my PhD, which will porbably happen late next spring sometime. This has led me to think quite a lot about the best ways to collaborate, what are the best ways to write efficiently, what are the tradeoffs between these aspects of writing.

In the past I’ve used the following systems to share work between colleagues:

The issue with these methods is that they don’t align with the ways that I like to write when I’m writing for myself, which are:

Both of which I like to edit using VIM, my chosen plain text editor. I like Markdown and LaTeX because the file sizes are small, I can use version control software like Git, I find the writing style more focussed if I don’t have to worry too much about formatting as I’m writing, and I know that plain text will always be readable, even when Microsoft Word versions have lost their backwards compatibility and Google has gone out of business (unlikely, but possible).

Wouldn’t it be good if there was a method of doing track changes on plain text documents? Well there is, it’s Git combined with git diff, but unfortunately lots of people seem to be scared of Git, and even those colleagues that I’ve come across who know about Git don’t seem to make the connection that it can be used for more than just code editing. In fact, Git with git diff is even better than Track Changes or Google Docs in some senses. In track changes, you can’t pass the document around multiple co-authors simultaneously and have them always be looking at the most up to date version, instead you get lots of comments back that are increasingly out of date as time goes on and the document evolves. In Google Docs and track changes, it’s not so simple to see the version history of a document like you can with git log. Yes, Google Docs has a version history, but it’s not nearly as powerful as git diff combined with git log.

Unfortunately however, I don’t know the best way to get people to use Git and plain text for their document editing, I think most of it is fear of something that looks techy on the command line, but then some of it I think is the lack of a GUI meaning that you have to learn commands, whether that’s using git log, git merge, git diff etc. to control versions, or using underscores for italics, and hashes for headers etc..

aybe the answer is some sort of GUI that incorporates markdown syntax highlighting, git version control, a markdown previewer and pandoc suite, so that the user doesn’t even know what is going on in the background, unless they want to, then the program should be wide open for tinkering. Maybe one of the GUI plain text editors like Sublime or Atom could have an extensive overhaul to serve this purpose. There may even have already been attempts, and I just haven’t heard of them.