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

50%
+0 −0
Q&A What is in scope for criticizing technical writing

This answer covers a single work like a paper well, and what it says applies to larger works too. Correctness and clarity are the most important factors in any technical work. For larger works, su...

posted 5y ago by Monica Cellio‭  ·  last activity 4y ago by System‭

Answer
#3: Attribution notice added by user avatar System‭ · 2019-12-08T11:05:56Z (over 4 years ago)
Source: https://writers.stackexchange.com/a/42881
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision by (deleted user) · 2019-12-08T11:05:56Z (over 4 years ago)
[This answer](https://writing.stackexchange.com/a/42850/1993) covers a single work like a paper well, and what it says applies to larger works too. Correctness and clarity are the most important factors in any technical work. For larger works, such as a new section in a large documentation set, I look for some additional things:

- **Consistency of style:** Does this part fit seamlessly into the larger body of which it's a part? Ideally there is a house style guide, so what we're checking here is adherence to it. But, beyond that, if there are themes running through the larger work, such as an example domain that all the examples use, does this piece fit into that?

- **Cross-references:** Very few pieces of technical documentation exist in a vacuum. Does this new part link to (or reference) other parts where needed? On my team, for example, we have reference pages for all the commands, functions, system tables, and so on that our product supports; when reviewing task/guide documentation, I expect to see links to the relevant references pages.

When providing feedback on a larger work in its entirety (which is a huge task), I pay particular attention to:

- **Table of contents:** Do the order and divisions into subtopics make sense? Is the structure reasonably balanced? For example, I don't want to see 30 top-level topics and then two topics each that have children out to six levels. You shouldn't impose arbitrary limits (I said _reasonably_ balanced), but if your organization seems really out of whack, that can signal problems with the content itself, too.

- **Index** (if present): I'll scan to see if similar things are in fact grouped together; I don't want to see "get" (15 subentries), "getting" (12 more), and "retrieving" (3 more). I look for a good mix of nouns and verbs. I'll pick a few entries at random, follow them, and see if where I landed makes sense.

#1: Imported from external source by user avatar System‭ · 2019-03-03T02:38:35Z (about 5 years ago)
Original score: 4