forked from matrix/element-web
68 lines
2.6 KiB
Markdown
68 lines
2.6 KiB
Markdown
# Review Guidelines
|
||
|
||
The following summarises review guidelines that we follow for pull requests in
|
||
Riot Web and other supporting repos. These are just guidelines (not strict
|
||
rules) and may be updated over time.
|
||
|
||
## Code Review
|
||
|
||
When reviewing code, here are some things we look for and also things we avoid:
|
||
|
||
### We review for
|
||
|
||
* Correctness
|
||
* Performance
|
||
* Accessibility
|
||
* Security
|
||
* Comments and documentation where needed
|
||
* Sharing knowledge of different areas among the team
|
||
* Ensuring it's something we're comfortable maintaining for the long term
|
||
|
||
### We should avoid
|
||
|
||
* Style nits that are already handled by the linter
|
||
* Dramatically increasing scope
|
||
|
||
### Good practices
|
||
|
||
* Use empathetic language
|
||
* See also [Mindful Communication in Code
|
||
Reviews](https://kickstarter.engineering/a-guide-to-mindful-communication-in-code-reviews-48aab5282e5e)
|
||
and [How to Do Code Reviews Like a Human](https://mtlynch.io/human-code-reviews-1/)
|
||
* Authors should prefer smaller commits for easier reviewing and bisection
|
||
* Reviewers should be explicit about required versus optional changes
|
||
* Reviews are conversations and the PR author should feel comfortable
|
||
discussing and pushing back on changes before making them
|
||
* Core team should lead by example through their tone and language
|
||
* Take the time to thank and point out good code changes
|
||
* Using softer language like "please" and "what do you think?" goes a long way
|
||
towards making others feel like colleagues working towards a common goal
|
||
|
||
### Workflow
|
||
|
||
* Avoid force pushing to a PR after first round of review
|
||
* Use merge commits when landing
|
||
* PR author merges after review (assuming they have write access)
|
||
* Assign issues only when in progress (don’t overly assign things so it’s clear
|
||
that anyone on the team can pick up)
|
||
|
||
## Design and Product Review
|
||
|
||
We want to ensure that all changes to Riot fit with our design and product
|
||
vision. We often request review from those teams so they can provide their
|
||
perspective.
|
||
|
||
In more detail, our usual process for changes that affect the UI or alter user
|
||
functionality is:
|
||
|
||
* For changes that will go live when merged, always flag Design and Product
|
||
teams as appropriate
|
||
* For changes guarded by a feature flag, Design and Product review is not
|
||
required (though may still be useful) since we can continue tweaking
|
||
|
||
As it can be difficult to review design work from looking at just the changed
|
||
files in a PR, authors should be prepared for Design and / or Product teams to
|
||
request a link to an ad-hoc build of Riot (hosted anywhere) that can be used for
|
||
the review. In the future, we [hope to automate
|
||
this](https://github.com/vector-im/riot-web/issues/12624) for every PR.
|