SEP-2149: MCP Group Governance and Charter Template by dsp-ant · Pull Request #2149 · modelcontextprotocol/modelcontextprotocol

dsp-ant · 2026-01-26T11:11:57Z

Summary

Introduces SEP-2149: governance rules and charter template for MCP Working Groups (WGs) and Interest Groups (IGs)
Distinguishes WG Leads from IG Facilitators throughout all governance rules; clarifies that WG Leads hold SEP sponsorship privileges
Adds IG graduation path to WG, 8-week transition period for existing groups, and CODEOWNERS rules requiring maintainer approval for charter/overview pages

Changes in this PR

CODEOWNERS: Add rules requiring Maintainer approval for WG/IG overview pages and Core Maintainer approval for charter documents
SEP-2149 document: Full governance spec covering leadership, responsibilities, participation tiers, decision-making, escalation, meeting requirements, communication channels, reporting, and lifecycle (formation, graduation, retirement)
Terminology: Consistently use "Leads" for WGs and "Facilitators" for IGs; fix typos (Maintian→Maintain, respctive→respective)
Participation tiers: Explicitly grant WG Leads SEP sponsorship privileges
Escalation: Tighten step 3 trigger (remove "does not pass" to avoid ambiguity)
IG graduation: Add formal process for IGs to petition Core Maintainers to charter a WG
node engine: Relax engine constraint from >=20,<25 to >=20

Test plan

Review governance rules for consistency between WG and IG terminology
Verify CODEOWNERS patterns match expected directory structure
Check that the charter template section is usable standalone for new groups
Confirm transition period language is clear for existing groups

🤖 Generated with Claude Code (0% 5-shotted by claude)

cliffhall

Duplicated sentence.

tadasant

This is great! I think it's a good time to formalize this; the current "free for all" WG/IG structure has served its purpose the last few months helping pave a path to seeing what norms emerged organically, and I think this proposal captures what seems to be working best without moving into being overly prescriptive too early. Thank you @sarahnovotny it feels like a lot of careful community input went into distilling all of this.

Not sure if you need a sponsor here or already have someone in mind but I'd be happy to fill that role here if helpful @dsp-ant

dsp-ant · 2026-02-09T23:24:25Z

Thanks for the feedback everyone. I've pushed a round of updates

The previous version used "WG recommends" in the authority table without defining what that means in practice. I've replaced it with "WG consensus" and defined it as a concrete 3-step progression:
1. Lazy consensus (default) — proposal with a deadline, silence is consent, Members can
  block with documented objections
2. Formal vote — triggered when a Member blocks or a Lead/3+ Members request it
3. Escalation to Core Maintainers — only when a vote fails to resolve (no quorum, doesn't
  pass, or result is contested)

This makes it clear when voting happens vs. when escalation happens.

Not all disagreements are votable. Scope disputes, authority questions, cross-WG conflicts, conduct concerns, and membership disputes should bypass voting and escalate directly to Core Maintainers
Removed the prescriptive meeting frequency table as a requirement. WG Leads now determine their own cadence based on the group's current needs and lifecycle stage. The previous weekly working session + monthly office hours table is kept as a common example. Hard requirements remain around openness, advance scheduling, agendas, and published notes.

SamMorrowDrums

I think this a great improvement. A couple of areas I think might need some further consideration:

guidance on where GitHub Discussions take place should be a link (and possible needs guidance in both creation and also WG adoption of relevant discussions that are in their AoR)
the working group formation part needs some guidance and probably some real improvements off the back of this, I know that I've found it incredibly difficult to get engagement from maintainers via discord and if it wasn't for @olaservo I'd have probably given up 😅. Not sure if doing something wrong, but having demonstrated demand and interest from key players, it's kind of not good enough to feel left hanging (and no judgement, I appreciate how overstretched everyone is), but I hope that a good process is the solution and the rest will go more smoothly.

Apologies for sounding negative while I'm reviewing PR, I was attempting to enumerate why I think certain clarifications and clear processes would help, which is exactly what you're setting out to do here @dsp-ant so I really appreciate these recent contributions! 🙏

SamMorrowDrums · 2026-02-10T09:00:33Z

+
+**Lead Requirements:**
+
+- Demonstrated sustained contribution to scope area


This is discretionary from maintainers/sponsor's discretion right? I don't think it needs to be explicitly defined here. Just clarifying.

I think you documented what this means more concretely elsewhere already.

Perhaps more internal linking would avoid questions (and help to maintain consistency between docs by making links and definition sources more explicit).

dsp-ant · 2026-02-10T18:08:01Z

the working group formation part needs some guidance and probably some real improvements off the back of this, I know that I've found it incredibly difficult to get engagement from maintainers via discord and if it wasn't for @olaservo I'd have probably given up 😅. Not sure if doing something wrong, but having demonstrated demand and interest from key players, it's kind of not good enough to feel left hanging (and no judgement, I appreciate how overstretched everyone is), but I hope that a good process is the solution and the rest will go more smoothly.

I honestly not fully sure how to best handle this. What are the alternatives here? The main issue is that the formation is less the problem, but ensuring that it fits into the direction of the project. Currently we have problems when an WG goes ahead, forms and creates output that CMs don't approve of in the first place. The idea here is to have WG's form only if CMs agree with the charter. I am happy to try other approaches as well. We can say for example "At least three sponsors across Core Maintainers Lead Maintainers and Maintainers".

SamMorrowDrums · 2026-02-10T19:20:35Z

Yes that's exactly the issue, and all I imagine is perhaps something less casual than discord message for ideation, preparation and actual proposal for a WG, and some regular interval that you can expect a proposal to be reviewed within.

I agree WGs shouldn't be created lightly, and the CM charter approval is fundamental, if you can't convince the core maintainers of the value prop then you need to either move on or work on the proposal and try again.

I want the process to be rigorous and relatively infrequent (bias to existing WGs etc.) but I found it tremendously easy to propose a WG that was initiated by a CM, but so far quite challenging as a self initiated proposal. This is definitely non-blocking feedback at any rate, just a consideration for a follow-up if you or others agree there's an improvement to be made.

dsp-ant · 2026-02-10T19:26:28Z

Yes that's exactly the issue, and all I imagine is perhaps something less casual than discord message for ideation, preparation and actual proposal for a WG, and some regular interval that you can expect a proposal to be reviewed within.

I agree WGs shouldn't be created lightly, and the CM charter approval is fundamental, if you can't convince the core maintainers of the value prop then you need to either move on or work on the proposal and try again.

I want the process to be rigorous and relatively infrequent (bias to existing WGs etc.) but I found it tremendously easy to propose a WG that was initiated by a CM, but so far quite challenging as a self initiated proposal. This is definitely non-blocking feedback at any rate, just a consideration for a follow-up if you or others agree there's an improvement to be made.

I think you are right. I am open to any suggestion here and just try things until we get it right.

dsp-ant · 2026-02-10T19:29:49Z

Antoher thing to consider is adding automation here via discord bots or a google form, that puts it onto the agenda for MCP Core Maintainers.

scottslewis · 2026-02-10T20:20:09Z

I think you are right. I am open to any suggestion here and just try things until we get it right.

FWIW, previous OSS foundations have frequently started programs for incubator/experimental projects + working groups...or other similar wording. These can be standardization efforts (e.g. protocol experimentation), or sdk/tech standardization...e.g. sdk APIs...or associated with just one technology/sdk/project/technical area...e.g. server tooling).

I think it's likely that the LF has some sort of concept and explicit support for such things...unfortunately I don't know the details there.

Just to be explicit: I'm not saying that everything has to follow history here...rather I'm just saying that previous experiences can be helpful for finding the right path.

sambhav · 2026-02-11T22:06:31Z

the working group formation part needs some guidance and probably some real improvements off the back of this, I know that I've found it incredibly difficult to get engagement from maintainers via discord and if it wasn't for @olaservo I'd have probably given up 😅. Not sure if doing something wrong, but having demonstrated demand and interest from key players, it's kind of not good enough to feel left hanging (and no judgement, I appreciate how overstretched everyone is), but I hope that a good process is the solution and the rest will go more smoothly.

I honestly not fully sure how to best handle this. What are the alternatives here? The main issue is that the formation is less the problem, but ensuring that it fits into the direction of the project. Currently we have problems when an WG goes ahead, forms and creates output that CMs don't approve of in the first place. The idea here is to have WG's form only if CMs agree with the charter. I am happy to try other approaches as well. We can say for example "At least three sponsors across Core Maintainers Lead Maintainers and Maintainers".

One option is to leverage our pulumi automation. Users create a PR - if it gets approved (with appropriate approval requirements using codeowners) and merged, the channel/WG and other things are set up.

Co-authored-by: Tadas Antanavicius <[email protected]>

Address concern about unintentional WG capture by adding an explicit lead responsibility to proactively reach out to relevant participants to ensure broad, representative membership across organizations and perspectives, particularly during formation and when members depart or become inactive. Co-Authored-By: Claude Opus 4.6 <[email protected]>

Rework the escalation process to address concerns raised by Luca and Sarah: emphasize resolving disagreements locally first, escalate to the CM group rather than a single CM, have the group designate a CM to handle resolution (avoiding shared organizational affiliation with the parties involved), and report back to the group. Co-Authored-By: Claude Opus 4.6 <[email protected]>

Switch agenda and meeting notes from GitHub issues to the Meeting Notes category in GitHub Discussions. Remove the recording requirement due to technical hurdles. Co-Authored-By: Claude Opus 4.6 <[email protected]>

…xibility Refactor the charter template to use a 3-step decision-making progression (lazy consensus → formal vote → escalation), clarify which disputes should bypass WG voting and escalate directly to Core Maintainers, make meeting cadence flexible based on WG lifecycle stage, and add expectations for community involvement in operational duties. Co-Authored-By: Claude Opus 4.6 <[email protected]>

Separate the SEP into two clear parts: Part 1 (Group Governance): Fixed rules that apply uniformly to all groups - leadership, participation tiers, decision-making, escalation, meeting requirements, reporting, and lifecycle. Part 2 (Charter Template): Fields each group fills in - mission, scope, leadership roster, authority table, membership, operations, and deliverables. Extend coverage to both Working Groups and Interest Groups with lighter requirements for IGs where appropriate (no formal decision authority, no deliverables tracking, no quarterly reporting).

Existing WGs and IGs are grandfathered in and do not need to re-apply through the formation process. They have 8 weeks to create a conforming charter or be considered inactive.

…2149 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Co-authored-by: Den Delimarsky <[email protected]>

- Distinguish WG Leads from IG Facilitators throughout governance rules - Fix typos in Section 1.2 (Maintain/respective) - Add WG Lead SEP sponsorship privileges to participation tiers - Clarify step 3 escalation trigger (remove "does not pass" condition) - Add IG graduation to WG process - Relax node engine constraint from >=20,<25 to >=20 Co-Authored-By: Claude Opus 4.6 <[email protected]>

- Rename group participation tier Member to WG Member to avoid collision with the org-wide ladder Member role - Fix Lead Core Maintainer terminology to Lead Maintainer - Move CM sponsorship, ladder Member prerequisite, and sustained-engagement requirement to all Leads (WG and IG), not WG-only - Replace Community Moderator IG governance authority with Core Maintainer authority (formation, retirement, charter amendments) - Grant WG Leads SEP triage authority in responsibility list and authority table - Add cross-reference to SEP-2148 in abstract - Fix typos (Maintain, respective)

- Add docs/community/charter-template.mdx with copyable fill-in template - Rewrite docs/community/working-interest-groups.mdx with Part 1 governance rules (leadership, participation, decision-making, escalation, lifecycle) while keeping the IG/WG explanations, quick reference, and FAQ - Add charter-template to docs.json nav - Apply review feedback: backtick channel names, docs/ path prefixes, blockquote formatting for examples - Update SEP Reference Implementation section to match actual artifacts

Co-authored-by: Jonathan Hefner <[email protected]>

…optional - §1.8: Quarterly updates posted to the WG's GitHub Discussions category, optionally reviewed in core maintainer meetings - §6: Membership list can be omitted for groups with no members yet - §1.9: Sync 'widely acknowledged concern' wording to governance doc - Propagate all SEP changes to working-interest-groups.mdx and charter-template.mdx - Relax agenda publishing requirement in governance doc

Drop the 24-hour advance requirement; agendas must be published and available but can be posted closer to the meeting time.

- Change status from Draft to Final - Fix contributor-ladder links to use /seps/ path - Regenerate SEP docs and navigation

dsp-ant changed the title ~~SEP-0000: MCP Working Group Charter Template~~ SEP-2149: MCP Working Group Charter Template Jan 26, 2026

dsp-ant requested a review from a team January 26, 2026 11:30

dsp-ant self-assigned this Jan 26, 2026

dsp-ant added SEP draft SEP proposal with a sponsor. labels Jan 26, 2026

github-project-automation Bot added this to SEP Review Pipeline Jan 26, 2026

olaservo mentioned this pull request Jan 26, 2026

SEP-2148: MCP Contributor Ladder #2148

Merged

cliffhall requested changes Jan 26, 2026

View reviewed changes