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.
