From 64d0b93acdb8da9e5b7425b70f43307a81a6a7fd Mon Sep 17 00:00:00 2001 From: Samuel Ortiz Date: Tue, 9 Feb 2021 10:36:44 +0100 Subject: [PATCH] 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 --- AC-Meeting-Guidelines.md | 63 ++++++++++++++++++++++++++++++++++++++++ README.md | 9 +++++- 2 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 AC-Meeting-Guidelines.md diff --git a/AC-Meeting-Guidelines.md b/AC-Meeting-Guidelines.md new file mode 100644 index 0000000000..ce58df9f0b --- /dev/null +++ b/AC-Meeting-Guidelines.md @@ -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. diff --git a/README.md b/README.md index eba3182094..9009f8fb4e 100644 --- a/README.md +++ b/README.md @@ -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).