Instead of granting people outright admin access we should limit the
scope. Github offers us a org wide "CI/CD Admin" rule that can be used
to manage all the import CI configs. In particular I assigned that role
to Ashley as she requires that access to manage the macos worker pool.
Using the roles to limit access is better for security as we do not have
to give out Admin or org wide Owner access then.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As part of our move into the podman-container-tools org and our
migration to GH Actions CI, we moved several additional
repositories into the Podman Container Tools CNCF project. These
include container-libs (core libraries used by Podman and CRI-O),
podman-machine-os (builds OS images used by `podman machine`),
and automation (tools and scripts for maintaining our CI). All
of these went through the subproject process documented in our
governance and are now subprojects, so let's get them listed in
the governance.
Signed-off-by: Matt Heon <mheon@redhat.com>
Define the team rules we already used before, this makes it explicitly
how the users should be given their access.
In short we should add users to the github teams and not add them
individually to the repos.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We were asked about adding podman-py to the project, which seems
entirely sensible given how strongly related it is. However, we
don't actually have a process to do this right now. I added a
section on adding and removing subprojects, based on the CNCF
governance-by-subprojects template.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We were going through our Github permissions to make sure they
were consistent with MAINTAINERS.md when we realized that we did
not make it explicit what each level in our contributor ladder
should receive for permissions. This fixes that oversight. We
retain some flexibility (e.g. granting Triage to anyone who is
assisting with the project, but not enough to become a Reviewer)
but core privileges are now spelled out explicitly.
Signed-off-by: Matt Heon <mheon@redhat.com>
We'd like our community managers to be able to assist in issue
triage - mostly to justify giving them the Github permissions to
add and edit labels on issues in the project.
As community managers are not expected to be technical, we're not
expecting them to act fully as reviewers, but letting them move
issues between repos, close issues that have gotten out of hand
and are accumulating CoC violations, and label persistent
problems as things that should be strongly considered for future
releases are valuable.
Signed-off-by: Matt Heon <matthew.heon@pm.me>
When I worked up changes to Buildah's Governance, I found
that Podman's version was missing a few links, and there were
a few minor grammatical tweaks needed.
This addresses those.
For reference, Buildah's Governance Update PR: https://github.com/containers/buildah/pull/6124
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
I noticed that the GOVERNANCE.md file did not have links to the
MAINTAINERS.md file. Also added a link or two to the OWNERS file.
This change just adds links and does not change any wording.
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
Firstly, include both subprojects in the model and link to them.
Ensures complete clarity on what is part of the Podman Project in
CNCF.
Secondly, add that Community Managers are expected to take notes
on Core Maintainer meetings and make those notes available to the
public.
Signed-off-by: Matt Heon <mheon@redhat.com>
This is the initial version of the governance model we're looking
to implement. It is still very early, and comments and
suggestions are very welcome!
Signed-off-by: Matt Heon <mheon@redhat.com>
