Open shannonxtreme opened 9 months ago
@shannonxtreme: The label(s) sig/contribex
cannot be applied, because the repository doesn't have them.
/sig contributor-experience
/cc @IanColdwater @chris-short @mrbobbytables @kaslin
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen /remove-lifecycle stale cc @kubernetes/contributor-comms
Thinking of this as we're discussing cgroups v2
@BenTheElder: Reopened this issue.
I think this issue description is missing a big area that we need to be better about is a community of thrid party tools built on k8s. Many customers don't care about k8s internals, they depend on it by proxy via those 3rd party tools. Spreaading awareness in CNCF and beyond is a very important job we need to do when making disruptive changes
/remove-lifecycle rotten
@SergeyKanzhelev One thing we learned from the registry change comms effort is that many folks found out about it through their Kubernetes/cloud vendor. Building good links between K8s Comms and the cloud providers went a very long way. The fact this is listed towards the top is VERY good.
Taking your comment into consideration, how much further should we go? I want to have some kind of idea of scale here so the effort can be measured accurately.
@SergeyKanzhelev One thing we learned from the registry change comms effort is that many folks found out about it through their Kubernetes/cloud vendor. Building good links between K8s Comms and the cloud providers went a very long way. The fact this is listed towards the top is VERY good.
Taking your comment into consideration, how much further should we go? I want to have some kind of idea of scale here so the effort can be measured accurately.
To this point, how do third party tooling devs (not the cloud providers) keep up-to-date with what's going on in k8s? Is the expectation that they be on our dev mailing lists and in our Slack channel? At what point is the onus no longer on the project and more on the 3p developers to ensure that they're subscribed to our major channels (and how can we socialize those channels more?)
@SergeyKanzhelev One thing we learned from the registry change comms effort is that many folks found out about it through their Kubernetes/cloud vendor. Building good links between K8s Comms and the cloud providers went a very long way. The fact this is listed towards the top is VERY good.
Taking your comment into consideration, how much further should we go? I want to have some kind of idea of scale here so the effort can be measured accurately.
Yes, cloud vendors is the best and the most immediate and higher priority communication channel we need to ensure. Especially since many of them needs to be conformant: https://www.cncf.io/training/certification/software-conformance/ which assumes timely updates.
As for 3rd party vendors, I think a good story may be if we will have some comms channel for people building products that "work on k8s". Including monitoring vendors, security vendors, frameworks, etc. If for every deprecation we may contact 3rd party vendors and publish table with the name of a 3rd party product and a link to the product's page explaining how the deprecation affects or doesn't affect them - it will be great. Something that we can generate sceleton for and vendors can fill up with their links, would be great to have
BTW, same idea as in previous comment can be used for conformant products. For each deprecation we can ask every conformant vendor to provide a docs link and indication on their readiness for the deprecation.
This will be a very good use of a conformance program as I see it.
@kaslin and I will likely spend some time after the comms meeting next at least getting some bullet points together.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Describe the issue
In the past, we've needed to communicate upcoming disruptive changes to the project to end users. For example, deprecating dockershim or the registry changes. We lack a comprehensive process around communicating this type of disruptive/breaking change to our users. This issue proposes the creation of a comms plan, including performing an audience needs analysis, creating templates, and accounting for crisis situations.
The rest of this issue is up for discussion. I split it into phases to make it easier to track this effort in individual issues. If the scope is too large, we can work on it. I also am unsure who would own what part of the comms process.
Goals
Tasks
Phase 1: Gather information
(TODO: tracking issue)
This phase's methodology is up for discussion. What media do we use to get a survey to people?
TikTok)Phase 2: Identify cloud provider stakeholders
(TODO: tracking issue)
Communicating disruptive upstream changes should be a partnership with cloud providers, which'll increase our reach with every communication.
Consider making this process timeless by asking the stakeholders to set up aliases instead of relying on individuals.
Phase 3: Build a plan
(TODO: tracking issue)
Create a baseline communications plan. This plan needs to outline the following:
Phase 4: Templates and process docs
(TODO: tracking issue)
Process docs
Templates
Example flow
Consider an upcoming planned deprecation of PodSecurityAdmission. sig-security creates an issue with the comms folks with the following info:
Comms + the SIG: