paulmataruso/zulip
1
0
Fork 0
mirror of https://github.com/zulip/zulip.git synced 2025-11-04 05:53:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc: Fix typos in code reviewing doc.

Browse Source 
Made some spelling and grammatical changes.
This commit is contained in:
Rishabh-792
2022-01-06 16:58:19 +05:30
committed by Tim Abbott
parent c46dae64a8
commit 1ec018d237
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/contributing/code-reviewing.md
View File

@@ -11,7 +11,7 @@ outside of the handful of people who do a ton of reviews -- and
`@`-mention them with something like "`@person`, would you review
this?". Good choices include
- someone based in your timezone or a nearby timezone
- someone based in your time zone or a nearby time zone
- people working on similar things, or in a loosely related area
Alternatively, posting a message in
@@ -20,7 +20,7 @@ development community server](https://zulip.com/development-community/), would
help in reaching out to a wider group of reviewers. Either way, please be
patient and mindful of the fact that it isn't possible to provide a
quick reply always, but that the reviewer would get to it sooner or later.
Lastly, ensuring the your PR passes CI and is organized into coherent
Lastly, ensuring that your PR passes CI and is organized into coherent
commits would help save reviewers time, which could otherwise be used
to dive right into reviewing the PR's core functionality.
@@ -98,7 +98,7 @@ just saying you're busy and when you'll have time to look harder -- is
still really valuable for the author and for anyone else who might
review the PR.
People in the Zulip project live and work in many timezones, and code
People in the Zulip project live and work in many time zones, and code
reviewers also need focused chunks of time to write code and do other
things, so an immediate reply isn't always possible. But a good
benchmark is to try to always reply **within one workday**, at least
@@ -170,8 +170,8 @@ sooner is better.
conflicts) if there are still user experience issues under
discussion for the feature itself.
- _Completeness._ For refactorings, verify that the changes are
complete. Usually one can check that efficiently using `git grep`,
- _Completeness._ When reviewing a refactor, verify that the changes are
complete. Usually, one can check that efficiently using `git grep`,
and it's worth it, as we very frequently find issues by doing so.
- _Documentation updates._ If this changes how something works, does it