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.