Analysis of Gaps in Community Channels

[nimbinatus]

Split from #7051

In general, we're removing the monthly community meeting (see #7051 for details on rationale). There needs to be a discussion on whether we're meeting the needs of the community in terms of getting news out, introducing new contributors to various SIGs, helping current contributors find new projects, and more. This issue is open for discussion on this topic.

The end result may be a single thing, multiple things, or nothing needed.

Currently, community-wide discussions are happening in the following places:

• Public Steering Committee meetings
• SIG-Leads monthly sync
• Written Annual Reports

All discussion on this issue welcome.

cc @mrbobbytables @jberkus

ref: #6544, #7068

/assign @nimbinatus
/sig contributor-experience

[craiglpeters]

As we move to a self-paced course for new contributors, there needs to be some complementary way to interact with others going through the course, and get help from more experienced contributors. A slack channel + a monthly series of office hours (with instances in multiple time zones) has been proposed

[pnbrown]

I think that's a great idea. 👍🏿

[jberkus]

The other big area that's been missing has been making SIG contributors aware of what other SIGs are doing -- that is, project-wide awareness of major technical initiatives, even if those are handled by a single SIG. The annual reports put these on paper, but I have no illusions about how well-read those are. Maintainer sessions at Kubecon also help, but are subject to conflicts.

My thought here would be doing one "SIG X Office Hour" per year for each SIG, where they would have an online session where they'd talk about what they're doing that year and also be open to new contributor questions. Prep could be minimal for the SIG leads, since they could re-use material prepared for the annual report and Kubecons.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.