Contributor Communication

This document explains how to communicate and collaborate within the Agent Client Protocol (ACP) project.

​

Communication Channels

In short:

• Zulip: For real-time or ad-hoc discussions.
• RFDs: For proposed changes to the specification.
• GitHub Discussions: For structured, longer-form discussions.
• GitHub Issues: For actionable tasks, bug reports, and feature requests.

All communication is governed by our Code of Conduct. We expect all participants to maintain respectful, professional, and inclusive interactions across all channels.

​

Zulip

For real-time contributor discussion and collaboration. The server is designed around ACP contributors and is not intended to be a place for general ACP support. The Zulip server will have both public and private channels. Join the Zulip here.

​

Public Channels (Default)

• Purpose: Open community engagement, collaborative development, and transparent project coordination.
• Primary use cases:
  • Public SDK and tooling development
  • Community onboarding and contribution guidance.
  • Community feedback and collaborative brainstorming.
• Avoid:
  • ACP user support: participants are expected to read official documentation and start new GitHub Discussions for questions or support.
  • Service or product marketing: interactions on this Zulip are expected to be vendor-neutral and not used for brand-building or sales. Mentions of brands or products are discouraged outside of being used as examples or responses to conversations that start off focused on the specification.

​

Private channels (Exceptions)

• Purpose: Confidential coordination and sensitive matters that cannot be discussed publicly. Access will be restricted to designated maintainers.
• Strict criteria for private use:
  • Security incidents (CVEs, protocol vulnerabilities).
  • People matters (maintainer-related discussions, code of conduct policies).
  • Select channels will be configured to be read-only. This can be good for example for maintainer decision making.
  • Coordination requiring immediate or otherwise focused response with a limited audience.
• Transparency:
  • All technical and governance decisions affecting the community must be documented in RFDs, GitHub Discussions and/or Issues.
  • Some matters related to individual contributors may remain private when appropriate (e.g., personal circumstances, disciplinary actions, or other sensitive individual matters).
  • Private channels are to be used as temporary “incident rooms,” not for routine development.

Any significant discussion on Zulip leads to a potential decision or proposal must be moved to an RFD, GitHub Discussion, or GitHub Issue to create a persistent, searchable record. Proposals will then be promoted to full-fledged PRs with associated work items as needed.

​

RFDs

Please refer to the RFD process for how this is managed. This is the primary way to actually create changes to the protocol. Conversation about a given RFD can take place within the relevant PRs created to move the RFD forward. Or, a discussion within Zulip can be created in the rfds channel to discuss in real-time with other contributors.

​

GitHub Discussions

For structured, long-form discussion and debate on project direction, features, improvements, and community topics. When to use:

• Announcements and release communications
• Community polls and consensus-building processes
• Feature requests with context and rationale
  • If a particular repository does not have GitHub Discussions enabled, feel free to open a GitHub Issue instead.

​

GitHub Issues

For bug reports, feature tracking, and actionable development tasks. When to use:

• Bug reports with reproducible steps
• Documentation improvements with specific scope
• CI/CD problems and infrastructure issues
• Release tasks and milestone tracking

​

Security Issues

Do not post security issues publicly. Instead:

1. Contact lead and/or core maintainers, or hi@zed.dev directly.
2. Follow responsible disclosure guidelines.