As Bazel adoption grows, we are seeing both more requests for adding features to Skylark as a language, and for exposing more and more functionality available in Bazel internally to Skylark extensions. These requests originate both within and outside the Bazel team. As their number grows (and we expect them to grow more and more over time), addressing those requests meets several challenges:
We need to keep Skylark as a language (and a set of associated APIs/libraries) concise and consistent, easy to learn and use, and documented.
Any APIs or solutions we adopt will be painful to change down the road, so the more consistent, orthogonal, and open to future extensions they are, the less pain we and our users will encounter.
It is difficult for engineers - both within the team and outside - to approach making changes to Skylark. As people attempt to do so, they experience a lot of friction: patches get written and the discussion starts where reviewers and the author attempt to solve Skylark API issues, code design issues, implementation issues, compatibility issues and so on and so forth all in one code review thread. The result is friction and frustration, and the quality of the end result is not guaranteed.
This document proposes an informal but orderly and well-defined process for Skylark language changes to address the above challenges.
Facilitate healthy growth of Skylark as a language
Ensure that Skylark the language has a clear set of experts caring for its development
Reduce friction for engineers exposing APIs to Skylark or proposing new Skylark features
Changes to Skylark, both the language and the exposed APIs, are evaluated by the Skylark Reviewers Panel.
The author of the proposed change sends the design document to the [email@example.com] mailing list with a subject containing "SKYLARK DESIGN REVIEW"
Design doc can be either of:
The design doc should include:
A model example design doc (although that is probably an overkill).
Skylark Reviewers respond to a document within 2 business days
Skylark Reviewers are responsible for bringing in subject-matter experts as needed (for example, a change involving exposing a certain provider from cc_library rule should be reviewed by C++ rules expert as well)
Skylark Reviewers facilitate the discussion and aim to reach a "looks good/does not look good" decision within 10 business days.
Skylark Reviewers operate by consensus.