Clean up the community membership & contributing docs (#634)

Consensys · Sep 5, 2022 · 19917f2 · 19917f2
1 parent 477e894
commit 19917f2
Show file tree

Hide file tree

Showing 2 changed files with 85 additions and 49 deletions.
diff --git a/COMMUNITY_MEMBERSHIP.md b/COMMUNITY_MEMBERSHIP.md
@@ -1,21 +1,24 @@
 # Community organisation and members responsibilities
 
-This doc outlines the various responsibilities of contributor roles in
-this project.
-
-| Role                | Responsibilities                             | Defined by                  |
-|---------------------|----------------------------------------------|-----------------------------|
-| Everyone            | none                                         | anybody with a belly button |
-| Member              | everyone who contributes - code or otherwise | Web3Signer GitHub org member     |
-| Approver            | approve accepting contributions              | write permissions on master |
-| Project Manager     | management of the project                    | ConsenSys                     |
-| Project Sponsor     | contribute developer resources               | ConsenSys                     |
-| Open Source Circle  | OSS support                                  | ConsenSys                     |
-| Project Evangelist  | promote the project                          | ConsenSys                     |
-| Benevolent Dictator | decision tie-breaker                         | ConsenSys                     |
+This doc outlines the various responsibilities of contributor roles in this
+project.
+
+| Role                | Responsibilities                             | Defined by                   |
+|---------------------|----------------------------------------------|------------------------------|
+| Everyone            | none                                         | anybody with a belly button  |
+| Member              | everyone who contributes - code or otherwise | Web3Signer GitHub org member |
+| Approver            | approve accepting contributions              | write permissions on master  |
+| Project Manager     | management of the project                    | ConsenSys                    |
+| Project Sponsor     | contribute developer resources               | ConsenSys                    |
+| Open Source Circle  | OSS support                                  | ConsenSys                    |
+| Project Evangelist  | promote the project                          | ConsenSys                    |
+| Benevolent Dictator | decision tie-breaker                         | ConsenSys                    |
 
 ## Everyone
-Any person from the public is able to access the code.  The standard permissions grant the ability to view the code, view open bugs, access the wiki, download binaries, view CI results and comment on pull requests.
+
+Any person from the public is able to access the code. The standard permissions
+grant the ability to view the code, view open bugs, access the wiki, download
+binaries, view CI results and comment on pull requests.
 
 ## New contributors
 
@@ -33,33 +36,42 @@ below.
 
 ## Member
 
-Members are continuously active contributors in the community.  They can have
+Members are continuously active contributors in the community. They can have
 issues and PRs assigned to them.
 
 ### Requirements
 
 - Enabled [two-factor authentication] on their GitHub account
-- Have made multiple contributions to the project or community.  Contribution may include, but is not limited to:
+- Have made multiple contributions to the project or community. Contribution may
+  include, but is not limited to:
     - Authoring or reviewing PRs on GitHub
     - Filing or commenting on issues on GitHub
-    - Contributing to community discussions (e.g. meetings, Slack, email discussion forums, Stack Overflow)
+    - Contributing to community discussions (e.g. meetings, Slack, email
+      discussion forums, Stack Overflow)
 - Joined [Web3Signer Discord]
 - Have read the [contributor guide]
 - Signed ICLA, as described in [CLA.md]
 
 ### Responsibilities and privileges
 
 - Responsive to issues and PRs assigned to them
-- Active owner of code they have contributed (unless ownership is explicitly transferred)
-  - Code is well tested
-  - Tests consistently pass
-  - Addresses bugs or issues discovered after code is accepted
+- Active owner of code they have contributed (unless ownership is explicitly
+  transferred)
+    - Code is well tested
+    - Tests consistently pass
+    - Addresses bugs or issues discovered after code is accepted
 - Members can do `/lgtm` on open PRs
-- They can be assigned to issues and PRs, and people can ask members for reviews with a `/cc @username`
+- They can be assigned to issues and PRs, and people can ask members for reviews
+  with a `/cc @username`
 
 ## Approver
 
-Code approvers are members that have signed an ICLA and have been granted additional commit privileges. While members are expected to provided code reviews that focus on code quality and correctness, approval is focused on holistic acceptance of a contribution including: backwards / forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, etc.
+Code approvers are members that have signed an ICLA and have been granted
+additional commit privileges. While members are expected to provided code
+reviews that focus on code quality and correctness, approval is focused on
+holistic acceptance of a contribution including: backwards / forwards
+compatibility, adhering to API and flag conventions, subtle performance and
+correctness issues, interactions with other parts of the system, etc.
 
 **Defined by:** write permissions on master branch
 
@@ -70,97 +82,125 @@ Code approvers are members that have signed an ICLA and have been granted additi
 - Approver status granted by Project Sponsor or the Open Source Circle
 
 ### Responsibilities and privileges
+
 - Includes all of the responsibilities and privileges of a Member user
 - Approver status may be a precondition to accepting large code contributions
 - Demonstrate sound technical judgement
 - Responsible for project quality control via [code reviews]
-  - Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards
-    compatibility, API and flag definitions, etc
+    - Focus on holistic acceptance of contribution such as dependencies with
+      other features, backwards / forwards
+      compatibility, API and flag definitions, etc
 - Expected to be responsive to review requests as per [community expectations]
 - Mentor members
 - May approve pull requests
 - May merge pull requests
 
 ## Project Manager
-The Project Manager role provides the user with control over management aspects of the project.  
+
+The Project Manager role provides the user with control over management aspects
+of the project.
 
 **Defined by:** ConsenSys
 
 ### Requirements
+
 - Includes all of the requirements of a Member user
 - Signed ICLA, as described in [CLA.md]
 - PM status granted by Project Sponsor or the Open Source Circle
 
 ### Responsibilities and privileges
+
 - Includes all of the responsibilities and privileges of a Member user
 - Determining releases
 - Managing roadmaps and access to Circle reports
 
-
-
 ## Project Sponsor
-The Project Sponsor role provides a user with the ability to contribute additional developer resources to the project.  Project Sponsors must sign the ICLA.
+
+The Project Sponsor role provides a user with the ability to contribute
+additional developer resources to the project. Project Sponsors must sign the
+ICLA.
 
 **Defined by:** ConsenSys
 
 ### Requirements
+
 - Signed ICLA, as described in [CLA.md]
 - Project Sponsor status granted by the Open Source Circle
 
 ### Responsibilities and privileges
+
 - Includes all of the responsibilities and privileges of a Member user
-- Approval of new users to the Approver role, and access to Circle reports.
+- Approval of new users to the Approver role, and access to Circle reports
 
 ## Open Source Circle
-The Open Source Circle is a group that provides open source software support to projects.
+
+The Open Source Circle is a group that provides open source software support to
+projects.
+
 **Defined by:** ConsenSys
 
 ### Requirements
+
 - Includes all of the requirements of a Member user
 - Signed ICLA, as described in [CLA.md]
 - Open Source Circle status granted by the Open Source Circle
 
 ### Responsibilities and privileges
+
 - Includes all of the responsibilities and privileges of a Project Sponsor
 - Ability to archive the project
 - Manage the CLA
 - Conduct legal reviews
 
 ## Project Evangelist
-The Project Evangelist role is for those who wish to promote the project to the outside world, but not actively contribute to it.  
+
+The Project Evangelist role is for those who wish to promote the project to the
+outside world, but not actively contribute to it.
+
 **Defined by:** ConsenSys
 
 ### Requirements
+
 - Includes all of the requirements of a Member user
 - Signed ICLA, as described in [CLA.md]
 - Project Evangelist status granted by the Open Source Circle
 
 ### Responsibilities and privileges
+
 - Includes all of the responsibilities and privileges of a Member user
 - Project Evangelist have the standard public access permissions
 - Organise talks
 - Work with marketing to manage web and graphical assets
 
 ## Benevolent Dictator
-The benevolent dictator, or project lead, is self-appointed. However, because the community always has the ability to fork, this person is fully answerable to the community.  The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project lead.
+
+The benevolent dictator, or project lead, is self-appointed. However, because
+the community always has the ability to fork, this person is fully answerable to
+the community. The key is to ensure that, as the project expands, the right
+people are given influence over it and the community rallies behind the vision
+of the project lead.
 
 ### Responsibilities and privileges
-- Set the strategic objectives of the project and communicate these clearly to the community
-- Understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term
-- Ensure that the approvers make the right decisions on behalf of the project
-- Provide final tie-breaker decisions when consensus cannot be reached.
 
+- Set the strategic objectives of the project and communicate these clearly to
+  the community
+- Understand the community as a whole and strive to satisfy as many conflicting
+  needs as possible, while ensuring that the project survives in the long term
+- Ensure that the approvers make the right decisions on behalf of the project
+- Provide final tie-breaker decisions when consensus cannot be reached
 
 ## Attribution
 
 This document is adapted from the following sources:
-- Kubernetes community-membership.md, available at [kub community membership].  
-- OSSWatch Benevolent Dictator Governance Model, available at [oss watch benevolent dictator].  
+
+- Kubernetes community-membership.md, available at [kub community membership]
+- OSSWatch Benevolent Dictator Governance Model, available
+  at [oss watch benevolent dictator]
 
 [CLA.md]: /CLA.md
 [oss watch benevolent dictator]: http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel
 [kub community membership]: https://raw.githubusercontent.com/kubernetes/community/master/community-membership.md
-[code reviews]: /docs/community/code-reviews.md
+[code reviews]: /CONTRIBUTING.md#code-reviews
 [contributor guide]: /CONTRIBUTING.md
 [New contributors]: /CONTRIBUTING.md
 [two-factor authentication]: https://help.github.com/articles/about-two-factor-authentication

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -15,12 +15,11 @@ and feel free to propose changes to this document in a pull request.
   * [Suggesting Enhancements](#suggesting-enhancements)
   * [Your First Contribution](#your-first-contribution)
   * [Pull Requests](#pull-requests)
-  * [Code Reviews](#code-review)
+  * [Code Reviews](#code-reviews)
 
 [Style Guides](#style-guides)
   * [Java Style Guide](#java-code-style-guide)
   * [Coding Conventions](#coding-conventions)
-  * [Git Commit Messages & Pull Request Messages](#git-commit-messages--pull-request-messages)
 
 [Pull Request Labels](#pull-request-labels)
 
@@ -161,11 +160,11 @@ For this reason do not mix any formatting fixes or code moves with actual code c
 another part of the software. Running the `./gradlew clean check test` command locally will help you
 to be confident that your changes will pass CI tests once pushed as a Pull Request.
 1. **Push your changes** to your remote fork (usually labeled as `origin`).
-1. **Create a pull-request** (PR) on the Web3Signer repository. If the PR addresses an existing Jira issue, 
+1. **Create a pull-request** (PR) on the Web3Signer repository. If the PR addresses an existing Jira issue,
 include the issue number in the PR title in square brackets (for example, `[ES-2374]`). 
 1. **Add labels** to identify the type of your PR. _For example, if your PR is not ready to validate,
 add the "work-in-progress" label. If it fixes a bug, add the "bug" label._
-1. If the PR address an existing Jira issue, comment in the Jira issue with the PR number. 
+1. If the PR address an existing Jira issue, comment in the Jira issue with the PR number.
 1. **Ensure your changes are reviewed**.
 _Select the reviewers you would like to review your PR.
 If you don't know who to choose, simply select the reviewers proposed by GitHub or leave blank._
@@ -211,10 +210,10 @@ explaining why you believe the failure is unrelated. A maintainer will re-run th
 If we conclude that the failure was a false positive, then we will open an issue to track that problem 
 with our status check suite.</details>
 
-## Code Review
+## Code Reviews
 While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) 
 may ask you to complete additional design work, tests, or other changes before your pull request 
-can be ultimately accepted.  Please refer to [Code Reviews].
+can be ultimately accepted.
 
 # Style Guides
 
@@ -234,8 +233,6 @@ These are not strictly enforced during the build, but should be adhered to and c
 
 # Pull Request Labels
 
-#### Pull Request Labels
-
 | Label name                                                              | Description                                                                                |
 |-------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
 | [`work-in-progress`][search-label-work-in-progress]                     | Pull requests which are still being worked on, more changes will follow.                   |
@@ -247,7 +244,6 @@ These are not strictly enforced during the build, but should be adhered to and c
 [GitHub]: https://github.com/ConsenSys/web3signer
 [Web3Signer documentation]: https://docs.web3signer.consensys.net/en/latest/
 [CLA.md]: /CLA.md
-[Code Reviews]: /community/code-reviews.md
 [MkDocs]: https://www.mkdocs.org/
 [How to Write a Git Commit Message]: https://chris.beams.io/posts/git-commit/
 [Chris Beams]: https://github.com/cbeams