| --- |
| layout: contribute |
| title: Governance |
| --- |
| |
| # Governance |
| |
| The Bazel project is led by a core group of contributors, initially Googlers. |
| The group of core contributors is self-managed. |
| |
| ## Accepting contributions |
| |
| Please also see our [contribution guidelines](contributing.html). |
| |
| ### Policy |
| |
| We use the following rules for accepting code contributions. This is written |
| from the perspective that there is a group of people who cooperatively support |
| the project (the *core contributors*). In contrast, external contributors are |
| not actively supporting the project, but just contributing individual changes. |
| At this time, all core contributors work for Google, but this will hopefully |
| change over time. |
| |
| 1. We require all contributors to sign [Google's Contributor License |
| Agreement](https://cla.developers.google.com/). |
| |
| 2. We accept well-written, well-tested contributions of rules written in |
| [Skylark](docs/skylark/concepts.html), in a `contrib/` directory or similar |
| with clearly documented support policies. |
| |
| 3. We accept well-written, well-tested bug fixes to built-in rules. |
| |
| 4. We accept well-written, well-tested feature contributions if a core |
| contributor assumes support responsibilities, i.e., readily answers support |
| questions and works on bugs. This includes feature contributions from |
| external contributors. If there is no core contributor to support a feature, |
| then we will deprecate and subsequently delete the feature - we will give |
| three months' notice in such cases. |
| |
| 5. We will not accept untested changes, except in very rare cases. |
| |
| 6. We require a pre-commit code review from a core contributor for all changes. |
| For the time being, we will have to continue making changes across the |
| internal and external code bases, which will be reviewed internal to Google. |
| |
| 7. We will roll back changes if they break the internal development processes |
| of any of the core contributors. |
| |
| 8. We will move towards an open governance model where multiple parties have |
| commit access, roll-back rights, and can provide explicit support for |
| features or rules. |
| |
| 9. We will work with interested parties to improve existing extension points |
| and to establish new extension points if they do not run counter to the |
| internal requirements of any of the core contributors. |
| |
| ## Are you done open sourcing Bazel? |
| |
| Open sourcing Bazel is a work-in-progress. In particular, we're still working |
| on open sourcing: |
| |
| * Many of our unit and integration tests (which should make contributing patches |
| easier). |
| * Full IDE integration. |
| |
| Beyond code, we'd like to eventually have all code reviews, bug tracking, and |
| design decisions happen publicly, with the Bazel community involved. We are not |
| there yet, so some changes will simply appear in the Bazel repository without |
| clear explanation. Despite this lack of transparency, we want to support |
| external developers and collaborate. Thus, we are opening up the code, even |
| though some of the development is still happening internal to Google. Please |
| let us know if anything seems unclear or unjustified as we transition to an |
| open model. |
| |
| ## Are there parts of Bazel that will never be open sourced? |
| |
| Yes, some of the code base either integrates with Google-specific technology or |
| we have been looking for an excuse to get rid of (or is some combination of the |
| two). These parts of the code base are not available on GitHub and probably |
| never will be. |
| |
| ### Contact the core contributors |
| |
| <p class="lead"> |
| Contact the core team at <a href="mailto:bazel-core@googlegroups.com"> |
| bazel-core@googlegroups.com</a>. |
| </p> |