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 Zulip, shared Slack channel, or at [email protected]
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.
All repositories in the ACP organization should be licensed under the Apache 2.0 License.
This project does not require a Contributor License Agreement (CLA). Instead, contributions are accepted under the following terms:
By contributing to this project, you agree that your contributions will be licensed under the Apache License, Version 2.0. You affirm that you have the legal right to submit your work, that you are not including code you do not have rights to, and that you understand contributions are made without requiring a Contributor License Agreement (CLA).
