|
| 1 | +# goose Technical Governance and Stewardship |
| 2 | + |
| 3 | +Learn about goose's governance structure and how to participate |
| 4 | + |
| 5 | +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. |
| 6 | + |
| 7 | +## Core Values |
| 8 | + |
| 9 | +goose's governance is guided by three fundamental values: |
| 10 | + |
| 11 | +* **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. |
| 12 | +* **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. |
| 13 | +* **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. |
| 14 | + |
| 15 | +## Technical Governance |
| 16 | + |
| 17 | +goose adopts a streamlined two-tier structure optimized for speed and flexibility: |
| 18 | + |
| 19 | +* **Core Maintainers** drive overall project direction and make final decisions |
| 20 | +* **Maintainers** who have demonstrated extraordinary contributions and help drive specific components |
| 21 | + |
| 22 | +All Maintainers are expected to embody goose's philosophy of openness and user autonomy. Membership in the technical governance process is for individuals, not companies. |
| 23 | + |
| 24 | +### Core Maintainers |
| 25 | + |
| 26 | +Core Maintainers are members of the goose team responsible for: |
| 27 | + |
| 28 | +* Setting the overall technical direction and vision for goose |
| 29 | +* Reviewing and merging pull requests |
| 30 | +* Making architectural decisions along with Maintainers |
| 31 | +* Maintaining release processes |
| 32 | +* Resolving disputes and contentious issues |
| 33 | +* Appointing Maintainers |
| 34 | +* Ensuring goose remains fast-moving and experimental |
| 35 | +* Ensuring the quality and stability of goose |
| 36 | + |
| 37 | +Core Maintainers have full write access to the goose repositories and infrastructure. |
| 38 | + |
| 39 | +### Maintainers |
| 40 | + |
| 41 | +Maintainers are exceptional contributors from the broader community who have: |
| 42 | + |
| 43 | +* Demonstrated deep understanding of goose through significant contributions |
| 44 | +* Shown alignment with goose's values and technical direction |
| 45 | +* Consistently provided high-quality code reviews and community support |
| 46 | + |
| 47 | +Maintainers can: |
| 48 | + |
| 49 | +* Submit pull requests and push branches directly to the main repository |
| 50 | +* Review and provide feedback on pull requests |
| 51 | +* Help triage issues and guide contributors |
| 52 | +* Participate in technical discussions and planning |
| 53 | + |
| 54 | +Maintainers have write access for creating pull requests but cannot directly merge to main or modify sensitive repository settings. |
| 55 | + |
| 56 | +## Decision Making |
| 57 | + |
| 58 | +### Fast-Track Process |
| 59 | + |
| 60 | +To maintain goose's experimental and fast-moving nature: |
| 61 | + |
| 62 | +* Most decisions are made through informal consensus in pull requests, GitHub discussions, and issues |
| 63 | +* Core Maintainers can approve and merge changes quickly when there's clear benefit |
| 64 | +* Significant architectural changes ([such as adopting ACP](https://github.com/block/goose/discussions/4645)) should have discussion in a GitHub issue or discussion before implementation |
| 65 | +* We optimize for shipping and iterating rather than lengthy deliberation |
| 66 | + |
| 67 | +### Community Input |
| 68 | + |
| 69 | +While we move fast, we value community input: |
| 70 | + |
| 71 | +* All changes happen through pull requests, providing visibility |
| 72 | +* Significant features should have an associated GitHub issue describing the feature and testing approach |
| 73 | +* Community feedback is actively sought on Discord and GitHub discussions |
| 74 | +* External contributions are reviewed within two days, with merge/close decisions within two weeks |
| 75 | + |
| 76 | +## Working Practices |
| 77 | + |
| 78 | +### Code Review |
| 79 | + |
| 80 | +Following our way of working: |
| 81 | + |
| 82 | +* **Review AI-generated work carefully**: Check for redundant comments, bloated tests, outdated patterns, and repeated code |
| 83 | +* **Prioritize reviews**: Others are waiting, but take time to understand the changes |
| 84 | +* **Avoid review shopping**: Seek review from those familiar with the code being modified |
| 85 | +* **Test thoroughly**: Manual and automated E2E testing is essential for larger features; post videos for UI changes |
| 86 | + |
| 87 | +### Contributing |
| 88 | + |
| 89 | +* **Discuss first**: For new features or architectural changes, open an issue or discussion |
| 90 | +* **Keep PRs focused**: Smaller, focused changes are easier to review and merge |
| 91 | +* **Write meaningful tests**: Tests should guard against real bugs, not just increase coverage |
| 92 | +* **Engage with the community**: All Maintainers should be active on Discord and on GitHub, and be responsive to other contributors |
| 93 | + |
| 94 | +### Release Process |
| 95 | + |
| 96 | +* Regular releases with clear documentation of delivered features |
| 97 | +* Quick bug fixes or security resolutions are cherry-picked to patch releases when needed |
| 98 | +* All releases are tested by multiple Core Maintainers or Maintainers before publication |
| 99 | + |
| 100 | +## Communication |
| 101 | + |
| 102 | +### Channels |
| 103 | + |
| 104 | +* **GitHub**: Primary platform for PRs, issues, and technical discussions |
| 105 | +* **Discord**: Real-time community discussion and support |
| 106 | + |
| 107 | +### Transparency |
| 108 | + |
| 109 | +* All technical decisions are made in public through GitHub and Discord |
| 110 | +* Meeting notes and significant decisions are shared with the community on GitHub |
| 111 | +* Roadmap and priorities are openly discussed and published on GitHub |
| 112 | + |
| 113 | +## Nominating Maintainers |
| 114 | + |
| 115 | +### Principles |
| 116 | + |
| 117 | +* Recognition is based on individual merit and contributions |
| 118 | +* No term limits, but inactive Maintainers may be moved to emeritus status |
| 119 | +* Membership is for individuals, not their employers |
| 120 | + |
| 121 | +### Process |
| 122 | + |
| 123 | +1. Core Maintainers identify exceptional contributors through: |
| 124 | + - History of high-quality merged PRs |
| 125 | + - Consistent helpful code reviews |
| 126 | + - Strong community engagement |
| 127 | + - Alignment with goose values |
| 128 | +2. Discussion among Core Maintainers about the nomination |
| 129 | +3. If approved, the contributor is invited to become a Maintainer |
| 130 | +4. Announcement made to the community via Discord and GitHub |
| 131 | + |
| 132 | +### Removal |
| 133 | + |
| 134 | +Core Maintainers may remove Maintainer status if: |
| 135 | + |
| 136 | +* Extended inactivity (3+ months without contribution) |
| 137 | +* Actions contrary to goose's values |
| 138 | +* By request of the Maintainer |
| 139 | +* Appeals can be sent to the Core Maintainers group with rationale on why someone disagrees with the removal decision, with data to back up their case. As long as there is new information and good reasons to reverse the decision the appeal will be considered. |
| 140 | + |
| 141 | +## Current Membership |
| 142 | + |
| 143 | +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. |
| 144 | + |
| 145 | +## Evolution of Governance |
| 146 | + |
| 147 | +This governance model is designed to be lightweight and may evolve as goose grows. Changes to governance require: |
| 148 | + |
| 149 | +1. Proposal via GitHub issue with rationale |
| 150 | +2. Community discussion period (minimum 1 week) |
| 151 | +3. Consensus among Core Maintainers |
| 152 | +4. Clear communication of changes to the community |
| 153 | +5. A PR to the [GOVERNANCE.md](https://github.com/block/goose/blob/main/GOVERNANCE.md) file in the main goose repository |
| 154 | + |
| 155 | +The key principle is maintaining goose's ability to move fast and experiment while respecting community contributions and maintaining transparency. |
| 156 | + |
| 157 | +## Summary |
| 158 | + |
| 159 | +goose's governance prioritizes: |
| 160 | + |
| 161 | +* **Speed**: Minimal process to support rapid experimentation |
| 162 | +* **Openness**: Transparent decision-making and community involvement |
| 163 | +* **Autonomy**: Empowering users and contributors to shape goose |
| 164 | +* **Quality**: Thoughtful review while avoiding bureaucracy |
| 165 | + |
| 166 | +We believe this balance enables goose to remain innovative while building a strong, engaged community around the shared goal of creating the most hackable, user-controlled AI agent available. |
0 commit comments