Updated Review guidelines (markdown)

Jirka Borovec 2020-10-22 18:52:06 +02:00
parent f41261d630
commit e0f9e07723
1 changed files with 1 additions and 1 deletions

@ -32,7 +32,7 @@
* For new features or enhancements- ask yourself if we want this change in the product? * For new features or enhancements- ask yourself if we want this change in the product?
* Refactors should always be in separate PRs than changes. * Refactors should always be in separate PRs than changes.
* Every PR should change/fix **exactly one thing**. Otherwise, ask the author to split into smaller PRs. * Every PR should change/fix **exactly one thing**. Otherwise, ask the author to split into smaller PRs.
* Any code changes (may be skipped form typos in docs) both features and bug-fixes shall be cover by tests existing or newly added ones, If there is a bugfix and all tests were passing on master before and the PR does not add a new test to reveal the issue, ask the author to add it... * Any code changes (may be skipped form typos in docs) both features and bug-fixes shall be cover by tests existing or newly added ones, If there is a bugfix and all tests were passing on master before and the PR does not add a new test to reveal the issue, ask the author to add it... and add label "waiting for author".
### 3. Verify the code is **correct and readable**. ### 3. Verify the code is **correct and readable**.
* Code is read way more often than it is written or modified, so readability is always important. You should aim to understand every changed line. If you don't understand it, it's likely someone else won't either. Ask questions and comments for things you don't understand. * Code is read way more often than it is written or modified, so readability is always important. You should aim to understand every changed line. If you don't understand it, it's likely someone else won't either. Ask questions and comments for things you don't understand.