Reconcile community docs with contributor ladder

governance.mdx still carried pre-SEP-2148 content: a 7-step Discord-poll
nomination process, full role descriptions, and a 4-tier model that the
ladder supersedes. A newcomer reading both would learn two different
nomination processes.

- governance.mdx: collapse role sections into an overview that defers
  detail to the ladder; drop the old nomination process; keep named
  Lead/Core Maintainer rosters
- contributor-ladder.mdx: drop named Lead Maintainer (roster lives in
  governance.mdx only)
- working-interest-groups.mdx: align creation sponsorship with ladder
  (2 Core or 1 Lead, was 72h moderator vote); distinguish WG Lead vs
  IG Facilitator; require Member status for leadership
- CONTRIBUTING.md: Node 20 -> 24; point to design-principles instead
  of restating them
- docs.json: regroup Community tab by reader journey (Get Involved /
  Propose Changes / Governance / Roadmap); move Examples to Docs tab
- extensions/overview.mdx: fix links to removed governance anchors

Author: dsp-ant

CONTRIBUTING.md

@@ -9,7 +9,7 @@ Also see the [overall MCP communication guidelines in our docs](https://modelcon
 
 The following software is required to work on the spec:
 
-- Node.js 20 or above
+- Node.js 24 or above
 - TypeScript
 - TypeScript JSON Schema (for generating JSON schema)
 - [Mintlify](https://mintlify.com/) (optional, for docs)
@@ -102,21 +102,13 @@ When contributing to the documentation:
 
 ## Specification Proposal Guidelines
 
-### Principles of MCP
+Specification changes follow the [SEP process](https://modelcontextprotocol.io/community/sep-guidelines).
+Before drafting a proposal, review the [MCP design principles](https://modelcontextprotocol.io/community/design-principles)
+— proposals that align with these principles move faster through review.
 
-1. **Simple + Minimal**: It is much easier to add things to a specification than it is to
-   remove them. To maintain simplicity, we keep a high bar for adding new concepts and
-   primitives as each addition requires maintenance and compatibility consideration.
-2. **Concrete**: Specification changes need to be based on specific implementation
-   challenges and not on speculative ideas.
-
-### Stages of a specification proposal
-
-1. **Define**: Explore the problem space, validate that other MCP users face a similar
-   issue, and then clearly define the problem.
-2. **Prototype**: Build an example solution to the problem and demonstrate its practical
-   application.
-3. **Write**: Based on the prototype, write a specification proposal.
+The shortest summary: explore the problem space and validate that others share the problem,
+build a prototype that demonstrates a solution, then write the SEP based on what the
+prototype taught you.
 
 ## Submitting Changes
 

docs/community/contributor-ladder.mdx

@@ -183,8 +183,6 @@ When evaluating candidates, Core Maintainers should consider whether the current
 
 Lead Maintainers hold ultimate authority over MCP's direction and governance. This is a lifetime appointment reserved for project founders. There is no advancement path to this role. It is only assumed through succession (see [Succession](#succession)).
 
-**Current Lead Maintainer:** David Soria Parra
-
 **Responsibilities:**
 
 - All Core Maintainer responsibilities

docs/community/governance.mdx

@@ -41,46 +41,17 @@ All maintainers are expected to have a strong bias towards MCP's design philosop
 
 Technical governance is facilitated through a shared [Discord server](https://discord.gg/6CSzBmMkjX) for all 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 Discord server.
 
-### Maintainers
+### Roles
 
-Maintainers are responsible for [Working Groups or Interest Groups](/community/working-interest-groups) within the MCP project. These generally are independent repositories such as language-specific SDKs, but can also extend to subdirectories of a repository, such as the MCP documentation.
+The [Contributor Ladder](/community/contributor-ladder) is the canonical definition of each role — its requirements, responsibilities, privileges, advancement process, and inactivity policy. This section gives a conceptual overview of how the roles relate to governance.
 
-Maintainers may adopt their own rules and procedures for making decisions. They are expected to make decisions for their respective projects independently, but can defer or escalate to the Core Maintainers when needed.
+**Maintainers** steward specific areas such as SDKs, documentation, or [Working Groups](/community/working-interest-groups). They make decisions for their area independently and escalate to Core Maintainers when needed. Maintainers have write access to their respective repositories.
 
-**Maintainer responsibilities:**
+**Core Maintainers** steer the MCP specification and overall project direction. They can veto Maintainer decisions by majority vote, resolve disputes, and appoint or remove Maintainers. Core Maintainers have admin access to all MCP repositories but use the same pull-request workflow as outside contributors.
 
-- Thoughtful and productive engagement with community contributors
-- Maintaining and improving their respective area of the MCP project
-- Supporting documentation, roadmaps, and other adjacent parts of the MCP project
-- Presenting ideas from the community to Core Maintainers
+**Lead Maintainers** hold final authority and can veto any decision by Core Maintainers or Maintainers — the role commonly known as Benevolent Dictator for Life (BDFL). Lead Maintainers appoint and remove Core Maintainers, and are administrators on all project infrastructure. They are part of the Core Maintainer group and are expected to publicly articulate their reasoning.
 
-Maintainers are encouraged to propose additional maintainers when needed. Maintainers can only be appointed and removed by Core Maintainers or Lead Maintainers at any time and without reason.
-
-Maintainers have write and/or admin access to their respective repositories.
-
-### Core Maintainers
-
-The Core Maintainers are expected to have a deep understanding of the Model Context Protocol and its specification. Their responsibilities include:
-
-- Designing, reviewing, and steering the evolution of the MCP specification, as well as all other parts of the MCP project
-- Articulating a cohesive long-term vision for the project
-- Mediating and resolving contentious issues with fairness and transparency, seeking consensus where possible while making decisive choices when necessary
-- Appointing or removing Maintainers
-- Stewardship of the MCP project in the best interest of MCP
-
-The Core Maintainers as a group have the power to veto any decisions made by Maintainers by majority vote. The Core Maintainers have power to resolve disputes as they see fit. The Core Maintainers should publicly articulate their decision-making. The core group is responsible for adopting their own procedures for making decisions.
-
-Core Maintainers generally have write and admin access to all MCP repositories, but should use the same contribution (usually pull-request) mechanism as outside contributors. Exceptions can be made based on security considerations.
-
-### Lead Maintainers (BDFL)
-
-MCP has two Lead Maintainers: Justin Spahr-Summers and David Soria Parra. Lead Maintainers can veto any decision by Core Maintainers or Maintainers. This model is also commonly known as Benevolent Dictator for Life (BDFL) in the open source community.
-
-The Lead Maintainers should publicly articulate their decision-making and give clear reasoning for their decisions. Lead Maintainers are part of the Core Maintainer group.
-
-The Lead Maintainers are responsible for confirming or removing Core Maintainers.
-
-Lead Maintainers are administrators on all infrastructure for the MCP project where possible. This includes but is not restricted to all communication channels, GitHub organizations, and repositories.
+The [Contributor Ladder](/community/contributor-ladder) also defines the **Member** and **Community Moderator** roles, which sit outside the Steering Group.
 
 ### Decision Process
 
@@ -127,41 +98,14 @@ The MCP project maintains a [public Discord server](https://discord.gg/6CSzBmMkj
 
 ## Nominating, Confirming, and Removing Maintainers
 
-### Principles
-
-- Membership in maintainer groups is given to **individuals** on merit basis after they demonstrated strong expertise of their area of work through contributions, reviews, and discussions and are aligned with the overall MCP direction.
-- For membership in the **Maintainer** group, the individual has to demonstrate strong and continued alignment with the overall MCP principles.
-- No term limits for Maintainers or Core Maintainers.
-- Light criteria of moving Working Group or sub-project maintenance to 'emeritus' status if they don't actively participate over long periods of time. Each maintainer group may define the inactive period that's appropriate for their area.
-- The membership is for an individual, not a company.
-
-### Nomination and Removal
-
-- The Lead Maintainers are responsible for adding and removing Core Maintainers.
-- Core Maintainers are responsible for adding and removing Maintainers. They will take the consideration of existing Maintainers into account.
-- If a Working Group or Interest Group with 2+ existing Maintainers unanimously agrees to add additional Maintainers (up to a maximum of 5), they may do so without Core Maintainer review.
-
-### Nomination Process
-
-If a Maintainer (or Core/Lead Maintainer) wishes to propose a nomination for the Core/Lead Maintainers' consideration, they should follow this process:
+Membership in maintainer groups is given to **individuals** on a merit basis after demonstrated expertise and alignment with MCP's direction. Membership is associated with the person, not their employer, and has no term limit.
 
-1. Collect evidence for the nomination. This will generally come in the form of a history of merged PRs on the repositories for which maintainership is being considered.
-2. Discuss among Maintainers of the relevant group(s) as to whether they would be supportive of approving the nomination.
-3. DM a Community Moderator or Core Maintainer to create a private channel in Discord, in the format `nomination-{name}-{group}`. Add all Core Maintainers, Lead Maintainers, and co-Maintainers on the relevant group.
-4. Provide context for the individual under nomination. See below for suggestions on what to include.
-5. Create a Discord Poll and ask Core/Lead Maintainers to vote Yes/No on the nomination. Reaching consensus is encouraged though not required.
-6. After Core/Lead Maintainers discuss and/or vote, if the nomination is favorable, relevant members with permissions to update GitHub and Discord roles will add the nominee to the appropriate groups. The nominator should announce the new maintainership in the relevant Discord channel.
-7. The temporary Discord channel will be deleted a week later.
+The nomination process, sponsorship requirements, review timeline, and inactivity criteria for each role are defined in the [Contributor Ladder's Advancement Process](/community/contributor-ladder#advancement-process).
 
-**Suggestions for nomination context:**
+## Current Lead Maintainers
 
-- GitHub profile link, LinkedIn profile link, Discord username
-- For what group(s) are you nominating the individual for maintainership
-- Whether the group(s) agree that this person should be elevated to maintainership
-- Description of their contributions to date (including links to most substantial contributions)
-- Description of expected contributions moving forward (e.g., Are they eager to be a Maintainer? Will they have capacity to do so?)
-- Other context about the individual (e.g., current employer, motivations behind MCP involvement)
-- Anything else you think may be relevant to consider for the nomination
+- Justin Spahr-Summers
+- David Soria Parra
 
 ## Current Core Maintainers
 

docs/community/working-interest-groups.mdx

@@ -63,13 +63,13 @@ Within the MCP contributor community we maintain two types of collaboration form
 ### Creating an Interest Group
 
 1. Fill out the creation template in the `#wg-ig-group-creation` channel on [Discord](https://discord.gg/6CSzBmMkjX)
-2. A community moderator will review and call for a vote in `#community-moderators` (72h period, majority approval)
-3. Once approved, the Facilitator(s) organize the IG per the expectations above
+2. Secure sponsorship from at least two Core Maintainers or one Lead Maintainer
+3. Once sponsored, the Facilitator(s) organize the IG per the expectations above
 
 **Creation Template:**
 
-- Facilitator(s)
-- Maintainer(s) (optional - an official MCP Steering Group representative)
+- Facilitator(s) — must hold [Member](/community/contributor-ladder#member) status or above
+- Sponsoring Core/Lead Maintainer(s)
 - Related IGs with potentially similar goals
 - How this IG differentiates itself from related IGs
 - First topic to discuss within the IG
@@ -93,7 +93,7 @@ Within the MCP contributor community we maintain two types of collaboration form
 ### Expectations
 
 - Meaningful progress towards at least one SEP or implementation **OR** maintenance responsibilities for a project
-- Facilitators keep track of progress and communicate status
+- Leads keep track of progress and communicate status
 - Meeting dates published on the [MCP community calendar](https://meet.modelcontextprotocol.io/) with the WG channel name (e.g., `agents-wg`)
 - Notes publicly shared after meetings
 
@@ -107,13 +107,13 @@ Within the MCP contributor community we maintain two types of collaboration form
 ### Creating a Working Group
 
 1. Fill out the creation template in `#wg-ig-group-creation` on [Discord](https://discord.gg/6CSzBmMkjX)
-2. Community moderator reviews and calls for vote (72h period, majority approval)
-3. Facilitator(s) organize the WG per expectations
+2. Secure sponsorship from at least two Core Maintainers or one Lead Maintainer
+3. Lead(s) organize the WG per expectations
 
 **Creation Template:**
 
-- Facilitator(s)
-- Maintainer(s) (optional)
+- Lead(s) — must hold [Member](/community/contributor-ladder#member) status or above
+- Sponsoring Core/Lead Maintainer(s)
 - Explanation of interest/use cases (IG discussion helps but isn't required)
 - First Issue/PR/SEP the WG will work on
 
@@ -124,22 +124,24 @@ Within the MCP contributor community we maintain two types of collaboration form
   - Community moderators or Core/Lead Maintainers determine it's no longer active
   - The WG has no active Issue/PR for a month or has completed all planned work
 
-## Facilitators
+## Group Leadership
 
-A **Facilitator** is an informal role anyone can self-nominate for. Facilitators:
+Working Groups are led by **WG Leads**; Interest Groups are led by **IG Facilitators**. Both roles:
 
 - Shepherd discussions and collaboration
 - Schedule and run meetings
 - Ensure notes are published
 - Keep the group on track
 
-Being a Facilitator does **not** grant [maintainership](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) in the MCP organization. Lead and Core Maintainers may modify the list of Facilitators for any WG/IG at any time.
+Group leadership requires [Member](/community/contributor-ladder#member) status at minimum. It does **not** grant [maintainership](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) — Leads and Facilitators work with Maintainers for merge decisions. WG Leads may sponsor and triage SEPs within their scope.
+
+See the [Contributor Ladder](/community/contributor-ladder#working-group-and-interest-group-leadership) for full requirements and how this role relates to advancement.
 
 ## Meeting Calendar
 
 All IG and WG meetings are published on the public MCP community calendar at [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io/).
 
-Facilitators are responsible for posting meeting schedules in advance to enable broader participation.
+WG Leads and IG Facilitators are responsible for posting meeting schedules in advance to enable broader participation.
 
 ## FAQ
 

docs/docs.json

@@ -62,6 +62,13 @@
             "pages": [
               "docs/tools/inspector"
             ]
+          },
+          {
+            "group": "Examples",
+            "pages": [
+              "clients",
+              "examples"
+            ]
           }
         ]
       },
@@ -416,22 +423,27 @@
       {
         "tab": "Community",
         "pages": [
-          "community/contributing",
-          "community/communication",
           {
-            "group": "Principles & Direction",
+            "group": "Get Involved",
+            "pages": [
+              "community/contributing",
+              "community/communication",
+              "community/working-interest-groups"
+            ]
+          },
+          {
+            "group": "Propose Changes",
             "pages": [
-              "community/design-principles"
+              "community/design-principles",
+              "community/sep-guidelines"
             ]
           },
           {
             "group": "Governance",
             "pages": [
               "community/governance",
               "community/contributor-ladder",
-              "community/sep-guidelines",
               "community/sdk-tiers",
-              "community/working-interest-groups",
               "community/antitrust"
             ]
           },
@@ -440,13 +452,6 @@
             "pages": [
               "development/roadmap"
             ]
-          },
-          {
-            "group": "Examples",
-            "pages": [
-              "clients",
-              "examples"
-            ]
           }
         ]
       }

docs/extensions/overview.mdx

@@ -61,7 +61,7 @@ Experimental extension repositories live within the MCP GitHub organization with
 
 - Every experimental extension needs to be associated with a Working Group or Interest Group
 - Repositories and published packages need to clearly indicate their experimental status (e.g., in the README and package name)
-- [Core Maintainers](/community/governance#core-maintainers) retain oversight of experimental extension repositories, including the ability to archive or remove them
+- [Core Maintainers](/community/contributor-ladder#core-maintainer) retain oversight of experimental extension repositories, including the ability to archive or remove them
 
 ### Graduation to Official Status
 
@@ -73,7 +73,7 @@ The lifecycle for official extensions follows a SEP-based process. For full deta
 
 1. **Propose**: Create a SEP in the main MCP repository using the [standard SEP guidelines](/community/sep-guidelines) with type **Extensions Track**.
 2. **Implement**: Build at least one reference implementation in an official SDK — this is required before the SEP can be reviewed.
-3. **Review**: [Core Maintainers](/community/governance#core-maintainers) review the SEP and have final authority over inclusion.
+3. **Review**: [Core Maintainers](/community/contributor-ladder#core-maintainer) review the SEP and have final authority over inclusion.
 4. **Publish**: Once approved, open a PR to add the extension to the extension repository.
 5. **Adopt**: After that, other clients, servers, and SDKs can implement the extension too.