@@ -15,23 +15,26 @@ Watch a presentation that covers this material from [Derek Prior at RailsConf 20
15
15
- ** Good questions avoid judgment and avoid assumptions about the author's
16
16
perspective**
17
17
- ** Ask for clarification**
18
- - "I didn't understand. Can you clarify?"
18
+ - "I didn't understand. Can you clarify?"
19
19
20
20
- ** Avoid selective ownership of code**
21
- - "Mine", "not mine", "yours"
21
+ - "Mine", "not mine", "yours"
22
22
23
23
- ** Avoid using terms that could be seen as referring to personal traits**
24
24
- "Dumb", "stupid".
25
25
- Assume everyone is intelligent and well-meaning.
26
26
27
+ - ** Avoid diminishing words**
28
+ - "simply", "simple", "just"
29
+
27
30
- ** Be explicit**
28
- - Remember people don't always understand your intentions online.
31
+ - Remember people don't always understand your intentions online.
29
32
30
33
- ** Be humble**
31
- - "I'm not sure - let's look it up."
34
+ - "I'm not sure - let's look it up."
32
35
33
36
- ** Don't use hyperbole**
34
- - "Always", "never", "endlessly", "nothing"
37
+ - "Always", "never", "endlessly", "nothing"
35
38
36
39
- ** Don't use sarcasm**
37
40
- ** Keep it real**
@@ -43,8 +46,12 @@ Watch a presentation that covers this material from [Derek Prior at RailsConf 20
43
46
- Post a follow-up comment summarizing the discussion.
44
47
45
48
- ** If you learned something new, share your appreciation**
46
- - "I did not know about this. Thank you for sharing it."
49
+ - "I did not know about this. Thank you for sharing it."
47
50
51
+ - ** Avoid the "since you're at it" attitude**
52
+ - If you would like to recommend a code change unrelated to the current
53
+ pull request, suggest it in the appropriate place or open a ticket for it
54
+ (on Trello, JIRA, GitHub project...)
48
55
49
56
## Having Your Code Reviewed
50
57
@@ -71,11 +78,14 @@ Watch a presentation that covers this material from [Derek Prior at RailsConf 20
71
78
- ** Seek to understand the reviewer's perspective**
72
79
- ** Try to respond to every comment**
73
80
- ** Wait to merge the branch until continuous integration tells you the test suite is green in the branch**
74
- - TDDium, Travis CI, CircleCI, Github Actions, etc.
81
+ - TDDium, Travis CI, CircleCI, GitHub Actions, etc.
75
82
76
83
- ** Merge once you feel confident in the code and its impact on the project**
77
84
- ** Final editorial control rests with the pull request author**
78
85
86
+ - ** Recognize the work of your teammates when you are pairing**
87
+ - Use ` Co-Authored-By: <name> <email> ` at the end of your commit message.
88
+
79
89
## Reviewing Code
80
90
81
91
Understand why the change is necessary (fixes a bug, improves the user experience, refactors the existing code).
@@ -114,6 +124,12 @@ If you disagree with a guideline, open an issue on the guides repo rather than d
114
124
115
125
This helps us have more meaningful conversations on PRs rather than debating personal style preferences.
116
126
127
+ - ** Leave one comment only, for multiple stylistic offenses of the same kind**
128
+ - If there are a few occurrences of the same change needed, do not
129
+ leave multiple comments for the same change, rather suggest running the linter,
130
+ and/or leave one comment only, mentioning the line and elsewhere,
131
+ as long as the other files are being edited in the pull request.
132
+
117
133
[ challenging to convey emotion and intention online ] : https://thoughtbot.com/blog/empathy-online
118
134
[ using labels ] : https://conventionalcomments.org
119
135
[ standard ] : https://github.com/testdouble/standard
0 commit comments