mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-08-26 03:29:02 +00:00
Merge pull request #106 from jodh-intel/add-rota-doc
docs: Add new Rota doc
This commit is contained in:
James O. D. Hunt
GitHub
commit
cbd8d0ef9a
@ -5,6 +5,7 @@
|
||||
* [Join Us](#join-us)
|
||||
* [Users](#users)
|
||||
* [Contributors](#contributors)
|
||||
* [Review Team](#review-team)
|
||||
* [Governance](#governance)
|
||||
* [Developers](#developers)
|
||||
* [Contributor](#contributor)
|
||||
@ -51,6 +52,10 @@ distribution.
|
||||
|
||||
See the [contributing guide](CONTRIBUTING.md) for details on how to contribute to the project.
|
||||
|
||||
## Review Team
|
||||
|
||||
See the [rota documentation](Rota-Process.md).
|
||||
|
||||
# Governance
|
||||
|
||||
The Kata Containers project is governed according to the ["four opens"](https://governance.openstack.org/tc/reference/opens.html), which are open source, open design, open development, and open community. Technical decisions are made by technical contributors and a representative Architecture Committee. The community is committed to diversity, openness, and encouraging new contributors and leaders to rise up.
|
||||
|
||||
328
Rota-Process.md
Normal file
328
Rota-Process.md
Normal file
@ -0,0 +1,328 @@
|
||||
# Kata Rota Process
|
||||
|
||||
* [Introduction](#introduction)
|
||||
* [Kata Review Team](#kata-review-team)
|
||||
* [The rota](#the-rota)
|
||||
* [Who can join?](#who-can-join)
|
||||
* [How can I participate?](#how-can-i-participate)
|
||||
* [Preparation](#preparation)
|
||||
* [Reviewing documentation changes](#reviewing-documentation-changes)
|
||||
* [Tasks](#tasks)
|
||||
* [Talk to each other](#talk-to-each-other)
|
||||
* [PRs](#prs)
|
||||
* [Review PR backlog](#review-pr-backlog)
|
||||
* [Triggering a CI run](#triggering-a-ci-run)
|
||||
* [CI results](#ci-results)
|
||||
* [Stale PRs](#stale-prs)
|
||||
* [Temporarily blocking a PR from landing](#temporarily-blocking-a-pr-from-landing)
|
||||
* [Stable branches](#stable-branches)
|
||||
* [Issues](#issues)
|
||||
* [Review issues](#review-issues)
|
||||
* [Issue labels](#issue-labels)
|
||||
* [Issue triage](#issue-triage)
|
||||
* [General process](#general-process)
|
||||
* [Test stability](#test-stability)
|
||||
* [Weekly Summary](#weekly-summary)
|
||||
|
||||
## Introduction
|
||||
|
||||
This document explains the structure and roles of the Kata Review Team.
|
||||
|
||||
## Kata Review Team
|
||||
|
||||
The Kata Containers project runs a [rolling rota of members and volunteers](#the-rota)
|
||||
who donate their time to assess, review, move forward, and reduce any PR and
|
||||
issue backlogs across the repositories.
|
||||
|
||||
Informally, this team is sometimes referred to as the "Kat Herding Team".
|
||||
|
||||
## The rota
|
||||
|
||||
The rota is maintained in the
|
||||
[community wiki](https://github.com/kata-containers/community/wiki/Review-Team-Rota),
|
||||
which is updated frequently.
|
||||
|
||||
## Who can join?
|
||||
|
||||
Anybody can participate. You do **not** have to be a subject matter expert or Kata
|
||||
expert to help. All contributions are welcome.
|
||||
|
||||
Joining the team is a great way to expand your knowledge of the project and
|
||||
your skill set. Sometimes all you need to move a PR forward is for a community
|
||||
member to read the list of open PRs and ask the appropriate subject matter
|
||||
expert to review or help with the relevant PR.
|
||||
|
||||
Note that you must agree to our [code of conduct](CODE_OF_CONDUCT.md)
|
||||
if you want to become involved.
|
||||
|
||||
## How can I participate?
|
||||
|
||||
To participate and be added to the [the rota](#the-rota),
|
||||
notify the Kata team through one of the contact methods listed on
|
||||
https://katacontainers.io before you edit this page. Be sure to include your
|
||||
contact details in the Rota table, preferably your GitHub name.
|
||||
|
||||
## Preparation
|
||||
|
||||
Before you join the team, we strongly recommend that you read the
|
||||
[contribution guide](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md).
|
||||
We suggest you also read the
|
||||
[PR review guide](https://github.com/kata-containers/community/blob/master/PR-Review-Guide.md)
|
||||
for tips to consider as you review [pull requests](#prs).
|
||||
|
||||
### Reviewing documentation changes
|
||||
|
||||
We suggest you read the
|
||||
[documentation requirements](https://github.com/kata-containers/documentation/blob/master/Documentation-Requirements.md)
|
||||
and
|
||||
[documentation review process](https://github.com/kata-containers/community/blob/master/Documentation-Review-Process.md)
|
||||
to help you review documentation changes.
|
||||
|
||||
## Tasks
|
||||
|
||||
This section lists which activities the team should focus on.
|
||||
|
||||
### Talk to each other
|
||||
|
||||
If you are on the review team, we suggest you hang out on
|
||||
[Slack or IRC](README.md#join-us) in order to chat with each other. Nobody
|
||||
knows everything so do not hesitate to ask other folks on the team if you need
|
||||
help.
|
||||
|
||||
There is a useful wiki page that
|
||||
[lists areas of interest for various members of the community](https://github.com/kata-containers/community/wiki/Areas-of-interest).
|
||||
|
||||
We also have a
|
||||
[central GitHub `CODEOWNERS` file](https://github.com/kata-containers/.github/blob/master/CODEOWNERS).
|
||||
This [file type](https://help.github.com/en/articles/about-code-owners)
|
||||
defines individuals or teams that are responsible for code in a repository.
|
||||
This can help identify the appropriate group of people to contact about
|
||||
certain file changes.
|
||||
|
||||
### PRs
|
||||
|
||||
#### Review PR backlog
|
||||
|
||||
See [the GitHub reports](https://github.com/kata-containers/community/wiki/Review-Team-Rota#finding-the-open-prs)
|
||||
for a list of open PRs.
|
||||
|
||||
Read
|
||||
[the reviews section in the contributing guide](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#reviews)
|
||||
to learn how to "ack" a PR.
|
||||
|
||||
##### Triggering a CI run
|
||||
|
||||
See the [Controlling the CI](https://github.com/kata-containers/community/wiki/Controlling-the-CI) document.
|
||||
|
||||
##### CI results
|
||||
|
||||
When you review a PR, look at any CI failures shown at the bottom of the PR
|
||||
page. If any CI tests fail, review the logs to see if there are obvious
|
||||
issues.
|
||||
|
||||
Add a comment and a brief summary of the error message or issue to explain
|
||||
which CIs failed.
|
||||
|
||||
##### Stale PRs
|
||||
|
||||
If a PR has not been touched for a while, add a comment to ask the author if
|
||||
they intend to update the pull request.
|
||||
|
||||
If the author does not respond, we may decide to use the
|
||||
[assisted PR workflow](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#assisted-pr-workflow),
|
||||
which you can also take part in.
|
||||
|
||||
##### Temporarily blocking a PR from landing
|
||||
|
||||
See [this section in the contributing guide](CONTRIBUTING.md#temporarily-blocking-a-pr).
|
||||
|
||||
##### Stable branches
|
||||
|
||||
If a PR is just a fix, add the `stable-candidate` label and ask the author to
|
||||
backport the fix to the last two
|
||||
[stable branches](https://github.com/kata-containers/documentation/blob/master/Stable-Branch-Strategy.md).
|
||||
|
||||
### Issues
|
||||
|
||||
#### Review issues
|
||||
|
||||
See [the GitHub report](https://github.com/kata-containers/community/wiki/Review-Team-Rota#finding-new-issues)
|
||||
for a list of issues that need a review.
|
||||
|
||||
##### Issue labels
|
||||
|
||||
All the repositories use a
|
||||
[standard set](https://github.com/kata-containers/tests/blob/master/cmd/github-labels/labels.yaml.in)
|
||||
of GitHub labels. For example, here are the `runtime` repositories labels:
|
||||
|
||||
- https://github.com/kata-containers/runtime/issues/labels
|
||||
|
||||
Review the list and become familiar with the labels, and then read on.
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
> - All labels have a description to explain their use.
|
||||
>
|
||||
> - There *are* a lot of labels but only to cover as many scenarios as
|
||||
> possible. Most issues only need a small number of labels to be
|
||||
> applied to them.
|
||||
|
||||
##### Issue triage
|
||||
|
||||
Read each new issue carefully. Each issue is an arbitrary description of the
|
||||
problem or request, so we want to add meaningful labels to each for easier
|
||||
categorization and search.
|
||||
|
||||
If you are unsure of which labels to apply to an issue, talk to the rest of
|
||||
the [Rota team](#talk-to-each-other) or just ask
|
||||
[on Slack/IRC](https://github.com/kata-containers/community#join-us).
|
||||
|
||||
Here is some general advice:
|
||||
|
||||
- Security issue
|
||||
|
||||
Use the
|
||||
[Vulnerability Management Process (VMP)](https://github.com/kata-containers/community/blob/master/VMT/VMT.md)
|
||||
to handle serious security issues.
|
||||
|
||||
However, [immediately contact the team](https://github.com/kata-containers/community#join-us)
|
||||
for advice if you notice a user has raised a normal issue (i.e. does not
|
||||
follow the VMP) that appears to be a security issue. The `security` label
|
||||
should be added to the issue if it does not need to follow the VMP.
|
||||
|
||||
- "Crasher bug"
|
||||
|
||||
If an issue reports a crash or catastrophic error scenario add one or more
|
||||
of the following relevant labels:
|
||||
|
||||
- `crash`
|
||||
- `data-loss`
|
||||
- `hang`
|
||||
- `resource-leak`
|
||||
- `unreliable`
|
||||
|
||||
If you add one of the previous labels,
|
||||
[contact the team](https://github.com/kata-containers/community#join-us)
|
||||
to make them aware of the issues as soon as possible.
|
||||
|
||||
- Top priority
|
||||
|
||||
Add the `highest-priority` label to flag and alert the team of extremely
|
||||
urgent issues. This indicates to the team that the issue should be fixed as
|
||||
soon as possible.
|
||||
|
||||
- Release gating
|
||||
|
||||
Add the `release-gating` label if you think the issue should be fixed before
|
||||
the next release.
|
||||
|
||||
- Important medium / long term task
|
||||
|
||||
Add the `highest-severity` label if the issue is very important but not
|
||||
time-critical.
|
||||
|
||||
- Simple task for new contributors
|
||||
|
||||
Add the `good-first-issue` label if you think the issue is simple with a
|
||||
quick resolution and "self-contained." This marks it as suitable for a new
|
||||
contributor.
|
||||
|
||||
- Invalid
|
||||
|
||||
Add the `invalid` label if you think the issue is not appropriate.
|
||||
|
||||
- Duplicate
|
||||
|
||||
Add the `duplicate` label along with a comment referencing the original
|
||||
issue if you find a duplicated issue.
|
||||
|
||||
- Limitation
|
||||
|
||||
Add the `limitation` label if the issue describes a system limitation.
|
||||
|
||||
If the issue is a
|
||||
[known limitation](https://github.com/kata-containers/documentation/blob/master/Limitations.md),
|
||||
close the issue with a comment referencing the original limitation issue
|
||||
number so the issue author understands why the issue was closed.
|
||||
|
||||
- Teams
|
||||
|
||||
Add one of the `team/*` labels if you know which team the issue should be
|
||||
assigned to. Note, while some team names are the same as the
|
||||
[respective repository](https://github.com/kata-containers),
|
||||
some are general (e.g. `team/developer`).
|
||||
|
||||
Add a comment to include the name of the team (use the `@team-name` syntax)
|
||||
if you know the GitHub team a particular label relates to. All teams are
|
||||
listed [here](https://github.com/orgs/kata-containers/teams).
|
||||
[Contact the team](README.md#join-us) if you do not have access to this list.
|
||||
They will either grant you access or tell you which team to specify.
|
||||
|
||||
- Related project
|
||||
|
||||
Add one of the `related/*` labels if the issue relates to another project.
|
||||
|
||||
- Issue is lacking something
|
||||
|
||||
Add one of the the `needs-*` labels if you think the issue is incomplete
|
||||
somehow.
|
||||
|
||||
##### General process
|
||||
|
||||
We use
|
||||
[GitHub issue templates](https://github.com/kata-containers/.github/tree/master/.github/ISSUE_TEMPLATE)
|
||||
to help guide users to raising the correct type of issue. All these templates
|
||||
also automatically add a `needs-review` label to the issues.
|
||||
|
||||
The idea of this label is to highlight issues that have *not* yet been
|
||||
reviewed by the team.
|
||||
|
||||
Therefore, after you review an issue with this label, which potentially
|
||||
results in the application of additional labels, *remove* the `needs-review`
|
||||
label to signal that the issue has been reviewed.
|
||||
|
||||
### Test stability
|
||||
|
||||
The more PRs you look at, the more likely you are to notice patterns or
|
||||
anomalies of CI test failures.
|
||||
[Raising issues in the `tests` repository](https://github.com/kata-containers/tests/issues/new)
|
||||
helps us to identify "flaky" tests and prioritize the problematic bugs that
|
||||
make review/merges slower.
|
||||
|
||||
Use the following link to search all issues (open and closed) and look for the
|
||||
key failure message before you raise an issue. This allows you to see if the
|
||||
issue has been raised before:
|
||||
|
||||
- https://github.com/issues?utf8=%E2%9C%93&q=is%3Aissue+org%3Akata-containers+
|
||||
|
||||
Enter an error message in the search box and press enter.
|
||||
|
||||
If an issue has already been raised, add a comment on the PR to reference it.
|
||||
If it has not, raise a new issue and provide details of the failure. Add a PR
|
||||
comment to reference it.
|
||||
|
||||
### Weekly Summary
|
||||
|
||||
The Team should discuss amongst themselves and nominate someone to write a
|
||||
brief summary of what the team accomplished in the week. Post the summary to
|
||||
[the public mailing list](README.md#join-us).
|
||||
|
||||
Even if the week is quiet, a brief email is beneficial to show the community
|
||||
that we continue to progress PRs.
|
||||
|
||||
While there is no strict format for the weekly summary, it should mention
|
||||
significant PRs that have landed or been progressed. The summary does not need
|
||||
to be highly detailed or particularly long but it does help to include PR URLs
|
||||
to allow readers to find out further information.
|
||||
|
||||
The following link provides a template if you prefer to use one:
|
||||
|
||||
- https://github.com/kata-containers/community/blob/master/statusreports/REPORT_TEMPLATE.md
|
||||
|
||||
Other things to consider adding to the summary include:
|
||||
|
||||
- Were you particularly impressed with a piece of work (or team work)?
|
||||
- Did you face any particular problems?
|
||||
- Is there anything that can be done to make the process easier?
|
||||
|
||||
You can look at previous weekly reports on the mailing list for examples.
|
||||
Loading…
Reference in New Issue
Block a user