README: Define guidelines for adding topics to the AC meetings agenda

The goal here is to avoid spending time on discussions that could be
much more efficiently and inclusively discussed through github issues or
on the mailing list.

Fixes: #196

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This commit is contained in:
Samuel Ortiz 2021-02-09 10:36:44 +01:00
parent 0b177f61fa
commit 64d0b93acd
2 changed files with 71 additions and 1 deletions

63
AC-Meeting-Guidelines.md Normal file
View File

@ -0,0 +1,63 @@
**Important:**
Do **not** follow this process if you think you have discovered a vulnerability.
Instead, please use the [VMT](https://github.com/kata-containers/community/blob/master/VMT/VMT.md)
process.
# Architecture Committee Meeting Guidelines
The Architecture Committee (AC) recommends following a set of guidelines for
raising issues and adding topics to the meeting agenda.
## Use a GitHub issue first
For a project like Kata Containers, with contributors spanning across so many
different time zones, asynchronous discussions and reviews are the preferred
communication media.
Directly starting a proposal or trying to resolve new technical issues through
the AC meeting has many drawbacks:
* It potentially leaves a large part of the community out of the initial
dicussion.
* It does not give the AC meeting audience enough time to think through
the proposal and give constructive and well thought feedback.
* It makes it hard to track and share the discussion outcome.
As a consequence, the AC recommends using [GitHub issues](https://github.com/kata-containers/kata-containers/issues)
at first before adding new items to the AC meetings agenda, especially
if you think the topic could be discussed and resolved in less than two weeks.
## AC Agenda topics must be supported by a GitHub issue or a PR
Except for a few cases listed in the next section, any topic brought to the AC
meeting must be linked to a GitHub issue or a PR that should contain a
`cc @kata-containers/architecture-committee` in order to notify AC members of
the creation of a new AC meeting proposal.
Unless the topic must be urgently discussed, the AC recommends waiting for one
or two weeks before bringing the discussion to the AC meeting. That will give
enough time for interested contributors to digest the issue or proposal before
having a live discussion in the AC meeting.
### Exceptions
* Announcements
* Presentations
* Call for reviews of articles, blog posts, etc.
## AC agenda topics should have well defined expectations
When adding a topic to the agenda, one should have clearly defined expectations:
**"What do I want to get from the community and the AC with that discussion?"**.
For instance:
* Are you looking for a possible **solution** to a problem exposed through
GitHub or the mailing list?
* Are you looking for a **resolution** of a conflict in a pull request?
* Are you looking for a [**"go-nogo"**](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#submit-issues-before-prs)
from the community in order to start working on something?
* Are you looking for technical **feedback and guidelines** on a pending
technical proposal?
Answering those questions and clearly stating the expectations upfront will
help with steering the AC meeting discussions in the right direction.

View File

@ -12,6 +12,7 @@
* [Contributor](#contributor)
* [Maintainer](#maintainer)
* [Architecture Committee](#architecture-committee)
* [Architecture Committee Meetings](#architecture-committee-meetings)
* [Vendoring code](#vendoring-code)
* [Vulnerability Handling](#vulnerability-handling)
* [Reporting Vulnerabilities](#reporting-vulnerabilities)
@ -92,12 +93,18 @@ The current Architecture Committee members are:
- `Xu Wang` ([`gnawux`](https://github.com/gnawux)), [Ant Financial](https://www.antfin.com/index.htm?locale=en_US).
- `Fabiano Fidêncio` ([`fidencio`](https://github.com/fidencio)), [Red Hat](http://www.redhat.com).
Architecture Committee elections take place in September (3 seats available) and February (2 seats available). Anyone who has made contributions to the project will be eligible to run, and anyone who has had code merged into the Kata Containers project in the 12 months (a Contributor) before the election will be eligible to vote. There are no term limits, but in order to encourage diversity, no more than 2 of the 5 seats can be filled by any one organization. The Architecture Committee will meet regularly in an open forum with times and locations published in community channels.
Architecture Committee elections take place in September (3 seats available) and February (2 seats available). Anyone who has made contributions to the project will be eligible to run, and anyone who has had code merged into the Kata Containers project in the 12 months (a Contributor) before the election will be eligible to vote. There are no term limits, but in order to encourage diversity, no more than 2 of the 5 seats can be filled by any one organization.
The exact size and model for the Architecture Committee may evolve over time based on the needs and growth of the project, but the governing body will always be committed to openness, diversity and the principle that technical decisions are made by technical contributors.
See [the elections documentation](elections) for further details.
### Architecture Committee Meetings
The Architecture Committee meets every Tuesdays at 7:00am PST. Agenda & call info can be found [here](https://etherpad.opendev.org/p/Kata_Containers_2021_Architecture_Committee_Mtgs)
In order to efficiently organize the Architecture Committee (AC) meetings, maximize the benefits for the community, and be as inclusive as possible, the AC recommends following a set of [guidelines](AC-Meeting-Guidelines.md) for raising topics during the weekly meetings.
# Vendoring code
See the [vendoring documentation](VENDORING.md).