From f64e1fcf8f2df6e32b462a88617cbbae61157f73 Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Mon, 26 Oct 2020 12:07:31 +0000 Subject: [PATCH 1/3] Maintainer-Guidelines: give maintainers time to review enhancements. Let's slow down a little on enhancement PRs to give other maintainers time to give their feedback. This is mostly self-directed criticism. --- docs/Maintainer-Guidelines.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/Maintainer-Guidelines.md b/docs/Maintainer-Guidelines.md index fd5a61b862..3665570e50 100644 --- a/docs/Maintainer-Guidelines.md +++ b/docs/Maintainer-Guidelines.md @@ -157,6 +157,16 @@ Any maintainer can merge any PR they have carefully reviewed and is passing CI t Any maintainer can revert a PR created by another maintainer after a user submitted issue or CI failure that results. The maintainer who created the original PR should be given no less than an hour to fix the issue themselves or decide to revert the PR themselves if they would rather. +### Give time for other maintainers to review + +PRs that are an "enhancement" to existing functionality i.e. not a fix to an open user issue/discussion, not a version bump, not a security fix, not a fix for CI failure, a usability improvement, a new feature etc. should wait 24h Monday - Friday before being merged. For example, + +- a new feature PR submitted at 5pm on Thursday should wait until 5pm on Friday before it is merged +- a usability fix PR submitted at 5pm on Friday should wait until 5pm on Monday before it is merged +- a user-reported issue fix PR can be merged immediately after CI is green + +If a maintainer is on holiday/vacation/sick during this time and leaves comments after they are back: please treat post-merge PR comments and feedback as you would left within the time period and follow-up with another PR to address their requests (if agreed). + ## Communication Maintainers have a variety of ways to communicate with each other: From 2e957b24b92575611d7e22b1484c2aee56ddcf8b Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Mon, 26 Oct 2020 12:46:10 +0000 Subject: [PATCH 2/3] Maintainer-Guidelines: note refactoring PR review. --- docs/Maintainer-Guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Maintainer-Guidelines.md b/docs/Maintainer-Guidelines.md index 3665570e50..e0e71120e4 100644 --- a/docs/Maintainer-Guidelines.md +++ b/docs/Maintainer-Guidelines.md @@ -159,7 +159,7 @@ Any maintainer can revert a PR created by another maintainer after a user submit ### Give time for other maintainers to review -PRs that are an "enhancement" to existing functionality i.e. not a fix to an open user issue/discussion, not a version bump, not a security fix, not a fix for CI failure, a usability improvement, a new feature etc. should wait 24h Monday - Friday before being merged. For example, +PRs that are an "enhancement" to existing functionality i.e. not a fix to an open user issue/discussion, not a version bump, not a security fix, not a fix for CI failure, a usability improvement, a new feature, refactoring etc. should wait 24h Monday - Friday before being merged. For example, - a new feature PR submitted at 5pm on Thursday should wait until 5pm on Friday before it is merged - a usability fix PR submitted at 5pm on Friday should wait until 5pm on Monday before it is merged From 57e8f348f55489acf82f014401dfbe75953b1bd4 Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Wed, 28 Oct 2020 10:11:58 +0000 Subject: [PATCH 3/3] Maintainer-Guidelines: add homebrew-core 24h caveat. --- docs/Maintainer-Guidelines.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/Maintainer-Guidelines.md b/docs/Maintainer-Guidelines.md index e0e71120e4..71c39d6266 100644 --- a/docs/Maintainer-Guidelines.md +++ b/docs/Maintainer-Guidelines.md @@ -167,6 +167,8 @@ PRs that are an "enhancement" to existing functionality i.e. not a fix to an ope If a maintainer is on holiday/vacation/sick during this time and leaves comments after they are back: please treat post-merge PR comments and feedback as you would left within the time period and follow-up with another PR to address their requests (if agreed). +The vast majority of Homebrew/homebrew-core PRs are bug fixes or version bumps so can be self-merged once CI has completed. + ## Communication Maintainers have a variety of ways to communicate with each other: