Update to Governance Model (#736)

### Feature or Bugfix - Feature ### Detail - Update to the Governance model to formalise the status of maintainers and how decisions are mode on the project ### Relates ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? N/A - Is the input sanitized? N/A - What precautions are you taking before deserializing the data you consume? N/A - Is injection prevented by parametrizing queries? N/A - Have you ensured no `eval` or similar functions are used? N/A - Does this PR introduce any functionality or component that requires authorization? N/A - How have you ensured it respects the existing AuthN/AuthZ mechanisms? N/A - Are you logging failed auth attempts? N/A - Are you using or adding any cryptographic features? N/A - Do you use a standard proven implementations? N/A - Are the used keys controlled by the customer? Where are they stored? N/A - Are you introducing any new policies/roles/users? N/A - Have you used the least-privilege principle? How? N/A By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. --------- Co-authored-by: Nick Corbett <corbetn@amazon.co.uk>
data-dot-all · Oct 12, 2023 · 6e2fdb0 · 6e2fdb0
1 parent 38a089d
commit 6e2fdb0
Show file tree

Hide file tree

Showing 5 changed files with 224 additions and 0 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -6,6 +6,10 @@ documentation, we greatly value feedback and contributions from our community.
 Please read through this document before submitting any issues or pull requests to ensure we have all the necessary
 information to effectively respond to your bug report or contribution.
 
+## First Things First
+
+When in doubt, **open an issue**. For almost any type of contribution, the first step is to open an issue.  Even if you think you already know the best solution, writing down a description of the problem you are trying to solve will not only give everyone else context, but also help [consolidate your thoughts](https://en.wikipedia.org/wiki/Rubber_duck_debugging).  If its a really trivial change, like a typo or spelling error, you can skip this step, but when in doubt, open an issue
+
 
 ## Reporting Bugs/Feature Requests
 
@@ -38,6 +42,15 @@ To send us a pull request, please:
 GitHub provides additional document on [forking a repository](https://help.github.com/articles/fork-a-repo/) and
 [creating a pull request](https://help.github.com/articles/creating-a-pull-request/).
 
+## Review Process
+
+We deeply appreciate everyone who takes the time to make a contribution. We will review all contributions as quickly as possible. As a reminder, opening an issue discussing your change before you make it is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction.
+
+During the PR process, expect that there will be some back-and-forth. Please try to respond to comments in a timely fashion, and work with us to get the best outcome for the data.all project. If you don't wish to continue with the PR, let us know. 
+
+If we accept the PR, a [maintainer](MAINTAINERS.md) will merge your change and usually take care of backporting it to appropriate branches ourselves.
+
+If we reject the PR, we will close the pull request with a comment explaining why. This decision isn't always final: if you feel we have misunderstood your intended change or otherwise think that we should reconsider then please continue the conversation with a comment on the PR and we'll do our best to address any further points you raise.  If a PR takes too many iterations for its complexity or size, we may reject it.  Additionally, if you stop responding we may close the PR as abandoned. In either case, if you feel this was done in error, please add a comment on the PR.  A closed PR can always be re-opened.
 
 ## Finding contributions to work on
 Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any ['help wanted'](https://github.com/awslabs/aws-dataall/labels/help%20wanted) issues is a great place to start.

diff --git a/GOVERNANCE.md b/GOVERNANCE.md
@@ -0,0 +1,49 @@
+# Project Governance (Very Minimal Governance model)
+
+This open source project is managed by a Steering Committee composed of the maintainers of this project. Maintainers are
+defined as individuals with [maintain-level permissions on the data.all repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization).
+
+## Steering Committee
+
+The Steering Committee will be responsible for oversight of all technical, project, approval, and policy matters for the
+project. This notably includes brand and trademark management.
+
+The Steering Committee members are listed in the MAINTAINERS.md file in the repository. New maintainers (and accordingly,
+Steering Committee members) may be added or removed as outlined in [RESPONSIBILITIES.md](./RESPONSIBILITIES.md). The
+Steering Committee will appoint a Chair responsible for organizing Steering Committee activity. If the Steering Committee
+Chair is removed from the Committee (or the Chair steps down from that role), it is the responsibility of the Steering
+Committee to appoint a new Chair.
+
+The Steering Committee may, at its discretion, add or remove members who are not maintainers.
+
+## Voting
+
+The Steering Committee will strive for all decisions to be made by consensus. While explicit agreement of the entire
+Steering Committee is preferred, it is not required for consensus. Rather, the Steering Committee will determine
+consensus based on their good faith consideration of a number of factors, including the dominant view of the Steering
+Committee and nature of support and objections. The Steering Committee will document evidence of consensus in accordance
+with these requirements. If consensus cannot be reached, the Steering Committee will make the decision by a vote.
+
+The Steering Committee Chair will call a vote with reasonable notice to the Steering Committee, setting out a discussion
+period and a separate voting period. Any discussion may be conducted in person or electronically by text, voice, or video.
+The discussion will be open to the public, with the notable exception of discussions involving embargoed security issues
+or the addition or removal of maintainers, which will be private. In any vote, each voting representative will have one
+vote. Except as specifically noted elsewhere in this document, decisions by vote require a simple majority vote of all
+voting members.
+
+## Termination of Membership
+
+A maintainer’s access (and accordingly, their position on the Steering Committee) will be removed if any of the following
+occur:
+
+* Resignation: Written notice of resignation to the Steering Committee
+* Steering Committee Vote: 3/4 affirmative vote of the Steering Committee to remove a member
+* Unreachable Member: If a member is unresponsive for more than six months, the remaining active members of the Steering
+  Committee may vote to remove the member
+
+## License of this document
+
+This document is a modified work of the GitHub Minimal Viable Governance model, located here: 
+[https://github.com/github/MVG](https://github.com/github/MVG)
+This document may be used, modified, and/or distributed under the terms of the 
+[Creative Commons Attribution 4.0 International (CC-BY) license](https://creativecommons.org/licenses/by/4.0/legalcode).
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
@@ -0,0 +1,15 @@
+## Overview
+
+This document contains a list of maintainers in this repo. See [RESPONSIBILITIES.md](./RESPONSIBILITIES.md) 
+that explains what the role of maintainer means, what maintainers do, how they should be 
+doing it, and how to become one. If you're interested in becoming a maintainer, the best place to start is by first [CONTRIBUTING](CONTRIBUTING.md).
+
+## Current Maintainers
+
+| Maintainer           | GitHub ID                                     | Affiliation |
+|----------------------|-----------------------------------------------| ----------- |
+| Nick Corbett (chair) | [NickCorbett](https://github.com/NickCorbett) | Amazon      |
+| Anmol Gandhi         | [anmolsgandhi](https://github.com/anmolsgandhi) | Amazon      |
+| Adriana Lopez        | [dlpzx](https://github.com/dlpzx)             | Amazon      |
+| Noah Paige           | [noah-paige](https://github.com/noah-paige)   | Amazon      |
+| Nikita Podshivalov   | [nikpodsh](https://github.com/nikpodsh)       | Amazon      |
diff --git a/RESPONSIBILITIES.md b/RESPONSIBILITIES.md
@@ -0,0 +1,144 @@
+# Maintainer Responsibilities
+
+- [Overview](#overview)
+- [Current Maintainers](#current-maintainers)
+- [Maintainer Responsibilities](#maintainer-responsibilities)
+    - [Uphold Code of Conduct](#uphold-code-of-conduct)
+    - [Prioritize Security](#prioritize-security)
+    - [Review Pull Requests](#review-pull-requests)
+    - [Triage Open Issues](#triage-open-issues)
+        - [Automatically Label Issues](#automatically-label-issues)
+    - [Be Responsive](#be-responsive)
+    - [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo)
+        - [Keep Dependencies up to Date](#keep-dependencies-up-to-date)
+    - [Manage Roadmap](#manage-roadmap)
+    - [Add Continuous Integration Checks](#add-continuous-integration-checks)
+    - [Use Semver](#use-semver)
+    - [Release Frequently](#release-frequently)
+    - [Promote Other Maintainers](#promote-other-maintainers)
+    - [Describe the Repo](#describe-the-repo)
+- [Becoming a Maintainer](#becoming-a-maintainer)
+    - [Nomination](#nomination)
+    - [Interest](#interest)
+    - [Addition](#addition)
+- [Removing a Maintainer](#removing-a-maintainer)
+    - [Moving On](#moving-on)
+    - [Inactivity](#inactivity)
+    - [Negative Impact on the Project](#negative-impact-on-the-project)
+
+## Overview
+
+This document explains who maintainers are, what they do in the data.all project, and how they should be doing it. 
+If you're interested in contributing, see [Becoming a Maintainer](#becoming-a-maintainer).
+
+## Current Maintainers
+
+The current maintainers are listed in [MAINTAINERS.md](MAINTAINERS.md).
+
+## Maintainer Responsibilities
+
+Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows.
+
+### Uphold Code of Conduct
+
+Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers.
+
+### Prioritize Security
+
+Security is our number one priority. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs.
+
+Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details.
+
+### Review Pull Requests
+
+Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incoming pull requests. Don't let PRs be stale and do your best to be helpful to contributors.
+
+### Triage Open Issues
+
+Manage labels, review issues regularly, and triage by labelling them.
+
+We use key value labels, use the `priority:`, `type:`, `effort:` and `status:` when triaging issues.
+
+Use the `good first issue` label to let new community members know where to start and `blocker` for issues that scare you or need immediate attention. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project.
+
+### Be Responsive
+
+Respond to enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in.
+
+### Maintain Overall Health of the Repo
+
+Keep the `main` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches.
+
+#### Keep Dependencies up to Date
+
+Maintaining up-to-date dependencies on third party projects reduces the risk of security vulnerabilities. As 
+[recommended](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool) by 
+The Open Source Security Foundation (OpenSSF)  we use Dependabot, which is integrated with GitHub. Dependabot does not 
+have any centralized management dashboard, so maintainers may use tags or other PR filters to track pending updates.
+
+### Manage Roadmap
+
+Ensure the repo highlights features that should be elevated to the project roadmap. Be clear about the feature’s status, 
+priority, target version, and whether or not it should be elevated to the roadmap. Any feature that you want highlighted 
+on the data.all Roadmap should be tagged with "roadmap".
+
+### Add Continuous Integration Checks
+
+Add integration checks that validate pull requests and pushes to ease the burden on Pull Request reviewers.
+
+### Use Semver
+
+Use and enforce [semantic versioning](https://semver.org/) and do not let breaking changes be made outside of major releases.
+
+### Release Frequently
+
+Make frequent project releases to the community.
+
+### Promote Other Maintainers
+
+Assist, add, and remove [MAINTAINERS](MAINTAINERS.md). Exercise good judgement, and propose high quality contributors to become co-maintainers. See [Becoming a Maintainer](#becoming-a-maintainer) for more information.
+
+### Describe the Repo
+
+Make sure the repo has a well-written, accurate, and complete description.
+## Becoming a Maintainer
+
+You can become a maintainer by actively [contributing](CONTRIBUTING.md) to the project, and being nominated by an existing maintainer.
+
+### Nomination
+
+Any current maintainer starts a private conversation (e-mail or IM) with all other maintainers to discuss nomination using the template below. 
+In order to be approved, at least three positive (+1) maintainer votes are necessary (or all maintainers, if there are fewer than 3), and no vetoes (-1).
+
+The nomination should clearly identify the person with their real name and a link to their GitHub profile, and the 
+rationale for the nomination, with concrete example contributions.
+
+### Interest
+
+Upon receiving at least three positive (+1) maintainer votes, and no vetoes (-1), from existing maintainers after a one week period, the nominating maintainer asks the nominee whether they might be interested in becoming a maintainer on the repository via private e-mail message.
+
+> This is great work! Based on your valuable contribution and ongoing engagement with the project, the current maintainers invite you to become a co-maintainer for this project. Please respond and let us know if you accept the invitation to become maintainer.
+
+Individuals accept the nomination by replying, or commenting, for example _"Thank you! I would love to."_
+
+### Addition
+
+Upon receiving three positive (+1) maintainer votes, and no vetoes (-1), from other maintainers, and after having privately confirmed interest with the nominee, the maintainer opens a pull request adding the proposed co-maintainer to MAINTAINERS.md. The pull request is approved and merged.
+
+> _Content from the above nomination._
+>
+> The maintainers have voted and agreed to this nomination.
+
+Finally, the new maintainer's permissions are adjusted to reflect their new role.
+
+## Removing a Maintainer
+
+Removing a maintainer is a disruptive action that the community of maintainers should not undertake lightly. There are several reasons that a maintainer may be removed from the project including:
+
+- **Moving On.** There are plenty of reasons that might cause someone to want to take a step back or even a hiatus from a project.
+- **Inactivity.** Although maintainer status never expires, other maintainers may choose to remove anyone who has been inactive for a prolonged time (over six months).
+- **Violating the [code of conduct](./CODE_OF_CONDUCT.md)** or taking other actions that negatively impact the project.
+
+A maintainer can choose to leave the project at any time, with or without reason, by making a pull request to move themselves to the "Emeritus" section of MAINTAINERS.md, and asking an existing maintainer to remove their permissions.
+
+A maintainer can be removed by other maintainers, as set out in [governance](./GOVERNANCE.md).  Once the decision has been made to remove a maintainer, a pull request will be raised to move them to the "Emeritus" section of MAINTAINERS.md, and asking the existing maintainers will remove their permissions.
diff --git a/SECURITY.md b/SECURITY.md
@@ -0,0 +1,3 @@
+## Reporting a Vulnerability
+
+If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do **not** create a public GitHub issue.