Add zulip server link to the website (#236)

Author: benbrandt

CONTRIBUTING.md

@@ -11,7 +11,7 @@ We welcome many different types of contributions including:
 - Bug fixes
 - Documentation
 - Issue Triage
-- Answering questions on Slack/Mailing List
+- Answering questions on Zulip/Mailing List
 - Web design
 - Communications / Social Media / Blog Posts
 - Release management
@@ -62,7 +62,7 @@ Before a significant change or addition to the protocol is made, you should like
 If you’re unsure about anything, feel free to reach out! The best way to reach us with a question when contributing is to ask on:
 
 - The original GitHub issue or discussion thread
-- Slack
+- [Zulip](https://agentclientprotocol.zulipchat.com/)
 
 ## Code of Conduct
 

docs/community/communication.mdx

@@ -0,0 +1,86 @@
+---
+title: "Contributor Communication"
+description: "Communication methods for Agent Client Protocol contributors"
+---
+
+This document explains how to communicate and collaborate within the Agent Client Protocol (ACP) project.
+
+## Communication Channels
+
+In short:
+
+- **[Zulip](https://agentclientprotocol.zulipchat.com/)**: For real-time or ad-hoc discussions.
+- **[RFDs](https://agentclientprotocol.com/rfds/about)**: For proposed changes to the specification.
+- **[GitHub Discussions](https://github.com/orgs/agentclientprotocol/discussions)**: For structured, longer-form discussions.
+- **[GitHub Issues](https://github.com/agentclientprotocol/agent-client-protocol/issues)**: For actionable tasks, bug reports, and feature requests.
+
+All communication is governed by our [Code of Conduct](https://agentclientprotocol.com/community/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](https://agentclientprotocol.zulipchat.com/).
+
+#### 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](https://agentclientprotocol.com/rfds/about) 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 [email protected] directly.
+2. Follow responsible disclosure guidelines.

docs/community/governance.mdx

@@ -20,7 +20,7 @@ Note: This document describes how ACP governance is structured today (Zed-led) a
 - Companies and individuals with relevant expertise may contact Zed for component-specific administration rights
   - The goal of component-specific admins: allowing companies/individuals with specific knowledge and skillsets to administer code they're best equipped to administer
     - Example: JetBrains administers [the Kotlin SDK](https://github.com/agentclientprotocol/kotlin-sdk)
-  - Companies or individuals interested in administration may contact Zed via shared Slack channel or at [email protected]
+  - Companies or individuals interested in administration may contact Zed via [Zulip](https://agentclientprotocol.zulipchat.com/), shared Slack channel, or at [email protected]
 - Access to component administration is granted via _teams_
   - These teams have admin permissions to their specific repository/repositories, and write permissions to the [main protocol repository](https://github.com/agentclientprotocol/agent-client-protocol)
 - Zed will provide suggested permissions/rule sets for component admins, but admins are free to update these permissions within their repository(ies) as they see fit

docs/docs.json

@@ -101,6 +101,7 @@
         "tab": "Community",
         "pages": [
           "community/governance",
+          "community/communication",
           "community/code-of-conduct",
           "community/contributing"
         ]

docs/rfds/TEMPLATE.mdx renamed to docs/rfds/TEMPLATE

@@ -58,7 +58,7 @@ The project currently has a design team with the [Zed team as the lead (BDFL)](.
 
 ## Discussion and Moderation
 
-Detailed discussions often happen on Slack, with PR comments for process decisions. The results of detailed discussions should be incorporated into the relevant RFD. RFD champions actively curate discussions by collecting questions in the FAQ section. If PR discussions become too long, they should be closed, feedback summarized, and reopened with links to the original.
+Detailed discussions often happen on [Zulip](https://agentclientprotocol.zulipchat.com/), with PR comments for process decisions. The results of detailed discussions should be incorporated into the relevant RFD. RFD champions actively curate discussions by collecting questions in the FAQ section. If PR discussions become too long, they should be closed, feedback summarized, and reopened with links to the original.
 
 ## Licensing
 

docs/rfds/about.mdx

@@ -42,7 +42,7 @@ RFD proposals are merged into the "draft" section if a core team member decides
 
 Once a proposal is moved to draft, code and implementation may begin to land into the PR. This work needs to be properly feature gated and marked with the name of the RFD.
 
-Further discussion on the RFD can take place on Slack if needed.
+Further discussion on the RFD can take place on [Zulip](https://agentclientprotocol.zulipchat.com/) if needed.
 
 #### Moving to the "preview" section
 
@@ -58,7 +58,7 @@ Once accepted, RFDs become living documents that track implementation progress.
 
 ### Moderating and managing RFD discussions
 
-Moving RFDs between points in the cycle involve opening PRs. Those PRs will be places to hold dialog and discussion -- but not the only place, we expect more detailed discussions to take place on Slack or other communication channels. RFD owners and champions should actively "curate" discussions by collecting questions that come up and ensuring they are covered in the FAQ. Duplicate questions can be directed to the FAQ.
+Moving RFDs between points in the cycle involve opening PRs. Those PRs will be places to hold dialog and discussion -- but not the only place, we expect more detailed discussions to take place on [Zulip](https://agentclientprotocol.zulipchat.com/) or other communication channels. RFD owners and champions should actively "curate" discussions by collecting questions that come up and ensuring they are covered in the FAQ. Duplicate questions can be directed to the FAQ.
 
 If the discussion on the PR gets to the point where Github begins to hide comments, the PR should typically be closed, feedback collected, and then re-opened.