The RFC (Request For Comments) process is intended to provide a consistent procedure for all major decisions affecting Paketo Buildpacks.
A Request For Comments starts with a document of proposed changes to Paketo Buildpack(s). All major decisions must start with an RFC proposal. Once an RFC has been proposed, anyone may ask questions, provide constructive feedback, and discuss trade-offs. But only the steering committee or team maintainers will be able to ratify an RFC for project-level and team-level RFCs, respectively.
Many changes, including bug fixes and documentation improvement can be implemented and reviewed by the normal Github pull request process. For substantial changes, we ask that an RFC be proposed as a method to achieve consensus within the Paketo community.
If the change is made as a pull request, but is considered substantial or more clarity/discussion is warranted, the issue will be closed and the author will be requested to open new issues.
You'll need to follow this process for anything considered "substantial". What constitutes a "substantial" change may include the following but is not limited to:
For clarification about where a change fits into this model, please review previous RFCs, or reach out on the official Paketo Slack.
If the changes proposed in the RFC are scoped to a specific sub-team, please open a team-level RFC. If the proposal will affect the multiple teams or the entire project please open a project-level RFC.
Examples of project-level RFCs:
BP_LOG_LEVEL)Examples of teams-level RFCs:
To get an RFC implemented, first the RFC needs to be merged into the rfcs repo. Once an RFC is merged, it's considered 'accepted' and may be implemented in the project. These steps will get an RFC to be considered:
Once a pull request is opened, the RFC is now in development and the following will happen:
It will be labeled as general or specific to a set of teams.
Voting members are defined as follows:
The effect of an RFC referenced above can be defined as follows:
The community will discuss as much as possible in the RFC pull request directly. All discussion should be posted on the PR thread. When an RFC is deemed "ready"
A Voting member may propose a "motion for final comment period (FCP)" along with a disposition of the outcome (merge, close, or postpone). Before entering FCP, supermajority of the voting members must sign off.
This step is taken when enough discussion of the trade-offs have taken place and the team(s) is in a position to make a decision.
The FCP will last 7 days. If there's unanimous agreement among the team(s), then the FCP can close early.
Acceptance requires a supermajority of binding votes by voting members in favor. The voting options are the following: Affirmative, Negative, and Abstention. Non-binding votes are of course welcome. Supermajority means 2/3 or greater.
If no substantial new arguments or ideas are raised, the FCP will follow the outcome decided. If there are substantial new arguments, then the RFC will go back into development.
Once an RFC has been accepted, the maintainer who merges the pull request should do the following:
0000 with the assigned ID.Once an RFC is accepted, maintainers agree to merge a corresponding PR implementing the described changes, provided it passes a standard code review. It is not a guarantee of implementation, nor does it obligate a team to implement the requested changes.
When the changes described in an RFC have been implemented and merged into the relevant repository (and thus, due to be released), the corresponding RFC will be moved from accepted/ to implemented/. If you'd like to implement an accepted RFC, please make a PR in the appropriate repo and mention the RFC in the PR. Feel free to do this even for work-in-progress code! If you'd like to track progress on an RFC implementation, check if an issue has been opened that requests the RFC be implemented. If not, feel free to open one.