From 7f28c8c1cd175389e00edec7adc9c0700a5e75e9 Mon Sep 17 00:00:00 2001 From: Anuraag Agrawal Date: Tue, 17 May 2022 22:57:08 +0900 Subject: [PATCH] Update CONTRIBUTING.md (#567) Signed-off-by: Anuraag Agrawal --- CONTRIBUTING.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0499de9f..f01630e5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,8 +4,8 @@ We welcome contributions from the community. Please read the following guideline ## Coding Style -- To ensure your change passes format checks, use run `make check`. To format your files, you can run `make format`. -- We follow standard Go table-driven tests and use the [`testify/require`](https://github.com/stretchr/testify#require-package) library to assert correctness. To verify all tests pass, you can run `make test`. +- To ensure your change passes format checks, run `make check`. To format your files, you can run `make format`. +- We follow standard Go table-driven tests and use an internal [testing library](./internal/testing/require) to assert correctness. To verify all tests pass, you can run `make test`. ## DCO @@ -57,14 +57,8 @@ You can add the sign off when creating the git commit via `git commit -s`. ## Code Reviews -* Indicate the priority of each comment, following this -[feedback ladder](https://www.netlify.com/blog/2020/03/05/feedback-ladders-how-we-encode-code-reviews-at-netlify/). -If none was indicated it will be treated as `[dust]`. -* A single approval is sufficient to merge, except when the change cuts -across several components; then it should be approved by at least one owner -of each component. If a reviewer asks for changes in a PR they should be -addressed before the PR is merged, even if another reviewer has already -approved the PR. +* A single approval is sufficient to merge. If a reviewer asks for changes in a PR they should be +addressed before the PR is merged, even if another reviewer has already approved the PR. * During the review, address the comments and commit the changes _without_ squashing the commits. This facilitates incremental reviews since the reviewer does not go through all the code again to find out what has changed since the last review.