The Technical Committee meetings have become a barrier for some folks in the
community (TC and non-TC members) to participate in some discussions. Below is a
list with some positive and negative aspects of the current format:

Positive aspects of the current format:

A quorum of the TC is required to hold the meeting

The meeting agenda is a reasonable concise summary of what the TC is doing

The IRC logs of the meeting, read alongside Gerrit, are a reasonable
record of the debate

The meeting can be a quick way to reach out to members of the TC to discuss
how to move a particular proposal or idea forward.

The meeting is used to make time to resolve disagreements and build
consensus around the particular topics that need progressing.

The meeting provides a weekly rhythm that forces TC members to regularly pay
attention to TC initiatives, and therefore keeps efforts progressing.

It’s a known time when other parts of the community can show up and interact
with the TC

Negative aspects of the current format:

It takes place a specific time of day, even if we have rotating time slots,
we are always excluding someone.

The fast paced nature of the IRC meetings can exclude many for the
conversation. Many native English speakers struggle to keep track of the
conversation and get their point across. It is even worse for non-native
English speakers.

Feels like many conversations happen outside the meeting in non-open ways,
we should make it easy to have more open conversations.

All of this is fighting the goals laid out in the TC 2019 vision around
diversity of OpenStack leadership and in particular in the TC. We must
do better.

As we quickly evolve our process, we need to be mindful of the challenges
non-native English speakers and teams spread across the globe. Success is
when all in our community feel able to contribute to the best of their
ability within our community.

The weekly meeting gives us a good regular cadence to keep progress moving
forward. When we loose the regular meeting, we really need to keep this
cadence. This should not be merely be a summary of what has happened, but
rather should include a call to action and priority setting, much like the
existing meeting agenda that is sent 24 hours before the current meeting.

The TC chair will be responsible for sending a weekly status update to the
development mailing list, which includes:

Highlights of what the TC has got done over the last week

Gerrit patches and email threads that need attention over the coming week

List of reviews that have enough support to be merged. They will be merged
after a 48 hour period of waiting for any final objections. This can be
accelerated, as normal, using the existing house rules.

It is likely the above will be built in a collaborative way using tools such
as gerrit, wiki pages and etherpads that track the TC’s work.

When needing to discuss and debate what is currently the highest priority,
replying to the weekly checkpoint email can be a good starting point for
that debate.

The weekly meeting is a good time for non-TC members to interact with TC
members. However the timing is very poor for many members of the community.
We can replace this part of the weekly meeting with office hours.

Schedule a set of slots so there are current members of the TC present in the
#openstack-tc IRC channel and there is a good time for folks from any timezone
to drop in and ask questions.

Currently, the weekly meeting is used to debate topics that are currently
in review and possibly close to getting merged. Doing this in the meeting
makes it clear when something will be debated so people can join in that
debate, and the debate is clearly recorded in the meeting logs.

Using the current meeting format and agendas for debate artificially limits the
bandwidth to what can be agreed within one hour a week. Losing this restriction
should allow for much higher bandwidth, if we are successful.

While email and gerrit conversations provide a good asynchronous mechanism to
debate, sometimes it is more efficient to have a synchronous conversation to
build understanding and consensus on a particular topic. Therefore, In case of
standing disagreements on some topics, the TC chair can call for a meeting to
discuss that specific topic. The meeting would be chaired by the TC chair or any
other member of the TC (hopefully neutral on the topic).

Any synchronous conversation (be they ad-hoc or during office hours) should be
summarised on the relevant gerrit review, or if not available, the relevant ML
thread. If the debated happened on IRC, a link to the IRC logs must be included.
These ad-hoc conversations should happen in logged mediums that can be easily
referenced in the summaries that will be provided.

Every decision should happen on asynchronous means, following the voting
process, regardless of whether there was a synchronous discussion or not.

As things are debated in the current IRC meeting, we often go off track
and discover interesting things that need to be defined for us to make
progress. Such as what do we mean by “upstream support”, or what do we
mean by “deprecated”. With tags and resolutions we can build up this
common set of definitions, so we all start talking about the same thing.

This free flowing conversation should be continued even without the regular
weekly meetings. Adhoc IRC conversations are likely to lead to interesting
ideas that should be debated more formally in their own right.
We have succeeded if we continue to refine our shared language in a way
that makes it easier to join in the debates.