3

summary

partner A: underling, coder, Linux and FLOSS user, lives in text editor and web browser, accustomed to collaborating using git repos (local and online) and online-repo-supported markup.

partner B: boss, scientist, Mac user of Microsoft Office, accustomed to collaborating using Word version control.

How to enable partners to collaborate on some relatively short, simple documents with minimal stress to !Microsoft-user A and !power-user B?

details

partners

Partners (of which B is definitely the senior) need to collaborate on some short, simple documents. These documents

  • will not be longer than a few pages
  • will not contain (e.g.) figures/images, equations, or other serious DTP functionality.
  • should be web-publishable but will also need to be printed for some meetings.

Partner A (Pa) knows from experience that "this sort of thing" is easily accomplished with markup dialect (e.g., Markdown, MediaWiki, reStructuredText) and soft-document converters (e.g., pandoc). For collaboration, Pa would vastly prefer to manage/version the documents as markup within local and online git repos.

Partner B (Pb) is the boss; notably, Pb has "final cut" on the documents. Pb has never used any repository or any markup, even for a wiki. Pb mostly lives on Mac except for occasional Windows forays for ArcGIS, and uses mostly Microsoft tools (including Office and Outlook). Pb considers open-source and open-science "shiny objects" that are "politically correct," whereas Word version control is State of the Art for document collaboration. Pa currently lacks access to Microsoft tools, and anyway finds they make him vomit--esp Word "version control."

candidate usecase

Pa would vastly prefer a document-collaboration process that would allow "roundtripping" git+markup ↔ Word. Pa prefers reStructuredText, but would be happy to use any markup supported by any of the major online git repos (e.g., Bitbucket, GitHub) and by a reasonably-competent web- or Linux-available markup converter (e.g., pandoc). Pa envisions a usecase like the following loop:

  1. Pa authors markup, commits to repo
  2. Pa generates .docx from markup
  3. Pa forwards .docx via email attachment
  4. Pb is happy ? exit : edits .docx in Word and returns
  5. Pa generates markup from .docx. Markdown (only) can be generated from .docx with Ben Balter's ruby gem or its related website.
  6. Pa diffs current/Pb markup against previous/committed markup
  7. Pa commits current/Pb markup with comment derived from previous step (and anything else Pb may have said in email)
  8. Pa edits markup, commits to repo
  9. loop to step#=2

Note that

Pa is unfortunately unaware of a tool that can accomplish step#=5. E.g.,

questions

In order of increasing importance:

  1. Is there a tool that can convert reST → Word? In the above pipeline, the Balter tools are (IIUC) restricted to Markdown. Furthermore, in my admittedly quite-limited testing, the website's conversion was a bit wonky (esp with list items, IIRC). That being said, I am aware of literally no other tool that does this conversion. Notably, pandoc can write .docx and ODT (i.e., step#=2) but cannot read them. (Am I missing something?)
  2. Is there another way (Something Completely Different) to accomplish the Pa's goals other than the candidate usecase? Which is obviously more than a little cumbersome.
  • 1
    Not sure if tools for such a workflow exist which would satisfy A and B; but maybe consider two alternative approaches: 1) Give B a WYSIWYG markdown editor looking very similar to what he's used to, and take a WebDAV storage with versioning to save documents to, 2) Use e.g. ownCloud, which includes such an editor and does versioning in the background (documents are available then via WebDAV and the browser, can even be sync'd). – Izzy Feb 27 '16 at 11:41
  • @Izzy: alas, P_b is very Word-centric. It is the Way, the Truth, and the Light(tm). – TomRoche Mar 1 '16 at 23:57
  • locked-in to the dark side, huh? OK, chances go asymptotic to the x-axis then I'm afraid :( Unless he uses his favorite toy, but saves into RTF format – which should go easy with versioning tools (being non-binary except for "embedded image blobs" if any), and also be understood by Pandoc IIRC. But then, much formatting might be lost. – Izzy Mar 2 '16 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.