Refining the way we communicate deprecations/wide-reaching changes to the project

kubernetes / community

Kubernetes community content

Apache License 2.0

11.91k stars 5.16k forks source link

Refining the way we communicate deprecations/wide-reaching changes to the project #5344

Open justaugustus opened 3 years ago

justaugustus commented 3 years ago

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:

dockershim
the k8s.gcr.io migration
hyperkube

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:

@kubernetes/sig-architecture
@kubernetes/sig-release
@kubernetes/sig-docs-en-owners

With @kubernetes/sig-contributor-experience to assist with consistent delivery.

I'm curious to hear everyone's thoughts here.

cc: @kubernetes/steering-committee

k8s-triage-robot commented 2 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:

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

justaugustus commented 2 years ago

@jlbutler -- Have we had a chance to make improvements here?

/remove-lifecycle stale /lifecycle frozen

chris-short commented 2 years ago

@jlbutler Let me know how I can help here on behalf of Upstream Marketing.

jlbutler commented 2 years ago

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.

jlbutler commented 2 years ago

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?

jberkus commented 2 years ago

@jlbutler yeah, creating a "Create a web page with deprecations" issue makes sense. You wanna launch it?