Skip to content

Commit

Permalink
Updates to reflect LF Governance model
Browse files Browse the repository at this point in the history
Signed-off-by: Phillip Ritter <[email protected]>
  • Loading branch information
Phillip Ritter committed Mar 18, 2021
1 parent 7043d36 commit ef34541
Show file tree
Hide file tree
Showing 4 changed files with 68 additions and 65 deletions.
54 changes: 27 additions & 27 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -84,35 +84,35 @@ 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):

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
Expand All @@ -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).
Expand All @@ -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
Expand All @@ -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.

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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:
Expand All @@ -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
Expand All @@ -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".
Expand All @@ -286,19 +286,19 @@ 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

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
Expand All @@ -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.
Portions of this contributing document are based on the [Kata Containers](https://github.com/kata-containers) contributing documentation.
43 changes: 16 additions & 27 deletions Governance.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
30 changes: 22 additions & 8 deletions Organization_of_Work.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).

Expand Down

0 comments on commit ef34541

Please sign in to comment.