SEP-001: Introduce Governance Model and SEP Process #931
Conversation
docs/community/sep-guidelines.mdx
Outdated
|
|
||
| The standard SEP workflow is: | ||
|
|
||
| 1. You, the SEP author, fork the MCP repository and create a well-formatted GitHub Issue with the proposal and SEP tags |
There was a problem hiding this comment.
This point mentions forking the MCP repository. Should "GitHub Issue" be "GitHub Pull Request" (likewise for all previous instances of "GitHub Issue")? Or do we want to start the process with a GitHub issue and then transition to a pull request once there is a sponsor?
There was a problem hiding this comment.
Ah right, this was a left-over from the old-style that was using a repository with PRs for the SEPs instead of github issues.
docs/community/sep-guidelines.mdx
Outdated
| The standard SEP workflow is: | ||
|
|
||
| 1. You, the SEP author, fork the MCP repository and create a well-formatted GitHub Issue with the proposal and SEP tags | ||
| 2. Find a Core Maintainer or Maintainer to sponsor your proposal. Core Maintainers and Maintainers will regularly go over the list of open proposals to determine which proposals to sponsor. Once a sponsor is found, the sponsor is "assigned" to the issue and a milestone is assigned. The tag `draft` is added |
There was a problem hiding this comment.
If a proposal does not find a sponsor after a certain amount of time, should it be automatically rejected? My instinct would be "no", but we would need some way to address accumulation of issues / pull requests.
Alternatively, we could mandate that all pre-sponsor proposals start as a GitHub discussion, which can be converted to a GitHub issue (via GitHub's UI) upon obtaining a sponsor.
There was a problem hiding this comment.
I'm of the view that making items perishable is a good approach.
There was a problem hiding this comment.
I rather don't want two different spots. Part of preparing a SEP is also putting the effort in. I am okay with issues sitting there without having a sponsor for a while. I think eventually we want to close them out, but i am okay with long timeframes. If you watn to draft an update that says non-sponsored proposals automatically are removed after 3 months (not 'rejected'), I think thats fine.
There was a problem hiding this comment.
Agree that noting a timeout on languishing unsponsored proposals is a good idea (rather than leaving their fate undefined). Not sure how much value it adds to be super precise about the exact TTL though - could just be something like "proposals will be closed if they fail to find sponsorship after an extended period".
Also definitely agree with the need to distinguish between this state and "rejected".
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
|
👍 |
Joffref
left a comment
Joffref
left a comment
There was a problem hiding this comment.
Overall, I really appreciate the work done here — it feels like the MCP community is getting stronger with this kind of governance.
A few general remarks on the SEP process:
- It might be helpful to mention whether there's a pull request template for SEPs. If not, happy to help!
- Are SEPs stored directly in the repository? I know Kubernetes does this, and I really appreciate it — it allows you to track proposals through the documentation and helps with versioning in case of errata. Relying only on issues or PRs can feel a bit bloated for that purpose.
|
|
||
| Projects are concrete components maintained in dedicated repositories. These include the Specification, TypeScript SDK, Go SDK, Inspector, and other implementation artifacts. | ||
|
|
||
| Working groups are forums for collaboration where interested parties discuss specific aspects of MCP without maintaining code repositories. These include groups focused on transport protocols, client implementation, and other cross-cutting concerns. |
There was a problem hiding this comment.
How those WGs are related to MCP Community WGs?
There was a problem hiding this comment.
They are largely unconnected. There are cases where there are parallels (for example there is a security-wg in both the steering WG's and the community WG's), and naturally folks end up being involved in both and cross-pollinating discussions, but there is no hard link between the two.
Our plan regarding CWG is to add a link encouraging participation in CWG somewhere on a page like this, however it will not be added to the formal "governance" documentation at this time. CWG is more of a facilitation tool within community moderation than a formal governance component.
There was a problem hiding this comment.
Let’s be a bit controversial here: what’s the point of having CWGs if, in the end, the Steering WG makes the final decisions? I know most CWG leads are part of the MCP maintainer team—but what about those who aren’t? How do CWGs align with the Steering WG?
It feels like we’re discarding some of the progress we've made and reducing CWGs to a discussion group around MCP, rather than an active force shaping it. I had hoped this governance would strengthen CWGs and give them more ownership of the MCP roadmap—either by influencing changes based on community needs or by realigning CWGs with the broader direction of the project.
There was a problem hiding this comment.
I think CWGs influence stems from it's connection with the maintainers. I think CWG members own't find it hard to find sponsors for proposal they have discussed and prepared.
docs/community/governance.mdx
Outdated
| Projects and working groups without specified processes default to: | ||
|
|
||
| - GitHub pull requests and issues for contributions | ||
| - A public channel in the official MCP Discord |
There was a problem hiding this comment.
Is it possible to join it already?
There was a problem hiding this comment.
Not sure if this "public Discord" reference is just an artifact of a draft that isn't mean to be in this doc, but if it's intentional does it imply that a third Discord that is not Steering or CWG will be created? Or was the idea to repurpose one or the other of them?
There was a problem hiding this comment.
We are reworking the discord. This is a left-over that comes from putting governance out first and then doing the discord, which probably not very good sequencing, but the one we are going with for now. @tadasant we should talk about whats the best way to go about this is.
There was a problem hiding this comment.
If this gets merged before the discord gets reworked, can we add something obvious about this being TBD? Otherwise I think people might get confused about which discord this refers to.
| 1. **Standards Track** SEP describes a new feature or implementation for the Model Context Protocol. It may also describe an interoperability standard that will be supported outside the core protocol specification. | ||
| 2. **Informational** SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent a MCP community consensus or recommendation. | ||
| 3. **Process** SEP describes a process surrounding MCP, or proposes a change to (or an event in) a process. Process SEPs are like Standards Track SEPs but apply to areas other than the MCP protocol itself. |
There was a problem hiding this comment.
I think a few concrete examples would be useful. Based on my understanding:
- Standards Track — Asynchronous support in MCP (e.g Transport-agnostic resumable streams #899)
- Informational — Load balancing with MCP (e.g., Add best practices when using load balancer #325)
- Process — MCP Registry (https://github.com/modelcontextprotocol/registry)
There was a problem hiding this comment.
Please feel free to draft a specific change you have in mind.
There was a problem hiding this comment.
I just opened this PR targeting this branch: #957
izzymsft
left a comment
izzymsft
left a comment
There was a problem hiding this comment.
Thanks @dsp-ant for putting this together. This formal process is necessary.
I think the community can take a look at how decisions and voting are made in the Apache Communities and CNCF.
I have a couple of questions when it comes to certain decisions.
- As the community grows, would voting be needed to add, promote, downgrade or remove members at the different tiers?
- what is the minimum number of votes needed for approval?
- what types of votes do we count? for example if a lead maintainer votes, does their support or objection override all other votes?
- how many hours after the minimum votes is achieved do we wait before the vote is finalized?
- how are objections handled?
- how would the rules that govern voting be maintained and updated?
pcarleton
left a comment
pcarleton
left a comment
There was a problem hiding this comment.
overall LGTM, left a few wording suggestions
tadasant
left a comment
tadasant
left a comment
There was a problem hiding this comment.
Thanks for getting this going!
|
|
||
| ### Channels | ||
|
|
||
| Technical Governance is facilitated through a shared Discord server of all **maintainers, core maintainers** and **lead maintainers**. Each maintainer group can choose additional communication channels, but all decisions and their supporting discussions must be recorded and made transparently available on the core group Discord server. |
There was a problem hiding this comment.
Is this intentionally pointing to the Discord as the most important system of record? I would have thought we would continue to prioritize making sure decisions, discussions are made in public on GitHub, and more ephemeral, logistical exchanges be the purview of Discord.
There was a problem hiding this comment.
This is the perspective that shaped how the CWG operates, and overall, it works quite well. Personally, I see Discord messages as the starting point for decision-making and consensus-building in an informal setting. The views and opinions of each stakeholder should be represented and respected in github discussions/issues.
There was a problem hiding this comment.
@tadasant good point. We should probablyt have a separate form. For example Typescript also uses Github issues for meeting notes. Happy to streamline it around either Github Issues or a Repository, depending on which way we want to go.
There was a problem hiding this comment.
(For anyone reading, example of a Typescript GH Issue for meeting notes)
Suggestion to capture the high level Discord vs. GitHub balance without being too prescriptive on the details for now:
| Technical Governance is facilitated through a shared Discord server of all **maintainers, core maintainers** and **lead maintainers**. Each maintainer group can choose additional communication channels, but all decisions and their supporting discussions must be recorded and made transparently available on the core group Discord server. | |
| Technical Governance is facilitated through either a shared Discord server or GitHub. **Maintainers**, **core maintainers** and **lead maintainers** should all be present in the shared Discord server. All decisions and their supporting discussions must be recorded and made transparently available on GitHub so that they are easily discoverable. |
|
|
||
| Projects are concrete components maintained in dedicated repositories. These include the Specification, TypeScript SDK, Go SDK, Inspector, and other implementation artifacts. | ||
|
|
||
| Working groups are forums for collaboration where interested parties discuss specific aspects of MCP without maintaining code repositories. These include groups focused on transport protocols, client implementation, and other cross-cutting concerns. |
There was a problem hiding this comment.
They are largely unconnected. There are cases where there are parallels (for example there is a security-wg in both the steering WG's and the community WG's), and naturally folks end up being involved in both and cross-pollinating discussions, but there is no hard link between the two.
Our plan regarding CWG is to add a link encouraging participation in CWG somewhere on a page like this, however it will not be added to the formal "governance" documentation at this time. CWG is more of a facilitation tool within community moderation than a formal governance component.
docs/community/governance.mdx
Outdated
| Projects and working groups without specified processes default to: | ||
|
|
||
| - GitHub pull requests and issues for contributions | ||
| - A public channel in the official MCP Discord |
There was a problem hiding this comment.
Not sure if this "public Discord" reference is just an artifact of a draft that isn't mean to be in this doc, but if it's intentional does it imply that a third Discord that is not Steering or CWG will be created? Or was the idea to repurpose one or the other of them?
Co-authored-by: Paul Carleton <paulc@anthropic.com>
Co-authored-by: Paul Carleton <paulc@anthropic.com>
Co-authored-by: Paul Carleton <paulc@anthropic.com>
Co-authored-by: Tadas Antanavicius <tadas@tadasant.com>
Co-authored-by: Tadas Antanavicius <tadas@tadasant.com>
bhosmer-ant
left a comment
bhosmer-ant
left a comment
There was a problem hiding this comment.
A couple of very minor typo fixes inline - main things I noticed have been covered by other commenters already (and largely addressed). I think remaining potential clarifications are mostly around voting/nomination per @izzymsft, though those could also be deferred to a subsequent SEP and referenced here as pending.
docs/community/sep-guidelines.mdx
Outdated
| The standard SEP workflow is: | ||
|
|
||
| 1. You, the SEP author, fork the MCP repository and create a well-formatted GitHub Issue with the proposal and SEP tags | ||
| 2. Find a Core Maintainer or Maintainer to sponsor your proposal. Core Maintainers and Maintainers will regularly go over the list of open proposals to determine which proposals to sponsor. Once a sponsor is found, the sponsor is "assigned" to the issue and a milestone is assigned. The tag `draft` is added |
There was a problem hiding this comment.
Agree that noting a timeout on languishing unsponsored proposals is a good idea (rather than leaving their fate undefined). Not sure how much value it adds to be super precise about the exact TTL though - could just be something like "proposals will be closed if they fail to find sponsorship after an extended period".
Also definitely agree with the need to distinguish between this state and "rejected".
localden
left a comment
localden
left a comment
There was a problem hiding this comment.
LGTM, minor feedback items.
Add SEP superseded state
dsp-ant
dismissed stale reviews from ihrpr, localden, and bhosmer-ant
via
30e01b5
Co-authored-by: Den Delimarsky 🌺 <53200638+localden@users.noreply.github.com>
Co-authored-by: Den Delimarsky 🌺 <53200638+localden@users.noreply.github.com>
Co-authored-by: Den Delimarsky 🌺 <53200638+localden@users.noreply.github.com>
Co-authored-by: Den Delimarsky 🌺 <53200638+localden@users.noreply.github.com>
Co-authored-by: Den Delimarsky 🌺 <53200638+localden@users.noreply.github.com>
This are good concerns that we can work on in follows ups. For now it's simple majority of core maintainers. Lead maintainers have veto rights, but otherwise their votes inside the core maintainer group counts equally |
|
|
||
| Because the SEPs are maintained as text files in a versioned repository (GitHub Issues), their revision history is the historical record of the feature proposal. | ||
|
|
||
| ## SEP Types |
There was a problem hiding this comment.
similar to Joffre's comment below:
After reading this, it is still not 100% clear to me on what qualifies a SEP vs a regular Github issue. I'm attempting this to make it clearer:
What qualifies a SEP?
The goal is to reserve the SEP process for changes that are substantial enough to require broad community discussion, a formal design document, and a historical record of the decision-making process. A regular GitHub issue or pull request is often more appropriate for smaller, more direct changes.
Consider proposing a SEP if your change involves any of the following:
- A New Feature or Protocol Change: Any change that adds, modifies, or removes features in the Model Context Protocol. This includes:
- Adding new API endpoints or methods.
- Changing the syntax or semantics of existing data structures or messages.
- Introducing a new standard for interoperability between different MCP-compatible tools.
- A Breaking Change: Any change that is not backwards-compatible.
- A Change to Governance or Process: Any proposal that alters the project's decision-making, contribution guidelines (like this document itself).
- A Complex or Controversial Topic: If a change is likely to have multiple valid solutions or generate significant debate, the SEP process provides the necessary framework to explore alternatives, document the rationale, and build community consensus before implementation begins.
There was a problem hiding this comment.
@pwwpche Can you add this to the sep-guidelines in a follow up PR?
|
|
||
| Proposed changes to the specification must come in the form of a written version, starting with a summary of the proposal, outlining the **problem** it tries to solve, propose **solution**, **alternatives**, **considerations, outcomes** and **risks**. The [SEP Guidelines](/community/sep-guidelines) outline information on the expected structure of SEPs. SEP's are should be created as issues in the [specification repository](https://github.com/modelcontextprotocol/specification) and tagged with the labels `proposal, sep`. | ||
|
|
||
| All proposals must have a **sponsor** from the MCP steering group (maintainer, core maintainer or lead core maintainer). The sponsor is responsible for ensuring that the proposal is actively developed, meets the quality standard for proposals and is responsible for presenting and discussing it in meetings of core maintainers. Maintainer and Core Maintainer groups should review open proposals without sponsors in regular intervals. Proposals that do not find a sponsor within six months are automatically rejected. |
There was a problem hiding this comment.
Developers would most likely interact with the group of maintainers. Could we also publish the maintainer list somewhere so that it's easier to identify them for developers in Github?
There was a problem hiding this comment.
My thought is that it should be documented in a MAINTAINERS.md file, which would also help track ownership changes through PRs
| 1. You, the SEP author, fork the MCP repository and create a well-formatted GitHub Issue with the proposal and SEP tags | ||
| 2. Find a Core Maintainer or Maintainer to sponsor your proposal. Core Maintainers and Maintainers will regularly go over the list of open proposals to determine which proposals to sponsor. Once a sponsor is found, the sponsor is "assigned" to the issue and a milestone is assigned. The tag `draft` is added. At this point a unique SEP number is assigned. | ||
| 3. The sponsor will review and may request changes before formal review, based on community feedback. Once ready for review, the tag `in-review` is added. | ||
| 4. Once sponsored, the SEP enters formal review by the core team |
There was a problem hiding this comment.
| 4. Once sponsored, the SEP enters formal review by the core team | |
| 4. Once tagged `in-review`, the SEP enters formal review by the core team |
| - Clear benefit to the MCP ecosystem | ||
| - Community support and consensus | ||
|
|
||
| Once a SEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to "Final". |
There was a problem hiding this comment.
Regarding "main source code repository", did we mean any of the SDK repository or anything else?
Co-authored-by: Che Liu <cheliu@google.com>
|
I merged this for now to ensure we have a version in, but i think there were some good ideas in the thread. Please do follow up PRs for this. |
Summary
Changes
/docs/community/governance.mdx- Comprehensive governance documentation/docs/community/sep-guidelines.mdx- SEP submission and review guidelines/docs/docs.json- Added new pages to documentation structureRationale
As the MCP project grows, we need clear governance and contribution processes to ensure:
This PR implements the governance model itself, with this being the first formal SEP submission following the new process.
Related Issue
Will create SEP-001 issue after PR creation to follow the new process.