Coordination and Maintenance

When a change affects multiple SDKs, follow this sequence:

1. Proposal — RFC or issue describing the change
2. Cross-SDK review — at least 1 week for feedback
3. Sequencing decision — agree on rollout order
4. Tracking — set up as a Linear initiative
5. Communication — coordinate announcements

See Aligning Cross-SDK Changes for the step-by-step playbook and Managing Linear Projects for running per-SDK projects.

All user-reported issues MUST get a substantive first response within 2 business days. "Substantive" means acknowledging the problem, asking for reproduction steps, confirming it as a known issue, or explaining the resolution — not just a thumbs-up emoji.

Issues on GitHub and Linear are automatically labeled to track where action is needed:

• Waiting for: Product Owner — the maintainer MUST respond within 2 business days. The SLA restarts each time this label becomes active.
• Waiting for: Community — the maintainer has responded and is waiting for a reply or reproduction from the reporter. No SLA while this label is active.

Labels are managed automatically and reset on state transitions. Both are removed when the issue is closed.

See the Triaging playbook for the full workflow.

Supported versions should be documented in the README and docs. Dropping support for a platform or language version is a breaking change — it follows the breaking change and deprecation process and needs evidence: usage data, upstream EOL status, or maintenance burden. Announce it at least one minor release before the major that drops support.

Each SDK owns its version matrix. CI should test all supported versions.

Monitoring

After each release, watch for problems:

• Monitor SDK crash detection
• Verify dogfooding picks up the new version
• Watch the issue tracker for 48 hours
• Patch critical regressions within 48 hours

Handling regressions

Every SDK MUST have a documented regression handling plan covering:

• How to yank or unpublish a release
• How to cut a revert release
• Who has permissions — at least two people per SDK must be able to publish and yank
• A communication template for notifying users

An annual regression handling drill is recommended. See Setting up release infrastructure for initial setup.

Decisions should be traceable. Before making one, reference or create a Linear or GitHub issue to anchor the discussion. If a meeting happens, enable notes or recording — key decisions MUST be summarized and linked to the issue afterward.

Slack is fine for coordination, but outcomes MUST be moved to the system of record (Linear, GitHub, or Develop Docs) before the thread is considered closed. Update the issue immediately, link supporting docs, and assign action items with owners.