governance/resolutions/superseded/20170425-drop-tc-weekly-meetings.rst

2017-04-25 Replace Technical Committee meetings

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.

Global Sensitivity

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.

Keeping a rhythm

The weekly meeting gives us a good regular cadence to keep progress moving forward. When we lose 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.

Office hours

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.

Debating

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.

Shared Language

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.