Given the rapid iteration on the core protocol, Zed currently leads ACP in a “Lead Maintainer”/“BDFL” capacity
As the foundations of ACP harden and adoption increases, Zed intends on transitioning ACP to a hierarchical structure with a steering committee, similar to MCP
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
Companies or individuals interested in administration may contact Zed via shared Slack channel or at hi@zed.dev
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
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
Contributors should follow a discussion -> PR model
Discussions should address what change is looking to be made, why, and summarize the hypothesized technical direction
PRs submitted without prior discussion may be redirected to create a discussion, especially for larger changes that need more input.
Repository admins (whether Zed, or specific component admins) are required code reviewers to merge any PRs
Proposals for breaking changes to the protocol must be flagged for a 5 business day review/objection window before they are merged.
if no objections, the Zed team may self-merge after the window expires
Non-breaking changes can be merged at any time. However, changes that would require additional implementation effort should have followed the discussion model above, and ideally without major objections.
Repository admins, in their own repository may merge non-breaking and breaking changes at any time. It is acknowledged that library design may require changes over time, and each repository can follow its own method of gathering feedback and discussion before making breaking changes.
The current target structure for ACP is modeled after MCP
Contributors
Maintainers (component-level)
Core Maintainers (project-level)
Lead Maintainer(s) / BDFL (initially Zed; will evolve)
Steering Committee
Unlike MCP, we have a hypothesis that companies will have a strong role in the future governance model of ACP, given its primary utility today is for company interactivity. That’s just a hypothesis, though, and as the protocol develops we’re happy to hear alternate perspectives.
