mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2024-12-11 14:53:49 +00:00
44 lines
2 KiB
Markdown
44 lines
2 KiB
Markdown
|
# 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.
|