1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
---
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>
|
