Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add definition of core and non-core subprojects #34

Merged
merged 1 commit into from
Oct 18, 2019
Merged

Add definition of core and non-core subprojects #34

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 61 additions & 9 deletions GOVERNANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,19 +61,71 @@ maintainer has already discussed the candidacy with the candidate and a
maintainer is willing to be a sponsor by opening the pull request. The candidate
becomes a maintainer once the pull request is merged.

## Adding sub-projects

Similar to adding maintainers, new sub projects can be added to containerd
GitHub organization as long as they adhere to the CNCF
[charter](https://www.cncf.io/about/charter/) and mission. After a project
proposal has been announced on a public forum (GitHub issue or mailing list),
the existing maintainers are given five business days to discuss the new
## Subprojects

containerd subprojects are divided into two flavors currently: **core** and
**non-core**. Most of the repositories within the containerd GitHub organization are
"core" to the delivery of the containerd runtime project's releases. For example,
the Golang implementations of the cgroups, runc, and console APIs, the ttrpc
implementation, and various built-in plugins like the CRI implementation. These, among a
handful of other repositories, are all **core** and required pieces which culminate
in officially supported and maintained releases of containerd.

Non-core projects have a strong affiliation with the containerd runtime, but
operate similarly to the traditional `contrib/` directory in many open source
projects. In most cases the maintainer list will be unique and the project can
have unique release, support, and maintainer processes. Non-core projects may be
written in other languages and therefore require different skills, developer
tools, and CI systems than the core projects. For these reasons, non-core
subprojects have a few unique properties that are described in the section
"_Adding non-core subprojects_" below.

Both core and non-core subprojects must adhere to the CNCF
[charter](https://www.cncf.io/about/charter/) and mission.

### Adding core subprojects

New core subprojects can request to be added to the containerd GitHub
organization by submitting a project proposal via public forum (a
`containerd/project` GitHub issue is the easiest way to provide this proposal).
The existing maintainers are given five business days to discuss the new
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/The existing/The existing core/

Since this topic is for adding core sub-projects...

project, raise objections and cast their vote. Projects must be approved by at
least 66% of the current maintainers by adding their vote.
least 66% of the current maintainers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the current core maintainers (excluding non-core)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered going through this document and adding "core" in front of the word maintainers all the way through, but that seemed like overkill. Anything to do with overall project governance always means the core maintainers as represented in the containerd/project MAINTAINERS file. Maybe I should just add a single sentence in the opening matter to that effect?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/the current/said/


If a project is approved, a maintainer will add the project to the containerd
GitHub organization, and make an announcement on a public forum.

Please add the suggested text from our [Project core documents](./README.md#project-core-documents) section
to your `README.md`.

### Adding non-core subprojects

Non-core subprojects will also submit a project proposal via public forum, and
should state that the project is expected to be **non-core**.

The proposal should include a proposed list of maintainers who will manage
the non-core project and provide general information on support, releases,
stability, and any additional detail useful for the containerd maintainers to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/for the containerd maintainers//

understand the scope and nature of the project.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any policy to remove under-maintained project?

Copy link
Member Author

@estesp estesp Oct 11, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have that for any kind of project within our GitHub organization. It is up to us if we want to add that kind of policy, but by default any change can be proposed and approved with 2/3rds of maintainers approval (per our standard governance process). This would mean any core maintainer can propose that an under-maintained project be removed from the organization and have a discussion and vote. I would prefer doing that in a separate PR if we think we need a clear process (and to be clear, I'm not opposed to calling it out)

Copy link
Member

@yujuhong yujuhong Oct 11, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SG. I was just curious whether there were any existing policy. Just like code in contrib, I expect some non-core projects may not get enough care and attention after a while.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened #36 so we deal with this in the document in the near future. Thanks!


The existing maintainers are given five business days to discuss the new
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same suggested edit as above.

project, raise objections and cast their vote. Projects must be approved by at
least 66% of the current maintainers.

If a project is approved, a core maintainer will add the project to the containerd
GitHub organization and provide write access for that repository to the proposed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does one tell whether the project is core or non-core from looking at the repo?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the guidance provided in the README.md change in this PR would make it distinguishable as non-core projects will clearly state their status.

It is up to us as core maintainers to validate this when accepting new non-core projects into the organization.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. I think it's good to make the status more obvious so that users/contributors will have the correct expectations.

maintainer list, as well as make an announcement on a public forum.

Unlike core maintainers, non-core project maintainers are responsible for maintenance
tasks in their subproject only. Core maintainers have maintainer privileges across
all core and non-core projects to help contribute to project health, maintenance,
and release processes within the GitHub organization. For ease of list management,
the `MAINTAINERS` file of a non-core project will only list the non-core project
maintainers—the core maintainers of containerd will not be appended to each subproject.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph makes it clear... suggest moving to the top of the subprojects section under the title maintainer scope or something similar.


Please add the suggested text from our [Non-core project documents](./README.md#non-core-project-documents)
section to your `README.md`.

## Stepping down policy

Life priorities, interests, and passions can change. If you're a maintainer but
Expand Down Expand Up @@ -151,6 +203,6 @@ made through a pull request.

If you have a technical dispute that you feel has reached an impasse with a
subset of the community, any contributor may open an issue, specifically
calling for a resolution vote of the current maintainers to resolve the dispute.
calling for a resolution vote of the current core maintainers to resolve the dispute.
The same voting quorums required (2/3) for adding and removing maintainers
will apply to conflict resolution.
10 changes: 10 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,3 +52,13 @@ As a containerd sub-project, you will find the:
information in our [`containerd/project`](https://github.com/containerd/project) repository.
```

### Non-core project documents

If your project is a non-core addition to the containerd GitHub organization, please
make the following changes to your project once approved and added:

* Clearly state in an opening sentence within your project `README.md` that "_Project X is
a **non-core** subproject of containerd_"
* Add the project details boilerplate provided above with the following two changes:
1. The first line should be modified to state: _{Some-project} is a **non-core** containerd subproject_
2. Do not link to the core `MAINTAINERS` file in `containerd/project`. That link should be modified to point to your existing non-core project `MAINTAINERS` file.