|
1 |
| -# How To Review Someone's Work |
| 1 | +# How to be a great peer reviewer |
2 | 2 |
|
3 | 3 | When you first start your technical writing journey, one of the many important skills you'll need to learn is how to do is peer reviews. It's a skill that will not only teach you how to collaborate with other technical writers and other people who interact with documentation, but it will also help you to become a better technical writer in the long run.
|
4 | 4 |
|
5 |
| -## Peer Reviews vs. Code Reviews: What's the difference? |
| 5 | +## Tips for doing effective Peer Reviews |
6 | 6 |
|
7 |
| -Even though peer reviews and code reviews are often used interchangeably, there are some key differences between the two. Peer reviews are often more personal and more focused on the quality of the work, while code reviews are more focused on the quality of the code. |
| 7 | +When it comes to peer reviews, it can get confusing and overwhelming at times because you want to be effective, but at the same time you don't want to give too much feedback to point that the TA is confused. Consider using this checklist of things to keep in mind when doing peer reviews: |
8 | 8 |
|
9 |
| -## Tips for doing effective Peer Reviews |
| 9 | +### Content Review |
| 10 | + |
| 11 | +* **Overall structure and flow**: |
| 12 | + * Are the steps in the correct order? |
| 13 | + * Will the user be able to understand the steps? |
| 14 | + * Have all the terms been defined at the first use? |
| 15 | +* **Accuracy and completeness**: |
| 16 | + * Are all the steps accurate? |
| 17 | + * Are there any steps missing or unclear? |
| 18 | + * If you run through the document from start to finish, does it work? |
| 19 | + |
| 20 | +### Clarity and Readability |
| 21 | + |
| 22 | +* **Wording and clarity**: |
| 23 | + * Is everything well worded? |
| 24 | + * Are there any unclear bits? |
| 25 | + * Can anything be made shorter? |
| 26 | + * Does the tone suit the message? |
| 27 | +* **Formatting and consistency**: |
| 28 | + * Are headings and subheadings used consistently? |
| 29 | + * Are lists and tables used effectively? |
| 30 | + * Are images and diagrams used to support the text? |
10 | 31 |
|
11 |
| -When it comes to peer reviews, there are a few things that you can do to make them more effective. Here are some tips: |
| 32 | +### Mechanics and Style |
12 | 33 |
|
13 |
| -- **Categorize the kind of feedback you're giving:** Use the feedback template to categorize the kind of feedback you're giving. For example, if you are asking the reader a question about the content, you would use the following template: |
| 34 | +* **Spelling and grammar**: |
| 35 | + * Are there any spelling or grammar errors? |
| 36 | + * Are punctuation and capitalization consistent? |
| 37 | +* **Style and tone**: |
| 38 | + * Is the tone consistent throughout the document? |
| 39 | + * Are there any areas where the tone could be improved? |
14 | 40 |
|
15 |
| -```markdown |
16 |
| -[question]: what is the purpose of this section? |
17 |
| -``` |
| 41 | +### Additional Checks |
18 | 42 |
|
19 |
| -This method will make it easier for the reader to understand what you're asking them to do. |
| 43 | +* **Links and references**: |
| 44 | + * Are all links working correctly? |
| 45 | + * Are references properly cited? |
| 46 | +* **Code and examples**: |
| 47 | + * Do code snippets work as expected? |
| 48 | + * Are examples relevant and effective? |
20 | 49 |
|
21 |
| -- **Be objective as much as possible:** Behind every piece of documentation is a person, so it's crucial to be mindful of your wording and tone when giving feedback. For example, if you noticed that a section is missing a code snippet or a key detail about the product, it would be ineffective to say, "This section stinks." Consider pointing out the strengths of the work and the areas that could be improved. For example, "this section describes the steps effectively, but the screenshots are missing alt text." |
| 50 | +## Conclusion |
22 | 51 |
|
23 |
| -- **Be clear and specific:** When giving feedback, be clear about what you're looking for. For example, if you noticed that the content is missing a code snippet, you should say, "this section is missing a code snippet." as opposed to "this section is missing content." |
24 |
| -- **Be concise:** While getting every detail correct is important, don't go overboard with your feedback. The person you're giving feedback might get overwhelmed with too much information. Keep it short and to the point. For example, if you're asking the reader to explain a concept, keep it to one sentence or two. |
| 52 | +The end goal of reviewing is to make sure that the work is a) correct/accurate, and b) the best version of itself (for now). The nature of online documentation is that it's 100% going to change at some point, so it's important to keep a good eye on the work as it's being written |
0 commit comments