[Umbrella issue] Investigate and create a communications plan for disruptive changes #7613
Description
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
- Reach the maximum number of end users with comms about disruptive changes, especially those without a direct line to the k8s community
- Understand the effort and lead time required by the majority of end users to migrate from the deprecated capability
- Create consistent, unified comms and documentation, at predictable times, for every new change to the project
Tasks
Phase 1: Gather information
(TODO: tracking issue)
- Survey our end-users to understand their needs
- How do they stay on top of project changes?
- Where would they ideally find these changes?
- How long do they need to prepare their environments for disruptive changes? (how long did it take for recent ones?)
- What type of guidance do they need from us? (how much hand-holding, how much context, what type of docs)
This phase's methodology is up for discussion. What media do we use to get a survey to people?
- Social media (Twitter, LinkedIn(?), Reddit, Mastodon,
TikTok) - Banner on kubernetes.io
- Where else?
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.
- Identify internal stakeholders at various cloud provider organizations
- Ensure that cloud provider stakeholders know how their org's comms process works (release notes/social media/blog posts)
- Include interested stakeholders in comms planning for disruptive changes
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:
- Stakeholders (project and cloud provider)
- Includes owners for deliverables
- Timeline and milestones. Includes but not limited to:
- When to create the initial tracking issue
- Minimum time period before full removal
- When to deliver specific deliverables
- Modes of communication based on survey results
- Core deliverables based on survey results. For example:
- Migration guide (P1)
- "Hub" page about the change that includes context, links, etc (P1)
- Blog posts (P2)
- Release notes announcement (P1)
- Comms schedule (P2)
- Crisis comms plan:
- Minimum viable content for a crisis situation
- Minimum stakeholders to resolve the immediate issue
- Highest engagement platforms to send out communications
- Creation of tracking issue to feed into the full comms process
Phase 4: Templates and process docs
(TODO: tracking issue)
Process docs
- SIGs: How to engage the comms subproject(?)
- Comms team:
- When to use crisis plan vs normal comms
- How to use the comms plan
- How to engage stakeholders (setting up meetings, etc)
Templates
- Template for initial tracking issue
- Template for migration guide and "hub" page
- Template for comms schedule (spreadsheet with posts and frequency)
- Template for release notes announcements
Example flow
Consider an upcoming planned deprecation of PodSecurityAdmission. sig-security creates an issue with the comms folks with the following info:
- What's happening and why
- Alternatives
- Expected timeline
Comms + the SIG:
- Fill out the comms plan with all the info in the template
- Create a tracking issue for the change and attach the comms plan
- Set up recurring meetings at a set cadence with stakeholders
- Draft the P1 deliverables (migration guide, hub page, comms schedule)
- Create issues or PRs with sig-docs to update docs, engage cloud provider stakeholders, etc
- Announce the change with release notes and identified social media. All announcements link to hub page.
- Use the comms schedule to plan reminders and P2 deliverables (FAQs, blog posts)
- After the minimum allowed time (eg: 1 year) has passed, finalize the change.