From 4c687f34417665035d526879a000dd8ade1d8706 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joy=20Serqui=C3=B1a?= Date: Fri, 3 Nov 2023 13:39:39 -0700 Subject: [PATCH 1/2] docs(angular/components): document bullet formatting incompatible Updated bulleted points in CODE_REVIEWS.md to remove '.' at the end of each point to be cohesive with CONTRIBUTING.md guidelines. :s :q :1 :! --- CODE_REVIEWS.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/CODE_REVIEWS.md b/CODE_REVIEWS.md index 87206fb20b30..92ccb95258ab 100644 --- a/CODE_REVIEWS.md +++ b/CODE_REVIEWS.md @@ -1,16 +1,19 @@ # Code reviews for Angular Material -* Before any coding begins on new, large, or breaking work, a design discussion should take place. -* All code changes require a review and approval. -* All behaviors should be covered by unit tests in the same PR. -* Large changes should be accompanied by corresponding e2e tests in the same PR. -* Authors should attempt to keep PRs to 200 - 300 line changes. +- Before any coding begins on new, large, or breaking work, a design discussion should take place +- All code changes require a review and approval +- All behaviors should be covered by unit tests in the same PR +- Large changes should be accompanied by corresponding e2e tests in the same PR +- Authors should attempt to keep PRs to 200 - 300 line changes ## Workflow + 1. The code author sends a PR for review. This request should include: - * A high-level description of the change being made. - * Links to any relevant issues. - * Screenshots (for visual changes or new additions) + +- A high-level description of the change being made +- Links to any relevant issues +- Screenshots (for visual changes or new additions) + 2. Reviews provide comments and the author responds / makes changes. Repeat until LGTM. 3. One or more of the reviewers approve the pull request. 4. Once the PR is approved, either the author or the reviewer can add the "merge-ready" @@ -18,6 +21,7 @@ 5. The party responsible for merging PRs will do so. ## How PRs are merged + The team has a weekly rotation for the "caretaker" who is responsible for merging PRs. Before being merged, the caretaker runs PRs through Google's internal presubmit system. This process helps greatly in keeping the library stable by running against the tests of many applications inside of From 991847c74ad4e39b97ee606316dab6c509fca15b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joy=20Serqui=C3=B1a?= <44146839+essjay05@users.noreply.github.com> Date: Mon, 6 Nov 2023 12:30:21 -0800 Subject: [PATCH 2/2] docs: Update CODE_REVIEWS.md Update sub-bullet spacing as recommended by the reviewer. --- CODE_REVIEWS.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CODE_REVIEWS.md b/CODE_REVIEWS.md index 92ccb95258ab..f4680927468b 100644 --- a/CODE_REVIEWS.md +++ b/CODE_REVIEWS.md @@ -10,9 +10,9 @@ 1. The code author sends a PR for review. This request should include: -- A high-level description of the change being made -- Links to any relevant issues -- Screenshots (for visual changes or new additions) + - A high-level description of the change being made + - Links to any relevant issues + - Screenshots (for visual changes or new additions) 2. Reviews provide comments and the author responds / makes changes. Repeat until LGTM. 3. One or more of the reviewers approve the pull request.