[Ready for review] Updates to A Reviewing section #449
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 task
|
Thank you so much @illushka ! We will get this reviewed ASAP 🎉 |
rainsworth
changed the title
|
Pinging @yochannah to review these contributions! |
|
Deploy preview for the-turing-way ready! Built with commit 521a5ae |
yochannah
reviewed
May 17, 2019
| @@ -85,10 +90,23 @@ Reviews conducted in the right spirit (see especially [here](#Be_nice)) also ser | |||
|
|
|||
| As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better. | |||
|
|
|||
| ### Avoid being subjective | |||
| Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. | |||
There was a problem hiding this comment.
Love the guidelines about documenting style guides in advance to avoid arbitrary personal preferences!
yochannah
reviewed
May 17, 2019
| Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. | ||
|
|
||
| ### Specify crucial versus optional changes | ||
| You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin "You might..." could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin "You must..." to specify those that are not optional. |
There was a problem hiding this comment.
Again, love the guidance for providing suggestions without being nitpicky over the less important bits 😻
yochannah
approved these changes
May 17, 2019
|
@illushka This is a great contribution - @KirstieJane will add you as a collaborator to the repo, then you can go ahead and merge this!! 💯 |
|
Okay great! |
|
@all-contributors please add @illushka for doc |
|
I've put up a pull request to add @illushka! 🎉 |
|
Hi @illushka, you have been added as a collaborator to the Turing Way repo so you should be able to merge this in yourself now! Thanks so much for contributing 🎉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Added additional content in order to point out some more tips on how to make code reviews even more friendly, efficient as well as how to avoid subjective disagreements.
What should a reviewer concentrate their feedback on?
Just check if the new text fits with the old one. I checked for repeated content but another eye to ensure nothing is repeated may be useful.
Acknowledging contributors
By submitting this pull request I confirm that: