Consider Extending Length of Community Meeting

[danehans]

During the January 7, 2024 community meeting, I suggested extending the length of the community meeting. In recent meetings, the current meeting length (30 minutes) has not provided enough time to cover all topics or the meeting ran over time. Also, we discussed including CFP reviews in the weekly meeting agenda which places additional constraints on the meeting time. Please refer to this Slack thread for additional background on this issue.

[danehans]

Per @joestringer's request, the following are my thoughts on what makes for a useful synchronous discussion:

Clear Agenda and Objectives

• Predefined Topics: Having a clear, predefined agenda shared before the meeting helps participants prepare and ensures that the discussion stays focused. This can include items like Cilium Feature Proposals (CFP), bug triage, release planning, etc.
• Specific Objectives: Each agenda item should have a clear objective. Are you seeking feedback, making a decision, or simply sharing information? Knowing this in advance helps structure the discussion more effectively.

Inclusive Participation

• Encourage Participation: Ensure that everyone has a chance to speak. This might mean actively inviting input from quieter members or using round-robin techniques to share ideas.
• Diverse Perspectives: Cilium benefits from contributors located across the globe and from different affiliations. Be mindful of time zones and strive to schedule meetings at times that are as inclusive as possible.

Effective Moderation

• Time Management: A skilled moderator can keep the discussion on track, manage time effectively to cover all agenda items, and ensure that discussions remain respectful and productive.
• Actionable Outcomes: Ensure that decisions and action items are clearly identified, assigned, and summarized at the end of the meeting. This helps translate discussion into concrete progress, e.g. GitHub issues.

Use of Collaborative Tools

• Shared Documents: Utilize shared documents or collaborative editing tools for real-time note-taking, allowing participants to contribute, comment, and follow along.
• Voting or Polling: For decision-making, tools that facilitate voting or polling can help gauge consensus or make choices more efficiently. https://gitvote.dev/ is a tool that helps with voting and is available from the CNCF.

Asynchronous Follow-up

• Meeting Notes: Publish detailed meeting notes afterward to keep the wider community informed, including those who couldn’t attend. This also serves as a record of decisions made and action items assigned.
• Continued Discussion: Encourage continued discussion on appropriate channels (e.g. Slack) for topics that need further debate or were not covered due to time constraints.
• Record Meeting: A meeting recording allows contributors asynchronous attendance when synchronous discussion is not possible. This also provides a more detailed record of the meeting that complements meeting notes.

Regular Review

• Feedback on Meetings: Periodically solicit feedback on the meetings themselves to understand what's working and what can be improved. This can help refine the process and ensure meetings remain valuable for the community.

Building Community

• Informal Interaction: Allow time for informal interaction. Starting meetings with a brief check-in or ending with an open floor can foster community bonds and provide space for open discussions that might not fit into a formal agenda.

In my opinion, the current Cilium community meetings accomplish much of what is outlined above. I appreciate the efforts of @joestringer and other committers for making the meetings a valuable resource to the Cilium community.

[xmulligan]

Another idea could be to consider splitting out different parts of the meeting into separate ones. For example, release and testing could be their own meeting. I know no one wants more meetings and it is difficult to find a time that works for everyone, but we also might want to look at if all parts of the meeting are relevant to everyone on it.

[joestringer]

Thanks very much for your detailed thoughts on properties of successful community meetings @danehans . I think it's also important to think about:

• What is the role of synchronous meetings vs. asynchronous discussion and where is the threshold for those discussions?
• What format do we need for synchronous meetings? Audio/video calls can be more taxing on participants' attention than simply assembling at a time in a particular Slack channel.
• How do we provide equal opportunity for access to synchronous discussion for community members regardless of their location/timezone?
• How do we balance the needs of a variety of community members, from new contributors to experienced committers?
• How do we balance the interests of participants so that we are respectful of the time that they are volunteering to engage in the project?
• How do we develop the leadership skills in the community around moderation or otherwise facilitating discussions around particular topics?

I think that at this point the Cilium developer community has grown to a point where a single core community meeting is not really a viable mechanism for everyone to make progress. We frequently have 30+ members joining the session, and it is quite difficult to make a real dent in any technical topic in less than about 10 minutes. Even if only a third of the regular attendees brought a single topic, that can easily extend to an hour and a half. Furthermore, a format with so many attendees makes it difficult to have more than a few members chime in on a topic. Then there's the aspect that not all topics will be relevant to all attendees. Though that said, there is something valuable to providing exposure to unfamiliar subjects for attendees as a way to learn.

As for the role of synchronous voice calls in a community, there are certainly times where it can be quicker or more efficient to convey concepts verbally. This can be useful to get some high level alignment. At the same time, the format has another couple of properties: You tend to get the initial impressions from people, but there can be major gaps in feedback that are missed because either attendees are unable to express these ideas synchronously, or because the topic requires deeper thought & consideration before identifying key impacts of a topic. Furthermore, such calls force a bookending of a discussion topic and it is often difficult to jump into a discussion afterwards if a concern was missed. The live nature and competing voices can make it easier to gloss over important aspects of a problem space, and it is difficult to recreate the line of reasoning leading up to that aspect for deeper discussion after the fact.

To speak to a few aspects raised above and how I'm thinking about them:

Voting or Polling: For decision-making, tools that facilitate voting or polling can help gauge consensus or make choices more efficiently. https://gitvote.dev/ is a tool that helps with voting and is available from the CNCF.

In general in Cilium we try to operate by rough consensus, somewhat analogous to the IETF approach. We are typically averse to direct votes or polls as a way to come to a technical decision; having a simple majority vote does not sufficiently account for the concerns of the group.

Record Meeting: A meeting recording allows contributors asynchronous attendance when synchronous discussion is not possible. This also provides a more detailed record of the meeting that complements meeting notes.

For the record we've had ticket CNCFSD-2126 open with the CNCF since January 17 to establish new Zoom links with recordings. We hope to put this in place soon.

Feedback on Meetings: Periodically solicit feedback on the meetings themselves to understand what's working and what can be improved. This can help refine the process and ensure meetings remain valuable for the community.

I'd like to get more feedback on this in general, but I don't really know how. I feel like if I ask this question in the meeting, there will be little to no response. Generally I don't think that most developers really know or understand how to express feedback on meetings; most developers I know just do not like meetings at all. I also worry a bit that the meeting has become big enough that there is a bystander effect where over half of the attendees are there only to listen, and no-one feels empowered to express their opinions on what makes meetings effective or useful for them. So we continue with the current format for lack of a clear path to an alternative.

Informal Interaction: Allow time for informal interaction. Starting meetings with a brief check-in or ending with an open floor can foster community bonds and provide space for open discussions that might not fit into a formal agenda.

I empathize with the need for this. We do try this to an extent with the "joke of the week", though I find it a bit borderline as to whether this format is achieving this goal or whether it has jumped the shark. That said, I'm not sure that a community meeting with dozens of people is the format for this. It is exceedingly difficult to help people build 1:1 bonds in a session with so many people. I know that in-person summits or conferences can be very useful in this regard, though limiting for some community members who are unable to attend. I would like to encourage community members to engage with one another in Slack channels to help build bonds---this seems like the location that best suits this form of interaction.

Overall I'm not against extending the Wednesday community meeting slot, but I also wonder whether we actually need more process and leaders around special interests with more focused discussion topics rather than assuming that a single big long community meeting can solve all problems for all contributors.

We could also look at the current format and consider which of those elements really need standing discussion topics. For instance, for releases and testing we have structure in the community meeting to provide an open forum for people to raise concerns in those areas -- for instance if there's a bug that they think is major and could impact a release, or if the CI is blocking development, how can we identify issues, get volunteers to investigate/fix, or generally align expectations and concerns? We currently have 10 minutes reserved for these topics, but if we moved them async via Slack then we would already free up a third of the meeting time for agenda items. Overall my point is that it is tempting to always assume that we need to give something more time, but one way to get more time is to make more efficient use of the time that we have. Half an hour is a decent amount of time for getting a few dozen people on the same page. It's not long enough to do a deep review of a CFP, and I don't think that should be a part of the regular community meeting; if that's the need then let's set up either one-off sessions for that, or dedicated topic-based discussions on a regular basis.

[joestringer]

I wanted to note down a couple of efforts we've established, integrating feedback from this discussion. As per the latest community docs, there are new regular SIG meetings to provide space to dig into more depth on specific topics:

• #sig-policy meets on the first Tuesday of each month (notes)
• #sig-scalability meets on the fourth Thursday of each month (notes)

To join or suggest a new SIG, see the links and instructions on this page: https://docs.cilium.io/en/latest/community/community.