Hey Kubernetes Community,

tl;dr -- words are hard sometimes and we should take some time and care to assess the way we wield them.

Looking for feedback on https://github.com/kubernetes/community/issues/5344.

---

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:

• SIG Architecture
• SIG Release
• SIG Docs
  

With SIG ContribEx to assist with consistent delivery across our properties.

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

-- Stephen