From 38631a285f30bbc590506902be439e70b9aed936 Mon Sep 17 00:00:00 2001 From: Ricardo Zanini Date: Wed, 15 May 2024 12:15:31 -0300 Subject: [PATCH 1/5] Add Emeritus Maintaner role; Add 2 days period for merging PRs Signed-off-by: Ricardo Zanini --- GOVERNANCE.md | 69 ++++++++++++++++++++++----------------------------- 1 file changed, 30 insertions(+), 39 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 8c6fd582..088b7882 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -13,48 +13,39 @@ You can contact the project maintainers at any time by sending an email to the Main responsibilities of maintainers include: -1) They share responsibility in the project's success. -2) They have made a long-term, recurring time investment to improve the project. -3) They spend that time doing whatever needs to be done, not necessarily what -is the most interesting or fun. +1) Sharing responsibility for the project's success. +2) Making a long-term, recurring time investment to improve the project. +3) Performing necessary tasks, even if they are not the most interesting or fun. ## Reviewers -A reviewer is a core role within the project. -They share in reviewing issues and pull requests. Their pull request approvals -are needed to merge a large code change into the project. +A reviewer is a core role within the project. They share in reviewing issues and pull requests. +Their pull request approvals are needed to merge significant code changes into the project. + +## Emeritus Maintainers + +Emeritus maintainers are retired maintainers who have chosen to remain involved in the project as advisors. +Their main responsibilities include: + +1) Providing guidance and mentorship to current maintainers and contributors. +2) Offering historical context and insights based on their past experiences. +3) Participating in discussions and reviews on an advisory basis, without the obligations of active maintainers. ## Adding maintainers -Maintainers are first and foremost contributors that have shown they are -committed to the long term success of a project. Contributors wanting to become -maintainers are expected to be deeply involved in contributing code, pull -request review, and triage of issues in the project for more than three months. - -Just contributing does not make you a maintainer, it is about building trust -with the current maintainers of the project and being a person that they can -depend on and trust to make decisions in the best interest of the project. - -Periodically, the existing maintainers curate a list of contributors that have -shown regular activity on the project over the prior months. From this list, -maintainer candidates are selected and proposed on the project mailing list. -Only one maintainer per organization is allowed to avoid taking over votes in case of conflicts. - -After a candidate has been announced on the project mailing list, the -existing maintainers are given fourteen business days to discuss the candidate, -raise objections and cast their vote. Votes may take place on the mailing list -or via pull request comment. Candidates must be approved by at least 66% of the -current maintainers by adding their vote on the mailing list. The reviewer role -has the same process but only requires 33% of current maintainers. Only -maintainers of the repository that the candidate is proposed for are allowed to -vote. - -If a candidate is approved, a maintainer will contact the candidate to invite -the candidate to open a pull request that adds the contributor to the -MAINTAINERS file. The voting process may take place inside a pull request if a -maintainer has already discussed the candidacy with the candidate and a -maintainer is willing to be a sponsor by opening the pull request. The candidate -becomes a maintainer once the pull request is merged. +Maintainers are first and foremost contributors who have demonstrated their commitment to the long-term success of the project. Contributors wishing to become maintainers are expected to be deeply involved in contributing code, reviewing pull requests, and triaging issues for more than three months. + +Just contributing does not make you a maintainer; it is about building trust with the current maintainers and being someone they can depend on to make decisions in the project's best interest. + +Periodically, the existing maintainers curate a list of contributors who have shown regular activity over the prior months. From this list, maintainer candidates are selected and proposed on the project mailing list. Only one maintainer per organization is allowed to avoid conflicts of interest. + +After a candidate is announced on the project mailing list, the existing maintainers have fourteen business days to discuss, raise objections, and vote on the candidate. Votes can be cast on the mailing list or via pull request comments. Candidates must be approved by at least 66% of the current maintainers. The reviewer role has the same process but only requires 33% approval from current maintainers. Only maintainers of the repository the candidate is proposed for are allowed to vote. + +If approved, a maintainer will contact the candidate to invite them to open a pull request adding themselves to the MAINTAINERS file. The voting process can also take place inside a pull request if a maintainer has already discussed the candidacy with the candidate and is willing to sponsor them by opening the pull request. The candidate becomes a maintainer once the pull request is merged. + +## Adding Emeritus Maintainers + +To transition a maintainer to an emeritus role, the current maintainers can nominate a retiring maintainer who has expressed interest in staying involved as an advisor. The nomination process follows the same voting and approval procedures as adding new maintainers, requiring a 66% approval vote from the current maintainers. Once approved, the emeritus maintainer is added to the EMERITUS file and announced to the community. ## Subprojects @@ -140,9 +131,9 @@ document for more information about opening pull requests. ## Conflict Resolution -At least 66% approval from the project's maintainers is necessary to merge changes -in the specification. [Lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus) -is considered by maintainers that do not directly express their opinions in the pull request. +To merge changes into the specification, at least 66% approval from the project's maintainers is required. +Maintainers who do not explicitly voice their opinions on the pull request within the two-day approval period are +assumed to agree through [lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). Discussions and voting can be posponed in case one of the maintainers expressed that they won't be available for personal reasons, e.g. parental leave, vacations, sick leave, etc. From 251b8aa53183edd7722aecbe0bfe44826daaa242 Mon Sep 17 00:00:00 2001 From: Ricardo Zanini Date: Wed, 15 May 2024 12:21:51 -0300 Subject: [PATCH 2/5] Tidy up conflict res Signed-off-by: Ricardo Zanini --- GOVERNANCE.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 088b7882..1010dfac 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -131,9 +131,8 @@ document for more information about opening pull requests. ## Conflict Resolution -To merge changes into the specification, at least 66% approval from the project's maintainers is required. -Maintainers who do not explicitly voice their opinions on the pull request within the two-day approval period are -assumed to agree through [lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). +To merge changes into the specification, approval from at least one maintainer, other than the pull request's author, is required. +Maintainers who do not explicitly voice their opinions on the pull request within the two-day approval period are assumed to agree through [lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). Discussions and voting can be posponed in case one of the maintainers expressed that they won't be available for personal reasons, e.g. parental leave, vacations, sick leave, etc. From 7b9f2bf9e9210bb7cd31f99914d93e67e492bf7d Mon Sep 17 00:00:00 2001 From: Ricardo Zanini <1538000+ricardozanini@users.noreply.github.com> Date: Wed, 15 May 2024 14:53:47 -0300 Subject: [PATCH 3/5] Incorporating Doug's review Co-authored-by: Doug Davis --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 1010dfac..8eac9e14 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -45,7 +45,7 @@ If approved, a maintainer will contact the candidate to invite them to open a pu ## Adding Emeritus Maintainers -To transition a maintainer to an emeritus role, the current maintainers can nominate a retiring maintainer who has expressed interest in staying involved as an advisor. The nomination process follows the same voting and approval procedures as adding new maintainers, requiring a 66% approval vote from the current maintainers. Once approved, the emeritus maintainer is added to the EMERITUS file and announced to the community. +To transition a maintainer to an emeritus role, the process follows the same voting and approval procedures as adding new maintainers, a new PR is created that requires a 66% approval vote from the current maintainers. Once approved, the emeritus maintainer is added to the EMERITUS file and announced to the community. ## Subprojects From a23ff702daa67aa3b40d2d0ed832ddbbe661fa71 Mon Sep 17 00:00:00 2001 From: Ricardo Zanini Date: Wed, 15 May 2024 14:54:15 -0300 Subject: [PATCH 4/5] First round of reviews by Doug Signed-off-by: Ricardo Zanini --- GOVERNANCE.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 8eac9e14..e1f4bebe 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -20,12 +20,11 @@ Main responsibilities of maintainers include: ## Reviewers A reviewer is a core role within the project. They share in reviewing issues and pull requests. -Their pull request approvals are needed to merge significant code changes into the project. +Their pull request approvals are needed to merge code changes into the project. ## Emeritus Maintainers -Emeritus maintainers are retired maintainers who have chosen to remain involved in the project as advisors. -Their main responsibilities include: +Emeritus maintainers are retired maintainers who have provided valuable contributions to the project in the past but are not able to dedicate the time necessary to be fully active maintainers going forward. While their efforts will be focused elsewhere, it is hoped that they will try to find the time to continue to be active participants in the community by: 1) Providing guidance and mentorship to current maintainers and contributors. 2) Offering historical context and insights based on their past experiences. @@ -37,9 +36,9 @@ Maintainers are first and foremost contributors who have demonstrated their comm Just contributing does not make you a maintainer; it is about building trust with the current maintainers and being someone they can depend on to make decisions in the project's best interest. -Periodically, the existing maintainers curate a list of contributors who have shown regular activity over the prior months. From this list, maintainer candidates are selected and proposed on the project mailing list. Only one maintainer per organization is allowed to avoid conflicts of interest. +Periodically, the existing maintainers curate a list of contributors who have shown regular activity over the prior months. From this list, maintainer candidates are selected and proposed on a pull request. Only one maintainer per organization is allowed to avoid conflicts of interest. -After a candidate is announced on the project mailing list, the existing maintainers have fourteen business days to discuss, raise objections, and vote on the candidate. Votes can be cast on the mailing list or via pull request comments. Candidates must be approved by at least 66% of the current maintainers. The reviewer role has the same process but only requires 33% approval from current maintainers. Only maintainers of the repository the candidate is proposed for are allowed to vote. +After a candidate is announced on the pull request, the existing maintainers have fourteen business days to discuss, raise objections, and vote on the candidate. Votes can be cast on via pull request comments. Candidates must be approved by at least 66% of the current maintainers. The reviewer role has the same process but only requires 33% approval from current maintainers. Only maintainers of the repository the candidate is proposed for are allowed to vote. If approved, a maintainer will contact the candidate to invite them to open a pull request adding themselves to the MAINTAINERS file. The voting process can also take place inside a pull request if a maintainer has already discussed the candidacy with the candidate and is willing to sponsor them by opening the pull request. The candidate becomes a maintainer once the pull request is merged. From fd05cc7fd6aafd8149634b86edf70895bd430766 Mon Sep 17 00:00:00 2001 From: Ricardo Zanini Date: Thu, 16 May 2024 10:32:44 -0300 Subject: [PATCH 5/5] Incorporating Doug's review, second round Signed-off-by: Ricardo Zanini --- GOVERNANCE.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index e1f4bebe..53acfa15 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -32,15 +32,15 @@ Emeritus maintainers are retired maintainers who have provided valuable contribu ## Adding maintainers -Maintainers are first and foremost contributors who have demonstrated their commitment to the long-term success of the project. Contributors wishing to become maintainers are expected to be deeply involved in contributing code, reviewing pull requests, and triaging issues for more than three months. +Maintainers are primarily contributors who have shown a strong commitment to the long-term success of the project. Contributors aspiring to become maintainers are expected to be actively involved in coding, reviewing pull requests, and managing issues for over three months. -Just contributing does not make you a maintainer; it is about building trust with the current maintainers and being someone they can depend on to make decisions in the project's best interest. +Becoming a maintainer is not just about contributing; it involves building trust with the current maintainers and proving to be a reliable decision-maker for the project. -Periodically, the existing maintainers curate a list of contributors who have shown regular activity over the prior months. From this list, maintainer candidates are selected and proposed on a pull request. Only one maintainer per organization is allowed to avoid conflicts of interest. +Periodically, the existing maintainers compile a list of contributors who have been consistently active in recent months. From this list, maintainer candidates are selected and proposed via a pull request. To avoid conflicts of interest, only one maintainer per organization is allowed. -After a candidate is announced on the pull request, the existing maintainers have fourteen business days to discuss, raise objections, and vote on the candidate. Votes can be cast on via pull request comments. Candidates must be approved by at least 66% of the current maintainers. The reviewer role has the same process but only requires 33% approval from current maintainers. Only maintainers of the repository the candidate is proposed for are allowed to vote. +Once a candidate is proposed by adding them to the MAINTAINERS file via a pull request, the existing maintainers have fourteen business days to discuss, raise objections, and vote. Votes are cast through pull request comments, and candidates must receive at least 66% approval from the current maintainers. -If approved, a maintainer will contact the candidate to invite them to open a pull request adding themselves to the MAINTAINERS file. The voting process can also take place inside a pull request if a maintainer has already discussed the candidacy with the candidate and is willing to sponsor them by opening the pull request. The candidate becomes a maintainer once the pull request is merged. +The process for the reviewer role is similar but requires only 33% approval from current maintainers. Voting is restricted to maintainers of the repository for which the candidate is proposed. ## Adding Emeritus Maintainers