From e0f9e07723dfa406f6d69430804be941137faa1d Mon Sep 17 00:00:00 2001 From: Jirka Borovec Date: Thu, 22 Oct 2020 18:52:06 +0200 Subject: [PATCH] Updated Review guidelines (markdown) --- Review-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Review-guidelines.md b/Review-guidelines.md index 5bfa1dd..b9e2aa4 100644 --- a/Review-guidelines.md +++ b/Review-guidelines.md @@ -32,7 +32,7 @@ * For new features or enhancements- ask yourself if we want this change in the product? * 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. -* 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**. * 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.