TITLE: Methods of writing and collaboration
DATE: 2017-11-01
AUTHOR: John L. Godlee
====================================================================


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:

-   Google Doc which colleagues are invited to edit through an 
emailable link
-   Microsoft Word document which is passed around colleagues for 
edits, which are done using track changes and comments, then sent 
back to me for consideration.

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:

-   Markdown
-   LaTeX

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.