TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
FROM LIN:
"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 | https://techwhirl.com
