Post History
First off, technical non-writers make better technical writers, than non-technical writers do. They usually can write in a way mostly understandable to layman and factually correct (as opposed to n...
Answer
#3: Attribution notice added
Source: https://writers.stackexchange.com/a/10053 License name: CC BY-SA 3.0 License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision
First off, technical non-writers make better technical writers, than non-technical writers do. They usually can write in a way _mostly_ understandable to layman and factually correct (as opposed to non-technical writers who'll often write something perfectly clear, but completely wrong), they just need to be asked to do so - they won't, if they don't know they should! Instead of non-technical people assembling the notes, have technical people tasked with assembling them in a relatively reader-friendly manner. Best, if everyone in the team wrote short release notes on everything they did in person, every bug they filed, asked to explain it in relatively non-technical manner (typical to release notes - they know what release notes are). It's 10 minutes of work per month, and you have a good preliminary draft almost complete. Only then have the non-technical writer edit the draft, making it pretty, correcting errors or smoothing out still too technical language. If something is hard to understand, consult, perform the usual back-and-forth, but the number of these cases should drop to 2-3 per iteration from dozens. Simply, instead of asking the non-technical writers to reach across the chasm to the professionals, have them meet halfway - essentially, everyone becomes the writer, but you're getting one good editor.