From ef3454104249923becfd6ac75028251d9afdf78e Mon Sep 17 00:00:00 2001 From: Phillip Ritter Date: Thu, 18 Mar 2021 16:30:17 -0700 Subject: [PATCH] Updates to reflect LF Governance model Signed-off-by: Phillip Ritter --- CONTRIBUTING.md | 54 ++++++++++++++++++++--------------------- Governance.md | 43 ++++++++++++-------------------- Organization_of_Work.md | 30 +++++++++++++++++------ README.md | 6 ++--- 4 files changed, 68 insertions(+), 65 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6ab8067..1726582 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,7 +37,7 @@ In the event that you push a commit without signing off, you can amend the commi ```sh $ git commit -s --amend --no-edit -$ git push --force +$ git push --force ``` ## Repository specific contribution guides @@ -84,7 +84,7 @@ The issue is automatically closed by GitHub when the ##### Fork and clone -In this example, we configure a Git environment to contribute to this very +In this example, we configure a Git environment to contribute to this very `Community` repo. We create a sample branch, incorporate reviewer feedback, and rebase our commits. 1. Fork the [upstream repository](https://help.github.com/articles/cloning-a-repository): @@ -92,27 +92,27 @@ In this example, we configure a Git environment to contribute to this very 1. [Clone your forked copy of the upstream repository](https://help.github.com/articles/cloning-a-repository): 1. While on your *forked copy*, select the green button `Clone or download` - and copy the URL. + and copy the URL. 1. Run the commands below and **paste the copied URL** (previous step), so your real GitHub user name replaces `your-github-username` below. - + ```sh $ git clone https://github.com/{your-github-username}/community $ cd community ``` - + >**Note:** Cloning a forked repository automatically gives a remote `origin`. ##### Configure the upstream remote Next, add the remote `upstream`. Configuring this remote allows you to -synchronize your forked copy, `origin`, with the `upstream`. The -`upstream` URL varies by repository. We use the `upstream` from the Community for this example. +synchronize your forked copy, `origin`, with the `upstream`. The +`upstream` URL varies by repository. We use the `upstream` from the Community for this example. -1. Change directory into `community`. +1. Change directory into `community`. -1. Set the remote `upstream` as follows. +1. Set the remote `upstream` as follows. ```sh $ git remote add upstream https://github.com/magma/community @@ -121,10 +121,10 @@ synchronize your forked copy, `origin`, with the `upstream`. The 1. Run `git remote -v`. Your remotes should appear similar to these: ``` - origin https://github.com/your-github-username/community.git (fetch) - origin https://github.com/your-github-username/community.git (push) - upstream https://github.com/magma/community.git (fetch) - upstream https://github.com/magma/community.git (push) + origin https://github.com/your-github-username/community.git (fetch) + origin https://github.com/your-github-username/community.git (push) + upstream https://github.com/magma/community.git (fetch) + upstream https://github.com/magma/community.git (push) ``` For more details, see how to [set up a git remote](https://help.github.com/articles/configuring-a-remote-for-a-fork). @@ -137,7 +137,7 @@ For more details, see how to [set up a git remote](https://help.github.com/artic $ git checkout -b fix-spelling-errors ``` - >**Warning:** *Never* make changes directly to the `master` or `main` + >**Warning:** *Never* make changes directly to the `master` or `main` > branch--*always* create a new "topic branch" for PR work. 1. Make some editorial changes. In this example, we modify the file that @@ -161,7 +161,7 @@ For more details, see how to [set up a git remote](https://help.github.com/artic >**Note:** The `-u` option tells `git` to "link" your local clone with > your remote fork so that it knows from now on that the local repository - > and the remote fork refer to "the same" upstream repository. Strictly + > and the remote fork refer to "the same" upstream repository. Strictly >speaking, this option is only required the first time you call `git push` >for a new clone. @@ -189,7 +189,7 @@ $ git log main.. --oneline --decorate=no 60e2b2b doh - missed one ``` ->**Note:** The `git log` command compares your current branch +>**Note:** The `git log` command compares your current branch >(`fix-spelling-errors`) with the `main` branch and lists all the commits, >one per line. @@ -233,7 +233,7 @@ multiple commits on your branch. Follow these steps. pick 3a4ba3f doh - missed one ``` -1. In your editor, read the comments at the bottom of the screen. +1. In your editor, read the comments at the bottom of the screen. Do not modify the first line, `pick 2e335ac docs: Fix typos ...`. Instead, revise `pick` to `squash` at the start of all following lines. Example output: @@ -246,11 +246,11 @@ multiple commits on your branch. Follow these steps. ``` 1. Save your changes and quit the editor. Git puts you *back* into your - editor. You will see all the commit *messages*. + editor. You will see all the commit *messages*. -1. At top is your first commit, which should be in the - [correct format](#patch-format). Keep your first commit and delete - all the following commits, as appropriate, based on +1. At top is your first commit, which should be in the + [correct format](#patch-format). Keep your first commit and delete + all the following commits, as appropriate, based on the review feedback. 1. Save the file and quit the editor. Once this operation completes, the four @@ -275,7 +275,7 @@ multiple commits on your branch. Follow these steps. >those changes into your PR branch. This ensures your fork is now "up to >date" with the upstream repository. The `-f` option is a "force push". Since >you created a new commit using `git rebase`, you must "overwrite" the old ->copy of your branch in your fork on GitHub. +>copy of your branch in your fork on GitHub. Your PR is now updated on GitHub. To ensure team members are aware of this, leave a message on the PR stating something like, "Review feedback applied". @@ -286,7 +286,7 @@ This notification allows the team to once again review your PR more quickly. Before your PRs are merged into the main code base, they are reviewed. We encourage anybody to review any PR and leave feedback. -The [Reviewing Guide](Reviewing.md) provides more information on the +The [Reviewing Guide](Reviewing.md) provides more information on the responsibilities of maintainers and the process for reviewing a PR. ## Contact @@ -294,11 +294,11 @@ responsibilities of maintainers and the process for reviewing a PR. The Magma community can be reached [through various channels](https://www.magmacore.org). -## Project maintainers +## Project committers -The Magma project maintainers are the people accepting or +The Magma project committers are the people accepting or rejecting any PR. Although [anyone can review PRs](#reviews), only the -review of a maintainer counts towards the approval of a PR. +review of a committer counts towards the approval of a PR. Approvers are listed in GitHub teams for each repository. The project uses the @@ -308,4 +308,4 @@ along with the [GitHub `CODEOWNERS`file](https://help.github.com/en/articles/abo #### Acknowledgements -Portions of this contributing document are based on the [Kata Containers](https://github.com/kata-containers) contributing documentation. \ No newline at end of file +Portions of this contributing document are based on the [Kata Containers](https://github.com/kata-containers) contributing documentation. diff --git a/Governance.md b/Governance.md index 2c8d008..184b93b 100644 --- a/Governance.md +++ b/Governance.md @@ -7,39 +7,28 @@ technical decisions are made by technical contributors and a representative body accessible to every contributor, is a critical part in establishing a truly open community. -Magma's project open governance model will be put in place in several steps, -in order to give time for the common team to form from various corporate -workgroups, and to allow natural leaders to emerge. +Magma's open technical governance, as detailed in its [Technical Charter](https://github.com/magma/tsc/blob/main/CHARTER.md), is built around the +the following model: -## Step 1 (current): Interim governance +## Contributers -At this early stage in the formation of the project, Magma is currently -operating with minimal viable governance. Early critical project decisions -are generally made in two areas: approving code changes for inclusion into -Magma, and early release and roadmap decisions. +Anyone may become a contributer to the Magma project. A contributer is someone who contributes code to the prject github repository, initiates or comments on github issues or contributes to the project in any other way. Magma's contributers are its community. -For the first area, Magma uses GitHub maintainers groups. New maintainers -must be nominated and approved by established maintainers through a simple -majority with no existing maintainer objecting. +## Committers -For the second area, Magma uses a Release Management team, with the following -individuals: +Committers are contributers who have earned the right to make modifications to the Magma github repository, as set forth in the [CONTRIBUTING file](https://github.com/magma/community/blob/main/CONTRIBUTING.md). Committers are able to merge code or otherwise modify the Magma github repository. Committers may be added to or removed from the project by a majority vote of existing committers, with no single committer objecting. -- Michael Callahan -- Jacky Tian (@xjtian) -- Sanaz Bazargan +Issues may be raised to the Committers on the "#goverance-committers-ama" channel on the Magma Slack -Addition of new members requires approval of all current release management -team members. +## The Technical Steering Committee -## Step 2: Initial governance +The Committers of the project will elect 5 of their members to serve as a Technical Steering Committee (TSC) for the project. The TSC will be responsible for all technical oversight of the project. -Magma will initially be governed by a Technical Committee with members -appointed by Magma’s 3 sponsoring organizations, OIA, TIP and OIF. At that -point, the TC will be responsible for further updates to Governance documents. +As of March 11, 2021, the project TSC members are: +- Hunter Gatewood (hcgatewood) +- Marie Bremner (@themarwhal) +- Raphael Defosseux (@rdefosse) +- Scott Moeller (@electronjoe) +- Pravin Shelar (@pshelar) -This initial TC will be tasked with: - -- appointing additional TC members as natural leaders emerge -- establishing initial operating procedures and governance for the project -- handling the transition to a fully-elected representation in the future +Issues may be raised to the TSC on the "#goverance-tsc-ama" channel on the Magma Slack diff --git a/Organization_of_Work.md b/Organization_of_Work.md index 069460f..7dd60b4 100644 --- a/Organization_of_Work.md +++ b/Organization_of_Work.md @@ -2,20 +2,34 @@ ## Roles +The following is a high-level summary of the Magma project's roles as defined in [Magma's Technical Charter](https://github.com/magma/tsc/blob/main/CHARTER.md). + ### Contributors Anyone can become a Contributor by submitting a pull request to the project and having that change accepted through the project’s review process. A Contributor is someone who has had code merged within the last 12 months. -Contributors are eligible to vote in governance elections. Contributors have -access to propose and review code but not merge the code into repos of the -project. +Contributors have access to propose and review code but not merge the code +into repos of the project. -### Maintainers +### Committers -A Maintainer has the ability to merge code into the project. Maintainers are +A Committer has the ability to merge code into the project. Committers are active Contributors and participants in the project. In order to become a -Maintainer, you must be nominated and approved by the established Maintainers, -through a simple majority vote with no existing maintainer objecting. -Within the project, sub-components may decide to have additional requirements +Committer, you must be nominated and approved by the established Committers +through a simple majority vote. Within the project, sub-components may decide to have additional requirements for the review of code in their repos. + +### Technical Steering Committee (TSC) + +The TSC consists of 5 members nominated and elected by the project's Committers. +The Technical Steering Committee (the “TSC”) will be responsible for all technical +oversight of the open source Project. + +As of March 11, 2021 the TSC members are: + +- Scott Moeller (@electronjoe) +- Raphael Defosseux (@rdefosse) +- Pravin Shelar (@pshelar) +- Hunter Gatewood (@hcgatewood) +- Marie Bremner (@themarwhal) diff --git a/README.md b/README.md index e2a07e7..9f445e3 100644 --- a/README.md +++ b/README.md @@ -9,12 +9,12 @@ Magma is an open-source software platform that gives network operators an open, ## Join the Magma Community -- Mailing lists: - - Join [magma-dev](https://groups.google.com/forum/#!forum/magma-dev) for technical discussions - - Join [magma-announce](https://groups.google.com/forum/#!forum/magma-announce) for announcements - Slack: - [Magma](https://magmacore.slack.com) workspace - [Slack Invite](https://join.slack.com/t/magmacore/shared_invite/zt-g76zkofr-g6~jYiS3KRzC9qhAISUC2A) +- Mailing lists: + - Join [magma-dev](https://groups.google.com/forum/#!forum/magma-dev) for technical discussions + - Join [magma-announce](https://groups.google.com/forum/#!forum/magma-announce) for announcements All community members should abide to our [Code of Conduct](CODE_OF_CONDUCT.md).