SEP-994: Shared Communication Practices/Guidelines #1002
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,98 @@ | ||
| --- | ||
| title: Contributor Communication | ||
| description: Communication strategy and framework for the Model Context Protocol community | ||
| --- | ||
|
|
||
| This document provides practical guidance for communicating and collaborating within the Model Context Protocol (MCP) project. It outlines the communication channels, workflows, and processes used by the MCP community. | ||
|
|
||
| All communication within the MCP community is governed by our [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md). We expect all participants to maintain respectful, professional, and inclusive interactions across all channels. | ||
|
|
||
| ## Communication Channels | ||
|
|
||
| We support three primary communication channels: the public Discord server, [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues), and [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) in the [main project repository](https://github.com/modelcontextprotocol/modelcontextprotocol). | ||
|
Member
There was a problem hiding this comment. A thought, just to make sure this is the intention (not blocking merging this PR): can we turn off/deprecate the org-level discussions here? @dsp-ant has indicated previously that he likes how it filters noise (more serious suggestions get made in the spec repo-level Discussions), but I wonder if @jonathanhefner 's work to help organize things on the Issues/Discussions front has addressed that to some degree (+ the SEP process is now where things lift above the noise). Curious if @jonathanhefner agrees with deprecating that, and @dsp-ant would be OK with it now. cc @olaservo who I believe raised that conversation previously
Member
There was a problem hiding this comment. Yes, I would like to turn off org-level discussions in favor of repo-level discussions. One reason is to make it clear where users should post discussions. Another reason is because GitHub does not provide a way to watch org-level discussions (other than manually subscribing to each individual thread). This, specifically, makes it difficult to moderate org-level discussions.
Member
There was a problem hiding this comment. Just let me know when you want me to do that.
Member
There was a problem hiding this comment. I don't want to disrupt ongoing conversations, so I will start transferring recently active and popular (highly upvoted or commented) discussions to the After the discussions are transferred, we can make an Announcement post and lock those forums to maintainers only. (I think the lock will apply to discussion threads as well, but I am not sure.)
Member
There was a problem hiding this comment. I have transferred most recently active / popular discussions from the org to this repo. I did not transfer any of the show and tell discussions. To me, those don't quite fit in this specific repo, but, if it's something we want, I can transfer the most recent threads. Regarding SDK-related discussions, the only two notably active discussions I found were related to the Java SDK: https://github.com/orgs/modelcontextprotocol/discussions/246 and https://github.com/orgs/modelcontextprotocol/discussions/322. Perhaps someone with sufficient permissions could transfer those to the Java SDK repo?
Contributor
There was a problem hiding this comment. can we link to the Discord server like we are doing for GitHub?
Contributor
Author
There was a problem hiding this comment. @tadasant is there a way for us to do this with some kind of universal invite?
Member
There was a problem hiding this comment. there's this one from the CWG github:
Member
There was a problem hiding this comment. Agree that we can just keep using |
||
|
|
||
| ### Discord | ||
|
|
||
| For real-time contributor discussion and collaboration. The server is designed around **MCP contributors** and is not intended | ||
| to be a place for general MCP support. | ||
|
|
||
| The Discord server will have both public and private channels. | ||
|
|
||
| #### Public Channels (Default) | ||
|
|
||
| - **Purpose**: Open community engagement, collaborative development, and transparent project coordination. | ||
| - Primary use cases: | ||
| - **Public SDK and tooling development**: All development, from ideation to release planning, happens in public channels (e.g., `#typescript-sdk-dev`, `#inspector-dev`). | ||
| - **Working and interest group discussions** (`#client-implementors`, `#agents-wg`, etc.) | ||
| - **Working Group**: Some specific goal or project in mind (such as an SDK, inspector, registry, server-identity, load-balancing, etc). | ||
|
localden marked this conversation as resolved.
|
||
| - **Interest Group**: An abstract gathering of folks that might raise a range of various topics. Some might get actioned on as one-offs, others might spin into Working Groups. | ||
| - **Community onboarding** and contribution guidance. | ||
| - **Community feedback** and collaborative brainstorming. | ||
| - Public **office hours** and **maintainer availability**. | ||
|
localden marked this conversation as resolved.
|
||
| - Avoid: | ||
| - MCP 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 Discord 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 GitHub Discussions and/or Issues, and will be labeled with `notes`. | ||
| - **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 Discord that leads to a potential decision or proposal must be moved to a GitHub Discussion or GitHub Issue to create a persistent, searchable record. Proposals will then be promoted to full-fledged PRs with associated work items (GitHub Issues) as needed. | ||
|
|
||
| ### GitHub Discussions | ||
|
|
||
| For structured, long-form discussion and debate on project direction, features, improvements, and community topics. | ||
|
|
||
| When to use: | ||
|
|
||
| - Project roadmap planning and milestone discussions | ||
| - Announcements and release communications | ||
| - Community polls and consensus-building processes | ||
|
localden marked this conversation as resolved.
|
||
| - 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: | ||
|
|
||
| - Submit SEP proposals (following the [SEP guidelines](./sep-guidelines)) | ||
| - Bug reports with reproducible steps | ||
|
localden marked this conversation as resolved.
|
||
| - 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. Use the private security reporting process. For protocol-level security issues, follow the process in [SECURITY.md in the modelcontextprotocol GitHub repository](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md). | ||
| 2. Contact lead and/or [core maintainers](./governance#current-core-maintainers) directly. | ||
| 3. Follow responsible disclosure guidelines. | ||
|
|
||
| ## Decision Records | ||
|
|
||
| All MCP decisions are documented and captured in public channels. | ||
|
|
||
| - **Technical decisions**: [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs. | ||
| - **Specification changes**: [On the Model Context Protocol website](https://modelcontextprotocol.io/specification/draft/changelog). | ||
| - **Process changes**: [Community documentation](https://modelcontextprotocol.io/community/governance). | ||
| - **Governance decisions and updates**: [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs. | ||
|
|
||
| When documenting decisions, we will retain as much context as possible: | ||
|
|
||
| - Decision makers | ||
| - Background context and motivation | ||
| - Options that were considered | ||
| - Rationale for the chosen approach | ||
| - Implementation steps | ||
Uh oh!
There was an error while loading. Please reload this page.