You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: