Open justaugustus opened 3 years ago
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@jlbutler -- Have we had a chance to make improvements here?
/remove-lifecycle stale /lifecycle frozen
@jlbutler Let me know how I can help here on behalf of Upstream Marketing.
Hi all. Sorry, for the latency.
Based on the discussion here, I've added tasks revolving around facilitating an optional "Deprecations and Removals" blog per cycle to the Comms handbook (PR is here if you're reading this and it's still not merged).
We may want to consider something in docs as the above discussion suggests, but at least we've got something in place for every release cycle going forward, rather than ad hoc.
Bumping this discussion as relates to other things brought up on the thread beyond the release comms team scope (a dedicated web asset for deprecations and removal, and the higher-level migration support and persona definitions). Do folks want to open these as additional issues, or continue discussion here?
@jlbutler yeah, creating a "Create a web page with deprecations" issue makes sense. You wanna launch it?
As we go through deprecations and infrastructure changes in the project, it might be a worthwhile exercise to assess and refine the way we communicate them.
I can think of a few recent examples that caused some panic and required additional lift from contributors to reframe or contort/extend support to accommodate:
We should consider what it means to turn down a service, piece of functionality, or kubernetes/kubernetes-adjacent system and type of impact it may have for consumers.
Without policing contributors, as maintainers of the project, we also have a responsibility to users to be careful and deliberate with our communications outside of the project, whether it be Twitter, Hacker News, etc., etc.
So how can we improve?
I think depending on the scope of a change, the following SIGs should be involved in crafting comms:
With @kubernetes/sig-contributor-experience to assist with consistent delivery.
I'm curious to hear everyone's thoughts here.
cc: @kubernetes/steering-committee