@@ -140,4 +140,30 @@ These notes are notes, not a stenographic record. They're also not spell checked
140
140
* If you _ are_ a courtroom stenographer, record everything.
141
141
* If your org has a style guide, stick to it (until you can change it).
142
142
143
- Hacking the English Language - [ Nina Vyedin] ( )
143
+ Hacking the English Language - [ Nina Vyedin] ( )
144
+
145
+ _ Or, what we can steal from programmers_
146
+
147
+ * Documentation can be helped by giving writers a default framework in which to write/work.
148
+ * Have templates for oft-written stuff: blog posts, references
149
+ * Make sure you know what question a doc is trying to answer.
150
+ * ** make a spec** for your doc and make sure everyone involved knows the specs.
151
+ * what are the questions you're answering?
152
+ * who is the audience?
153
+ * what is the current state of documentation?
154
+ * new content, existing content (including 3rd party docs)
155
+ * what's the work plan?
156
+ * who owns it, who revises it?
157
+ * adapting the idea of _ design patterns_ to writing; start a doc with an architecture. examples:
158
+ * ** tell a story** linear timeline (walkthrough)
159
+ * ** paint a picture** spapshot (introduce feature/tool)
160
+ * ** reference** introduce one at a time and describe
161
+ * ** theme + situation** idea and use cases (intro to concept)
162
+ * ** drill down** general -> specific
163
+ * ** level up** simple to complex (getting started.doc)
164
+ * Errors/name your variables
165
+ * Undefined 'it'
166
+ * No ownership (avoid magic. [ that doesn't mean no django] )
167
+ * Vague terms (don't use generic tech terms)
168
+ * Unnamed ideas
169
+ * Idea of _ refactoring_ vs _ editing_
0 commit comments