Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

60%
+1 −0
Q&A How can we make compiling release notes less chaotic?

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...

posted 11y ago by SF.‭  ·  last activity 5y ago by System‭

Answer
#3: Attribution notice added by user avatar System‭ · 2019-12-08T03:19:20Z (almost 5 years ago)
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 by user avatar SF.‭ · 2019-12-08T03:19:20Z (almost 5 years ago)
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.

#1: Imported from external source by user avatar System‭ · 2014-01-16T23:28:50Z (almost 11 years ago)
Original score: 1