Rethinking the Monthly Community Meeting

[nimbinatus]

Contributor Experience has been discussing the "why" of the community meeting and looking into how to make the meeting more useful for the community. To summarize the discussions:

• The current format of the community meeting doesn't provide an opportunity for much discussion, which reduces engagement.
• The community meeting is a place for new members to get a sense of what's going on with the community and for current members to get a snapshot of current events.
• By joining all of the independent SIG update sessions to one meeting, the community meeting reduced the load on attendees, especially new members, to find and attend every SIG they might find interesting (and reduced the sheer volume of meetings).
• There's also a concern around the Google Groups being used to maintain the calendar invite.

We're considering a different format that keeps the same vibe, such as a podcast or pre-recorded updates with clear channels identified for discussion. Would that be more useful? Would that answer the "why" of the meeting while reducing the load on SIGs?

This issue is a spot for further discussion.

/sig contributor-experience

cc @mrbobbytables @alisondy

[nimbinatus]

After some further discussion with @parispittman, here are the thoughts around SIG reporting:

• We'd like to increase async comms and reduce meetings for the SIGs.
• There's already a lot of reporting (e.g., see https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md), and the community meeting overlaps much of that reporting already.

Some options that came up include Slack "open house days" on SIG channels to go with the reporting they already do and Slack-based community meetings.

[mrbobbytables]

Some notes from last week's contribex meeting where we talked about it too:

• SIGs schedule their own public sessions, getting updates from SIGs independently
  • It was dropped as it’d be difficult for attendees
• Openstack approaches community meetings by letting folks record video updates, We could approach folks to record video updates every quarter and then compile them together
• Considering the “why” of the meeting
  • A front door for new members (or campfire aspect of news)
  • A ‘what’s new for current members’
  • Would we be able to keep the same vibe with a different medium
    • Maybe podcast, maybe youtube
• Issue with the community meeting was there was no discussion

[nimbinatus]

Update: We're going to reboot with a discussion-based format. The community has a spot to add topics to discuss with a Google sheet (sent to the k-dev mailing list on 19 March 2021 at 12:00p Central Standard Time).

Tasks to finish before first reboot:

• Update the hosting guide
• Add an event to the community calendar
• Pick a few community-suggested topics
• Reach out to various folks to help drive day-of conversations

[nimbinatus]

/assign @nimbinatus

[nimbinatus]

cc: @MadhavJivrajani since you offered to help with this on the tracking sheet (Thank you!!!)

[MadhavJivrajani]

Hi! Thanks @nimbinatus!

I personally have not attended a community meeting having been part of the community for only a few months, but I just watched one of the community meets and looked over the current format, and I especially love the point that says "Contributor Tip of the Week", I think if its possible, we should try and include that in every community meeting, for example, for me personally, one of the most helpful tips was using cs.k8s.io and I use it religiously for almost every contribution I make!

We're considering a different format that keeps the same vibe, such as a podcast or pre-recorded updates with clear channels identified for discussion.

• I think that this is a great idea, especially because if someone were to miss the meeting or had to drop off mid way, if individual recordings/pod-casts were present, it might be more flexible for that person to get the required update from the respective recording rather than having to search through the recorded meet for that particular section and this would also solidify the "why" of having that particular meeting since there's a number of fine-grained, disjoint entities from which you can get your information.
• As per the idea of having clear channels identified for discussions, afaik there doesn't exist a community-meetup channel on slack, I apologize if I've overlooked it. I love the fact that MoC has a dedicated channel on slack where questions can be asked during the meeting, and I also loved the concept of async meetings that happen on the sig-contribex channel. My suggestion would be to create such a dedicated channel and have threads per participating SIG, per community meeting for discussions to take place if any!

The community meeting is a place for new members to get a sense of what's going on with the community

As a relatively new member myself, and thinking of what I would like from such a meeting, a few suggestions that I had in mind are:

• Before every SIG starts with their update, it would really help if the person giving the update could spend a minute giving maybe a one line description of what their SIG is responsible for and where information for that sig can be found, that could maybe be included in the slide template? So maybe something like: "you can find more info about our SIG at git.k8s.io/community/sig-name".
  • Not only would this introduce them to the existence of the k/community repo, but also since the weekly SIG meeting and mailing lists are the first thing that the README of that SIG discusses, it might give more insight to the person in terms of where help can be seeked for that particular SIG.
• It could help if at the end of the slides, the agenda doc for the current release cycle is linked (if its available by then). If an agenda doc isn't really available at the time of the meet, then if its possible and if KEPs being worked on are mentioned in the presentation, these KEPs could be linked.

Please let me know if I've misunderstood anything and/or I've overlooked some of the decisions that have already been made 😄

[nimbinatus]

Hi! These are great points that I think we could incorporate overall. Let me see if I can touch on a few points:

• Overall, the issues we're trying to solve are as follows:
  • We want to build more two-way connections across the community rather than the meeting becoming another readout.
  • We want to reduce workloads so people have more time to engage with one another versus providing reports.
  • We want to ensure new contributors (and current ones!) have somewhere to get information.
• One of the thoughts with reworking the community meeting was that SIGs were providing a bunch of duplicated updates. The thought was to have the SIGs provide the annual reports to the steering committee and save the community meeting as more of a discussion forum. So we dropped the individual SIG updates. As a new contributor, though, do you think the loss of insight into the SIGs in a quickly consumable video format means it's going to be harder to find your way?
• As noted in Mega/Process KEP changes & the Community Meeting #5730, I think KEPs are going to be heavily involved in the meeting going forward. Personally, I think understanding and discussing the KEPs is a great way to get a pulse on the ecosystem, but what are your thoughts as a new contributor?
• I really like the async Slack channel for questions. The hope is people will join the Zoom and ask themselves, but I know that it's kinda scary putting yourself out there if you're new. A Slack channel does lower that barrier. I don't think it will happen for April, but let's talk about it for May.

[mrbobbytables]

As per the idea of having clear channels identified for discussions, afaik there doesn't exist a community-meetup channel on slack, I apologize if I've overlooked it. I love the fact that MoC has a dedicated channel on slack where questions can be asked during the meeting, and I also loved the concept of async meetings that happen on the sig-contribex channel. My suggestion would be to create such a dedicated channel and have threads per participating SIG, per community meeting for discussions to take place if any!

Just an FYI - That is largely what the #kubernetes-contributors channel is for. 👍

[MadhavJivrajani]

Thank you for elaborating @nimbinatus!

As a new contributor, though, do you think the loss of insight into the SIGs in a quickly consumable video format means it's going to be harder to find your way?

Oh on the contrary, so I am a new contributor not only in terms of being new to the community but also in terms of being new to the k8s ecosystem as a whole. In my opinion, having a separate consumable video format would be great since now I would have all of the SIG updates in one place and I wouldn't have to search for it in a relatively longer meeting video. And more importantly, if its independent videos, in each video, a link to that SIG's info on the k/community repo can be added in the description along with each of the related KEPs that were mentioned in the update and it might make it easier to discover/navigate contents of that update this way. Another plus point is that its easier to maintain a lineage of per-sig update videos if done in this format by simply linking the previous update video in the current one and that way there's a continuity of context that can be provided, and of course those previously linked updates would also have the relevant KEPs linked and so on.

As noted in #5730, I think KEPs are going to be heavily involved in the meeting going forward. Personally, I think understanding and discussing the KEPs is a great way to get a pulse on the ecosystem, but what are your thoughts as a new contributor?

I strongly believe that emphasis on KEPs should be increased because before I "officially" joined the community, I used to browse the org and wonder "hmm okay so there are these things called SIGs, but what are they working on and is there anything for my level of expertise?" and I had no idea that the k8s contributor and dev guides existed, after I became a part of the slack channels and started interacting with people, one of the first people I spoke to was dims and he pointed me in the direction of the k/enhancements repo and the concept of KEPs, and since then KEPs have been my goto for anything related to what a SIG is planning to do or if I need more details on a feature that is already part of the code base, I try and search for that KEP and its a perfect source of information! If emphasis on KEPs and their discussions can be done earlier on, I think that would really really help!

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mrbobbytables]

/remove-lifecycle stale
/lifecycle frozen

[parispittman]

/close

I think we are ok here, especially with the docs being updated. thanks for your work Laura! re-open if there are more items to discuss

[k8s-ci-robot]

@parispittman: Closing this issue.

In response to this:

/close

I think we are ok here, especially with the docs being updated. thanks for your work Laura! re-open if there are more items to discuss

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.