| # Project Governance |
| |
| This document defines the governance process for the CEL language. CEL is |
| Google-developed, but openly governed. Major contributors to the CEL |
| specification and its corresponding implementations constitute the CEL |
| Language Council. New members may be added by a unanimous vote of the |
| Council. |
| |
| The MAINTAINERS.md file lists the members of the CEL Language Council, and |
| unofficially indicates the "areas of expertise" of each member with respect |
| to the publicly available CEL repos. |
| |
| ## Code Changes |
| |
| Code changes must follow the standard pull request (PR) model documented in the |
| CONTRIBUTING.md for each CEL repo. All fixes and features must be reviewed by a |
| maintainer. The maintainer reserves the right to request that any feature |
| request (FR) or PR be reviewed by the language council. |
| |
| ## Syntax and Semantic Changes |
| |
| Syntactic and semantic changes must be reviewed by the CEL Language Council. |
| Maintainers may also request language council review at their discretion. |
| |
| The review process is as follows: |
| |
| - Create a Feature Request in the CEL-Spec repo. The feature description will |
| serve as an abstract for the detailed design document. |
| - Co-develop a design document with the Language Council. |
| - Once the proposer gives the design document approval, the document will be |
| linked to the FR in the CEL-Spec repo and opened for comments to members of |
| the cel-lang-discuss@googlegroups.com. |
| - The Language Council will review the design doc at the next council meeting |
| (once every three weeks) and the council decision included in the document. |
| |
| If the proposal is approved, the spec will be updated by a maintainer (if |
| applicable) and a rationale will be included in the CEL-Spec wiki to ensure |
| future developers may follow CEL's growth and direction over time. |
| |
| Approved proposals may be implemented by the proposer or by the maintainers as |
| the parties see fit. At the discretion of the maintainer, changes from the |
| approved design are permitted during implementation if they improve the user |
| experience and clarity of the feature. |