chore: Update governance #5660
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,158 +5,180 @@ Learn about goose's governance structure and how to participate | |
| goose follows a lightweight technical governance model designed to support rapid iteration while maintaining community involvement. This document outlines how the project is organized and how decisions are made. | ||
|
|
||
| ## Core Values | ||
| goose's governance is guided by three fundamental values: | ||
|
|
||
| * **Open**: goose is open source, but we go beyond code availability. We plan and build in the open. Our roadmap as well as goose recipes, extensions, and prompts are editable and shareable. Our goal is to make goose the most hackable agent available. | ||
| * **Flexible**: we prefer open models – but we don’t restrict ourselves. goose equally supports remotely deployed frontier models as well as local private models, whether open or proprietary. | ||
| * **Choice**: We're not bound to any one model, protocol, or stack. goose is built for choice and open standards, adapting to your tools, workflow, and identity as a creator. | ||
|
|
||
| ## Roles | ||
|
|
||
| ### Contributors | ||
|
|
||
| Anyone in the community who contributes to goose through issues, pull requests, or discussions. Community contributions of all kinds, from code and bug reports to feature requests and discussion participation, help ensure goose evolves in directions that serve real user needs and remains aligned with how people actually use the project. | ||
|
|
||
| ### Maintainers | ||
|
|
||
| Maintainers are trusted community members responsible for key components of goose. They review pull requests, guide contributors, and ensure technical and community health within their domain. | ||
|
|
||
| #### Responsibilities | ||
|
|
||
| * Drive ongoing improvements within their component area. | ||
| * Review contributions and maintain quality. | ||
| * Foster community participation. | ||
| * Surface strategic or architectural decisions to Core Maintainers when needed. | ||
|
|
||
| Maintainers have write access to create branches on the repository but not full administrative rights. | ||
|
|
||
| ### Core Maintainers | ||
|
|
||
| Core Maintainers have broad technical understanding of goose and are responsible for the project's overall direction, technical consistency, and long-term vision. | ||
|
|
||
| #### Responsibilities | ||
|
|
||
| * Setting the overall technical direction and vision for goose | ||
| * Define and uphold goose’s technical direction and principles. | ||
| * Resolve disputes escalated by Maintainers. | ||
| * Appoint and remove Maintainers. | ||
| * Ensure the balance between innovation and stability. | ||
| * Steward goose in the best interest of the open community. | ||
|
|
||
| Core Maintainers have admin access across all repositories but use standard contribution workflows (e.g., pull requests) for transparency. | ||
|
|
||
| ## Decision-Making Process | ||
|
|
||
| ### Day-to-Day Decisions | ||
|
|
||
| * Most technical and process decisions are made through consensus in pull requests or GitHub discussions. | ||
|
Collaborator
There was a problem hiding this comment. shall we add Discord as well?
Contributor
Author
There was a problem hiding this comment. My instinct is no to Discord, since we want decisions to be easy to search and reference, so we can link to them in changelogs and release notes. Often decisions may start as a discussion in Discord, but should move to Discussions if it starts to look like something that leads to a decision. FYI @DOsinga |
||
| * Core Maintainers can approve and merge changes quickly when there's clear benefit. | ||
| * Significant architectural changes should have discussion in a GitHub issue or discussion before implementation. | ||
| * Core Maintainers may step in when disputes arise or when decisions have project-wide impact. | ||
|
|
||
| ### Dispute Resolution | ||
|
|
||
| * If Maintainers cannot reach consensus, the matter is escalated to Core Maintainers. | ||
| * Core Maintainers aim for consensus through discussion. | ||
| * If no resolution is reached after reasonable discussion, Core Maintainers may hold a simple majority vote to resolve the issue. | ||
| * All dispute resolutions should be publicly announced on GitHub and Discord. | ||
|
|
||
| This process ensures fairness and transparency while enabling timely decision-making. | ||
|
|
||
| ### Deadlocks | ||
|
|
||
| In the event of a decision deadlock in the process above, goose’s creator, Bradley Axen, steps in as a tie breaker to remove the deadlock and make progress. | ||
|
|
||
| ### Major Changes | ||
|
|
||
| Major architectural or directional changes should: | ||
|
|
||
| 1. Be proposed as a GitHub issue or discussion. | ||
| 2. Undergo open community review for at least one week. | ||
| 3. Require approval from a majority of Core Maintainers. | ||
| 4. Be publicly announced on GitHub and Discord. | ||
|
|
||
| ## Selection and Removal of Maintainers | ||
|
|
||
| ### Principles | ||
|
|
||
| * Membership is merit-based and tied to individual contributions, not employer affiliation. | ||
| * No term limits, but inactivity may lead to emeritus status. | ||
| * All appointments and removals are made transparently. | ||
|
|
||
| ### Maintainer Nomination Process | ||
|
|
||
| 1. Nomination by any existing Maintainer or Core Maintainer, based on: | ||
| * Sustained, high-quality contributions. | ||
| * Constructive participation in reviews and discussions. | ||
| * Alignment with the project’s values. | ||
| 2. Discussion among all Core Maintainers. | ||
| 3. Approval by majority vote. | ||
| 4. Public announcement on GitHub and Discord. | ||
|
|
||
| ### Core Maintainer Appointment | ||
|
|
||
| We aim to have between 3 and 7 Core Maintainers at any time. We strive for an odd number of Core Maintainers to minimise the chances of voting deadlocks, but technical excellence of candidates takes precedence over adhering precisely to numbers. | ||
|
|
||
| 1. Nomination by any existing Core Maintainer, based on: | ||
| * Everything required to be a maintainer | ||
| * Demonstrated leadership and judgement. | ||
| * Long-term commitment to the project’s values | ||
| 2. Discussion among all Core Maintainers. | ||
| 3. Approval by majority vote. | ||
| 4. Public announcement on GitHub and Discord. | ||
|
|
||
| ### Removal | ||
|
|
||
| Maintainers or Core Maintainers may be removed in the following cases: | ||
|
|
||
| * Extended inactivity of 3+ months without contribution. | ||
| * Actions contrary to the project’s values. | ||
| * By their own request. | ||
|
|
||
| Removal decisions require a majority vote of Core Maintainers and must be documented publicly. Appeals can be made to the Core Maintainers with supporting rationale. | ||
|
|
||
| ### Succession Planning | ||
|
|
||
| If a Core Maintainer leaves for any reason: | ||
|
|
||
| * The remaining Core Maintainers should appoint a replacement within 30 days. | ||
| * If Core Maintainer count falls below three, appointment of new Core Maintainers becomes a priority and appointment must happen within 15 days. No major decisions will be made until a new Core Maintainer is appointed. | ||
| * Until a replacement is appointed, remaining Core Maintainers continue governance responsibilities | ||
|
|
||
| ## Communication | ||
|
|
||
| ### Channels | ||
|
|
||
| * **GitHub**: The canonical home for issues, pull requests, and documentation. | ||
| * **Discord**: Used for real-time collaboration and informal discussions. | ||
|
|
||
| ### Transparency | ||
|
|
||
| * All technical decisions and governance discussions are to be conducted publicly. | ||
| * Meeting notes and key decisions are published openly on GitHub. | ||
| * Roadmap and priorities are openly discussed and published on GitHub. | ||
| * All proposals and changes to governance must be documented via pull requests. | ||
|
|
||
| ## Working Practices | ||
|
|
||
| ### Code Review | ||
|
|
||
| #### Following our way of working | ||
|
|
||
| * Review AI-generated work carefully: Check for redundant comments, tests that provide little to negative value, outdated patterns, and repeated code. | ||
| * Prioritize reviews: Others are waiting, but take time to understand the changes. | ||
| * Avoid review shopping: Seek review from those familiar with the code being modified. | ||
| * Test thoroughly: Manual and automated E2E testing is essential for larger features; post screenshots or videos for UI changes. | ||
|
|
||
| #### Contributing | ||
|
|
||
| * Discuss first: For new features or architectural changes, open an issue or discussion. | ||
| * Keep PRs focused: Smaller, focused changes are easier to review and merge. | ||
| * Write meaningful tests: Tests should guard against real bugs, not just increase coverage. | ||
| * Engage with the community: All Maintainers should be active on Discord and on GitHub, and be responsive to other contributors. | ||
|
|
||
| #### Release Process | ||
|
|
||
| * Regular releases with clear documentation of delivered features. | ||
| * Quick bug fixes or security resolutions are cherry-picked to patch releases when needed. | ||
| * All releases are tested by multiple Core Maintainers or Maintainers before publication. | ||
|
|
||
| ## Governance Changes | ||
|
|
||
| This governance model may evolve as goose grows. Any proposed modification to this document must: | ||
|
|
||
| 1. Be proposed through a GitHub issue with rationale. | ||
| 2. Undergo open community discussion for at least one week. | ||
| 3. Be approved by a majority of Core Maintainers. | ||
| 4. Clear communication of changes to the community. | ||
| 5. Implemented via a pull request to the GOVERNANCE.md file in the main goose repository. | ||
|
|
||
| ## Current Membership | ||
|
|
||
| Core Maintainers and Maintainers are listed in the main goose repository's [MAINTAINERS.md](https://github.com/block/goose/blob/main/MAINTAINERS.md) file with their areas of expertise where applicable. | ||
|
|
||
| ## Summary | ||
|
|
||
| ### goose's governance prioritizes | ||
|
|
||
| * **Speed**: Minimal process to support rapid experimentation | ||
| * **Openness**: Transparent decision-making and community involvement | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️