Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What Docs Are -- Purview #24

Open
lief-erickson opened this issue Jul 29, 2018 · 0 comments
Open

What Docs Are -- Purview #24

lief-erickson opened this issue Jul 29, 2018 · 0 comments

Comments

@lief-erickson
Copy link

I also have a broad definition of what falls under the purview of technical documentation management.
I prefer to be within one hop of every significant technology document the Engineering organization touches, from knowledge base articles to slide decks to drafts of blog posts and white papers.

I would go even further and suggest that bill of materials and build documentation (for hardware products) and code comments should also be considered, among other things that are not considered traditional "documentation." These are closer to "the source," since it actually is the source. We are all about single-sourcing, right? The source doesn't have to be a single, massive repository. In fact, it likely will never be. Instead, pulling together content from numerous silos, where each silo is maintained by its experts using tools they're familiar with.

A crafty DocOps person will query the BOM to build the latest-and-greatest list that users can use to confirm they received everything needed. If the BOM isn't up to date, that's not the tech writer's fault, but if the docs aren't it is. DocOps can help the tech writer by removing the tedious and unnecessary task of duplicating (probably through the error-prone copy-and-paste) someone else's effort. DocOps can improve the user experience, make the company more efficient while at the same time reducing the company's risk. Instead of taking the view of "documentation" DocOps should be pursuing the it's-all-content-and-it-doesn't-matter-where-it-comes-from-or-who-owns-it mentality.

I'm even aware of tools that can take structured files troubleshooting files and automatically create .svg flowcharts out of them. Would you rather read the troubleshooting or would you get through the flowchart faster with it's Yes/No branches? DocOps are the people who integrate tools like that to improve the documentarians life, but also the end user experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant