Re: TECHWR-L Digest, Vol 181, Issue 9

Subject: Re: TECHWR-L Digest, Vol 181, Issue 9
From: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
To: "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 12 Nov 2020 07:40:46 +0000 (UTC)

I'd like to address a couple of statements...

"We teach a class on Git and Git Hub in the Seattle are via STC's Puget Sound Chapter and I would say this is a tool for technical writers with a call towards working with developers and code. Those who don't would want another solution."
Yes, GIT is pretty technical. We had it imposed on us -- in our small team with a good range of "predilection" toward developers and code. It took a little doing to ramp up, but everybody got on board and became perfectly productive. In the end, the openness of our process plus the connection with development turned out to be powerful.
Definitely, you need one admin to keep a GIT-based tool chain healthy and responsive. In my experience, the rest of the team can chug along without too much concern.

FROM ROBERT:"Adopting Markdown + Git without evaluating your requirements and
comparing alternatives is the 2020 version of 2005's adopting DITA
without evaluating your requirements and comparing alternatives."
Love the hyperbole, but... Adopting ANY tool chain without evaluation is a bad idea. I thought the question was asking for alternatives to evaluate. Any text-based format would work well with GIT.
We found the GIT paradigm to be really good. (Want to try something out? Create a branch!) We've had to resolve a very few merge conflicts. But overall, for us, the positives have outweighed the negatives by far. For us it hasn't turned out to be a "make it work if you have to." We're totally drinking the Kool-Aid at this point. It works that well.
I agree that the bigger DITA solutions can be at least as siloed as Confluence. IMO, they have business incentives to stay that way. We OEM to other companies that use DITA, and they cannot (or will not -- not sure) push our stuff through their tool chain unless we adopt the same tool chain. This is opposite to the purpose of SGML/XML.Â

BTW, of the big systems I've seen, ZoomIn seems the most open. If you have the budget, take a look at that.

An open system should support any authoring, any input, any source management, and any output. We author in whatever. We ingest content from Jira, Moodle, source code, and real-time processing. Our output is PDF, HTML, and JSON -- sometimes Word. And we can merge our content in the product GUI, real-time. BTW, our initial evaluation did not predict everything that we currently do. But the openness of the system left the possibilities open to be exploited.
But I digress... The question was about evaluating other possibilities. GIT => Markdown => Static Web and PDF is one possibility. There's a lot of literature about how to make it work. Take a look and see...

Visit TechWhirl for the latest on content technology, content strategy and content development |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

Previous by Author: Re: Content Management ... was RE: Tools
Next by Author: Visual Insertion Order (Ticketing) System
Previous by Thread: Re: Content Management ... was RE: Tools
Next by Thread: Tools for SAP Report Writing?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads