Drop Technical Committee meetings
So, this is an idea I've been poking around for a bit. TBH, I ran this idea through some folks last year but it didn't seem to be the right moment for it. During the last elections, Matt asked[0] a question about inclusiveness in the TC, which resulted in myself[1] and ttx[2] proposing this idea. [0] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115227.html [1] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115255.html [2] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115313.html Now, down to business. From a practical perspective, most of the discussions we have at a TC level happen (or should happen) on gerrit and the mailing list. Lately, most of our meetings have been mostly useful to rubber stamp things that we've voted on already on gerrit. This is not to say that meetings are useless and that we don't have any interesting discussions during these meetings. We do, in fact, have some more heated discussions during our meetings from time to time but they are not as freequent as they used to be. So, instead of having a blocked hour, every week, for the TC meeting, I'd like to propose we drop the meetings entirely and, instead, encourage discussion in #openstack-dev. Here's are some things I think this would give us: - Possibility for arranging more focused discussions with stackholders on hours that work best. The smaller the group, the easier it is to pick a time. - More open and transparent discussions as it'll force everyone to discuss things using gerrit and the mailing list instead of waiting for meetings to happen. - It'll be easier for folks to stay up-to-date with the on-going discussions as we'll be reducing one channel of communication and focus on the other 2 we're already using. - It'll be easier for folks (especially non-native English speakers) to participate in the discussions as it'll allow them to take their time to do it. Co-Authored: John Garbutt <john.garbutt@rackspace.com> Change-Id: If70bb95da3216aad7632983f1955d06de1c50521
This commit is contained in:
parent
68f8866f00
commit
1f1ddcfded
|
@ -0,0 +1,124 @@
|
|||
===============================================
|
||||
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 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.
|
||||
|
||||
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. Loosing 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.
|
Loading…
Reference in New Issue