From ec3ffb1e996b4388ad7dad177cb00fd1ec9fdfca Mon Sep 17 00:00:00 2001
From: Dan Harris <danharris247@gmail.com>
Date: Fri, 15 Jan 2021 18:19:26 -0700
Subject: [PATCH 1/5] initial maintainers and governance framework
---
GOVERNANCE.md | 29 ++++++++++++++++++
MAINTAINERS.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 108 insertions(+)
create mode 100644 GOVERNANCE.md
create mode 100644 MAINTAINERS.md
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
new file mode 100644
index 000000000..6072053fd
--- /dev/null
+++ b/GOVERNANCE.md
@@ -0,0 +1,29 @@
+# Policy and Procedure
+
+
+## Maintainers
+
+|Maintainer|Role|
+|---|---|
+|*Dan Harris|CSC Operations|
+|*Kevin Sayers|CSC Applications|
+|Chris Chang|CSC Applications|
+|Ethan Young|CSC Applications|
+|Tim Kaiser|CSC Applications|
+|John Leicht|CSC Operations|
+
+_\* indicates repo admin_
+
+## Maintainership
+
+
+## Adding maintainers
+
+
+## Removing maintainers
+
+
+## How are decisions made?
+
+
+## Conflict Resolution
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
new file mode 100644
index 000000000..d5d4c9a0e
--- /dev/null
+++ b/MAINTAINERS.md
@@ -0,0 +1,79 @@
+# Maintainer Guidelines
+
+**This guide is for maintainers.** These people have **write
+access** to NREL HPC's repository and help merge the contributions of
+others.
+
+If you have something to contribute, please see the [Contributing Guide](CONTRIBUTING.md).
+
+This is a living document - if you see something out of date or missing,
+speak up!
+
+## What are a maintainer's responsibilities?
+
+It is every maintainer's responsibility to:
+
+* Expose a clear roadmap for improving the repository.
+* Deliver prompt feedback and decisions on pull requests.
+* Be available to anyone with questions, bug reports, criticism etc. on the repository.
+ This includes GitHub issues and pull requests.
+* Make sure the repository respects the philosophy, design and roadmap of the project.
+
+## How are decisions made?
+
+This project is an open-source project with an open design philosophy. This
+means that the repository is the source of truth for EVERY aspect of the
+project, including its philosophy, design, and roadmap. *If it's
+part of the project, it's in the repo. It's in the repo, it's part of
+the project.*
+
+As a result, all decisions can be expressed as changes to the
+repository.
+
+All decisions affecting this project, big and small, follow the same procedure:
+
+1. Open a pull request.
+ Anyone can do this.
+2. Discuss the pull request.
+ Anyone can do this.
+3. Review the pull request.
+ The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
+ Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on](GOVERNANCE.md).
+4. Merge or close the pull request.
+ The relevant maintainers do this.
+
+### I'm a maintainer, should I make pull requests too?
+
+Yes. Nobody should ever push to master directly. All changes should be
+made through a pull request.
+
+## Who decides what?
+
+All decisions are pull requests, and the relevant maintainers make
+decisions by accepting or refusing the pull request. Review and acceptance
+by anyone is denoted by adding a comment in the pull request.
+However, only currently listed `MAINTAINERS` are counted towards the required
+two Reviews. In addition, if a maintainer has created a pull request, they cannot
+count toward the two Review rule (to ensure equal amounts of review for every pull
+request, no matter who wrote it).
+
+Overall the maintainer system works because of mutual respect.
+The maintainers trust one another to act in the best interests of the project.
+Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people.
+In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus.
+
+### How are maintainers added?
+
+The best maintainers have a vested interest in the project. Maintainers
+are first and foremost contributors that have shown they are committed to
+the long term success of the 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 two 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 to act in the best interest of the project.
+The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md).
+
+### How are maintainers removed?
+
+When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).
+Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.
From 75d7c2bb71e612fac517df94cfc980d51173abc6 Mon Sep 17 00:00:00 2001
From: hyandt <hyandt@nrel.gov>
Date: Tue, 23 Aug 2022 09:10:33 -0600
Subject: [PATCH 2/5] Add Maintainer's guide
---
MAINTAINERS.md | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index d5d4c9a0e..40afa2451 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -13,11 +13,9 @@ speak up!
It is every maintainer's responsibility to:
-* Expose a clear roadmap for improving the repository.
* Deliver prompt feedback and decisions on pull requests.
* Be available to anyone with questions, bug reports, criticism etc. on the repository.
This includes GitHub issues and pull requests.
-* Make sure the repository respects the philosophy, design and roadmap of the project.
## How are decisions made?
@@ -77,3 +75,21 @@ The final vote to add a new maintainer should be approved by the [governance pro
When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).
Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.
+
+### Handling PR's
+Any new issue or Pull request should receive a response within 2 weeks.
+PRs should be merged once they have the review comments addressed and get approved by at least 1 maintainer.
+If the only issues holding up a merge are trivial fixes (typos, syntax, etc.) and the author doesn't respond within 2 weeks, the maintainers can make the necessary changes themselves and proceed with the merge process.
+If a PR doesn't receive feedback from the submitter within 1 month, a maintainer can choose to take over the PR and make necessary changes or can be closed.
+If a PR is related to an issue, check whether the issue is fixed and can be closed. Pull requests can be merged once they have been reviewed. If they fix an issue, the issue should be closed/or modified.
+Discuss in GH-pages meeting if PR should be closed/not merged in. If the content is not relevant/useful, we don't want to put out.
+
+Maintainer review:
+ask for changes in the PR (this blocks merging until the comments are resolved)
+approve the PR
+
+Acceptance criteria:
+Documentation or examples are clear
+Targets the right branch
+PR complies with the contribution guidelines
+The content is relevant and useful to HPC users
From b0f2e60d04dbb3b1644a0d8aa2ad28e4273f6949 Mon Sep 17 00:00:00 2001
From: Haley Yandt <46908710+yandthj@users.noreply.github.com>
Date: Tue, 23 Aug 2022 09:29:52 -0600
Subject: [PATCH 3/5] Update MAINTAINERS.md
---
MAINTAINERS.md | 53 +++++++++++++-------------------------------------
1 file changed, 14 insertions(+), 39 deletions(-)
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index 40afa2451..f03cf0d79 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -19,15 +19,6 @@ It is every maintainer's responsibility to:
## How are decisions made?
-This project is an open-source project with an open design philosophy. This
-means that the repository is the source of truth for EVERY aspect of the
-project, including its philosophy, design, and roadmap. *If it's
-part of the project, it's in the repo. It's in the repo, it's part of
-the project.*
-
-As a result, all decisions can be expressed as changes to the
-repository.
-
All decisions affecting this project, big and small, follow the same procedure:
1. Open a pull request.
@@ -36,7 +27,6 @@ All decisions affecting this project, big and small, follow the same procedure:
Anyone can do this.
3. Review the pull request.
The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
- Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on](GOVERNANCE.md).
4. Merge or close the pull request.
The relevant maintainers do this.
@@ -55,41 +45,26 @@ two Reviews. In addition, if a maintainer has created a pull request, they canno
count toward the two Review rule (to ensure equal amounts of review for every pull
request, no matter who wrote it).
-Overall the maintainer system works because of mutual respect.
-The maintainers trust one another to act in the best interests of the project.
-Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people.
-In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus.
-
-### How are maintainers added?
-
-The best maintainers have a vested interest in the project. Maintainers
-are first and foremost contributors that have shown they are committed to
-the long term success of the 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 two 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 to act in the best interest of the project.
-The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md).
-### How are maintainers removed?
-
-When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).
-Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.
+### Reviewing and approving Pull Requests
+Acceptance Criteria:
+PR complies with contribution guidelines
+Targets the right branch
+Content is clear/free of typos
+Content is relevant to NREL HPC users
-### Handling PR's
-Any new issue or Pull request should receive a response within 2 weeks.
+Process:
+Any new Pull request should receive a response within 2 weeks.
PRs should be merged once they have the review comments addressed and get approved by at least 1 maintainer.
If the only issues holding up a merge are trivial fixes (typos, syntax, etc.) and the author doesn't respond within 2 weeks, the maintainers can make the necessary changes themselves and proceed with the merge process.
If a PR doesn't receive feedback from the submitter within 1 month, a maintainer can choose to take over the PR and make necessary changes or can be closed.
-If a PR is related to an issue, check whether the issue is fixed and can be closed. Pull requests can be merged once they have been reviewed. If they fix an issue, the issue should be closed/or modified.
-Discuss in GH-pages meeting if PR should be closed/not merged in. If the content is not relevant/useful, we don't want to put out.
+If a PR is related to an issue. Check whether the issue is fixed
+If a PR doesn't receive feedback from the submitter within 1 month, a maintainer can choose to take over the PR and make necessary changes or can be closed.
+If a PR is related to an issue, check whether the issue is fixed and can be closed. If they fix an issue, the issue should be closed/or modified.
+Discuss in GH-pages meeting if PR should be closed/not merged in. If the content is not relevant/usefu
-Maintainer review:
+Maintainer review responses:
ask for changes in the PR (this blocks merging until the comments are resolved)
approve the PR
+bring up to maintainer's to close PR.
-Acceptance criteria:
-Documentation or examples are clear
-Targets the right branch
-PR complies with the contribution guidelines
-The content is relevant and useful to HPC users
From 214bdce615bb4c0065b6aaaf61ae9f7215ea94c1 Mon Sep 17 00:00:00 2001
From: Haley Yandt <46908710+yandthj@users.noreply.github.com>
Date: Tue, 23 Aug 2022 10:55:37 -0600
Subject: [PATCH 4/5] Update MAINTAINERS.md
---
MAINTAINERS.md | 61 +++++++++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index f03cf0d79..9137ae6fa 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -30,41 +30,42 @@ All decisions affecting this project, big and small, follow the same procedure:
4. Merge or close the pull request.
The relevant maintainers do this.
-### I'm a maintainer, should I make pull requests too?
+#### I'm a maintainer, should I make pull requests too?
-Yes. Nobody should ever push to master directly. All changes should be
+Yes. Nobody should ever push to the repository directly. All changes should be
made through a pull request.
-## Who decides what?
+### Who decides what?
-All decisions are pull requests, and the relevant maintainers make
-decisions by accepting or refusing the pull request. Review and acceptance
-by anyone is denoted by adding a comment in the pull request.
-However, only currently listed `MAINTAINERS` are counted towards the required
-two Reviews. In addition, if a maintainer has created a pull request, they cannot
-count toward the two Review rule (to ensure equal amounts of review for every pull
+Only maintainers are counted towards the required
+review. In addition, if a maintainer has created a pull request, they cannot
+review it themselves (to ensure equal amounts of review for every pull
request, no matter who wrote it).
-### Reviewing and approving Pull Requests
-Acceptance Criteria:
-PR complies with contribution guidelines
-Targets the right branch
-Content is clear/free of typos
-Content is relevant to NREL HPC users
-
-Process:
-Any new Pull request should receive a response within 2 weeks.
-PRs should be merged once they have the review comments addressed and get approved by at least 1 maintainer.
-If the only issues holding up a merge are trivial fixes (typos, syntax, etc.) and the author doesn't respond within 2 weeks, the maintainers can make the necessary changes themselves and proceed with the merge process.
-If a PR doesn't receive feedback from the submitter within 1 month, a maintainer can choose to take over the PR and make necessary changes or can be closed.
-If a PR is related to an issue. Check whether the issue is fixed
-If a PR doesn't receive feedback from the submitter within 1 month, a maintainer can choose to take over the PR and make necessary changes or can be closed.
-If a PR is related to an issue, check whether the issue is fixed and can be closed. If they fix an issue, the issue should be closed/or modified.
-Discuss in GH-pages meeting if PR should be closed/not merged in. If the content is not relevant/usefu
-
-Maintainer review responses:
-ask for changes in the PR (this blocks merging until the comments are resolved)
-approve the PR
-bring up to maintainer's to close PR.
+## Handling Pull Requests
+
+### Acceptance Criteria:
+* The PR complies with contribution guidelines
+* The PR Targets the right branch (see branch descriptions)
+* The content written is clear, free of typos, and relevant to NREL HPC users
+
+### Process for Pull Requests:
+* PRs can be merged once they have been approved by at least 1 maintainer.
+* Any new PR should be assigned a reviewer within 2 weeks. The reviewer should give a response within one week of assignment.
+* As a result of their review, a maintainer can:
+ 1. Request changes in the Pull Request (which blocks merging until the changes are resolved)
+ 3. Approve the Pull Request
+ 4. Propose closing the Pull Request
+* Maintainers need to submit the review in Github so that it is clear when the review is complete.
+* If the only issues holding up a merge are trivial fixes (typos, syntax, etc.) and the author doesn't respond within 2 weeks to the requested changes or comments, the maintainers can make the necessary changes themselves and proceed with the merge process.
+* If the requested changes to a PR don't receive a response from the submitter within 1 month, a maintainer can choose to take over the PR and make necessary changes or it can be closed.
+* If a PR is related to an issue, check whether the issue is completely resolved and can be closed. Comment with the PR number when closing the issue. Modify or comment on the issue if it is not entirely resolved.
+* A PR can be closed if it does not meet the acceptance criteria or does not receive a response to requested changes within 1 month. To close a PR, bring up a discussion at a Maintainer's meeting to get consensus.
+* If closing a PR, leave a comment about why it was closed.
+
+
+
+
+
From 8fb5ba902e9566b72f80b43cb1157d489c22efc7 Mon Sep 17 00:00:00 2001
From: Haley Yandt <46908710+yandthj@users.noreply.github.com>
Date: Tue, 23 Aug 2022 11:44:42 -0600
Subject: [PATCH 5/5] Update MAINTAINERS.md
---
MAINTAINERS.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index 9137ae6fa..10c6025ba 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -46,9 +46,9 @@ request, no matter who wrote it).
## Handling Pull Requests
### Acceptance Criteria:
-* The PR complies with contribution guidelines
-* The PR Targets the right branch (see branch descriptions)
-* The content written is clear, free of typos, and relevant to NREL HPC users
+* The PR complies with the [contribution guidelines](CONTRIBUTING.md)
+* The PR targets the appropriate branch
+* The content is clear, free of typos, and relevant to NREL HPC users
### Process for Pull Requests:
* PRs can be merged once they have been approved by at least 1 maintainer.