Add definition of core and non-core subprojects #34
Conversation
estesp
force-pushed
the
core-and-non-core
branch
from
e242dd6 to
8f9c876
Compare
Signed-off-by: Phil Estes <[email protected]>
estesp
force-pushed
the
core-and-non-core
branch
from
8f9c876 to
679f411
Compare
|
I believe I have incorporated all suggestions/clarifications/updates based on the review comments. PTAL @crosbymichael, @dmcgowan, @AkihiroSuda, and @Random-Liu. |
|
LGTM |
| 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. |
There was a problem hiding this comment.
the current core maintainers (excluding non-core)?
There was a problem hiding this comment.
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?
| 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 |
There was a problem hiding this comment.
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. |
|
|
||
| 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 |
There was a problem hiding this comment.
s/for the containerd maintainers//
| stability, and any additional detail useful for the containerd maintainers to | ||
| understand the scope and nature of the project. | ||
|
|
||
| The existing maintainers are given five business days to discuss the new |
| 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. |
There was a problem hiding this comment.
This paragraph makes it clear... suggest moving to the top of the subprojects section under the title maintainer scope or something similar.
| 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 |
There was a problem hiding this comment.
How does one tell whether the project is core or non-core from looking at the repo?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
ACK. I think it's good to make the status more obvious so that users/contributors will have the correct expectations.
| 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 | ||
| understand the scope and nature of the project. |
There was a problem hiding this comment.
Is there any policy to remove under-maintained project?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I opened #36 so we deal with this in the document in the near future. Thanks!
|
We passed the required number of LGTMs and I believe all feedback was handled. Merging; anything I missed can be handled in follow-up issues/PRs |
Needs review and agreement from @containerd/containerd-maintainers. We have 2 projects in queue which I believe are non-core, but valuable projects to have within our GitHub organization. One of them is already in proposal here as #33
Signed-off-by: Phil Estes [email protected]
9 maintainer's LGTM required (2/3)