Welcome to the AlmaLinux Engineering Steering Committee's (ALESCo) RFC repository. This repository is the central place for proposing, discussing, and documenting significant changes to AlmaLinux.
- Introduction
- When to Submit an RFC
- RFC Process Overview
- How to Submit an RFC
- RFC Lifecycle
- RFC Template
- Contributing Guidelines
- License
- Contact
- Additional Notes
- Frequently Asked Questions
The AlmaLinux RFC process is a formal way to propose significant changes, enhancements, or new features to the AlmaLinux project. It aims to foster open collaboration, transparency, and comprehensive documentation of decisions made by ALESCo and the broader community.
Consider submitting an RFC if you are proposing:
- Major changes to the operating system or its components.
- EX, Changing the default desktop environment
- New features or functionalities.
- EX, Adding SPICE support
- Any change that requires community consensus or impacts a large portion of the project.
- EX, Replacing the use of OpenSSL with LibreSSL
For minor issues like bug fixes or small enhancements, please use the appropriate AlmaLinux issue tracker or contribute directly to the relevant repository.
- Proposal Drafting: Author drafts the RFC using the provided template.
- Submission: RFC is submitted as a pull request to this repository.
- Accepted for Discussion: Community and ALESCo members provide feedback, with active revision of the proposal expected. As part of this step, ALESCo will also send an email to the AlmaLinux OS Foundation board with a link to the RFC pull request, indicating whether or not the board input is expected to be a blocker for the vote.
- Final Comment Period (FCP): A last call for comments before the decision. The board will also get a notification of an impending vote here, in case they would like to provide input.
- Decision Making: ALESCo votes on the RFC.
- Implementation: Accepted RFCs are merged and scheduled for implementation.
In very rare circumstances the AlmaLinux OS Foundation Board will be required to provide input in things ALESCo is deciding on. In some cases the board may be required to approve a change, and in some cases they can abstain from an official position. However, as part of their oversight in the project, input will be required before a vote can be held in the following situations.
- Input from the board will be a blocking stakeholder before ALESCo can vote on RFCs that...
- involve a change to trademarks
- involve a significant increase in needed resources
- involve a new or expanded partnership of some kind
To ensure the board provides input, the current board chair will be added as a required reviewer to the pull request. A representative from the board will also attend the meeting where the vote is taking place.
As a note - this is not a veto right, but is only to ensure that the board has been able to advise ALESCo on any potential impacts of changes.
- Fork the Repository: Click the "Fork" button at the top-right corner of this page to create your own copy of the repository.
- Create a New Branch: In your forked repository, create a new branch for your RFC:
git checkout -b rfc-title-of-your-proposal- Copy the Template: Copy the
0000-template.mdtorfcs/XXXX-title-of-your-proposal.md, replacingXXXXwith the next available RFC number (use0000for the initial PR; the number will be assigned during the process). - Write the RFC: Fill out the template with your proposal. Be thorough and clear.
- Submit a Pull Request: Push your branch to your fork and submit a pull request to this repository's main branch.
- Engage in Discussion: Monitor the pull request comments and participate in the discussion, making revisions as necessary.
The RFC process has the following states:
- Submitted: The RFC is submitted and requires an initial review for formatting, etc. Once it has been confirmed to meet the needs of the RFC process, the "accepted for discussion" tag will be added.
- Open for discussion: The RFC is under initial and active discussion and may undergo several revisions.
- FCP (Final Comment Period): ALESCo announces an FCP, signaling that the decision will be made soon. When the RFC enters this stage, the "vote at next meeting" tag will be added.
- Accepted: The RFC is approved and merged.
- Rejected: The RFC is not approved; reasons are documented.
- Withdrawn: The RFC is withdrawn by the author.
- Superseded: The RFC is replaced by a new proposal.
The RFC template can be found here. Please use this template for all new RFCs.
- Clarity: Write clear and concise proposals.
- Respect: Be respectful in discussions; adhere to the Code of Conduct.
- Responsiveness: Be available to answer questions and provide clarifications during the review process.
- Documentation: Update your RFC based on feedback received.
All participants are expected to uphold the AlmaLinux Code of Conduct.
Which amounts to: be nice, be respectful, and be nerdy.
By contributing to this repository, you agree that your contributions will be licensed under the Creative Commons Attribution Share Alike 4.0 International (CC-BY-SA-4.0`).
- Chat: AlmaLinux Mattermost
- Forums: AlmaLinux Community Forums
- Mailing List: [email protected]
- Assigning RFC Numbers: RFC numbers are assigned by the repository maintainers when the pull request is labeled as "accepted for discussion." Use 0000 as the number in your initial submission.
- File Naming Convention: Name your RFC file as XXXX-title-of-your-proposal.md, where XXXX is the assigned RFC number.
- Directory Structure: All RFC files should be placed in the rfcs/ directory.
- Updating RFC Status: The status of the RFC should be updated in the document header as it progresses through the lifecycle stages.
The standard review period is two weeks, but it can be extended if necessary to ensure adequate discussion.
The final decision is made by ALESCo, taking into account community feedback and the overall impact on the project. There is no obligation for the RFC to be accepted by the committee.
It is expected that contributors will be responsible for all or part of the work implementing the RFC.
Yes, you can withdraw your RFC at any point before it is accepted by closing the pull request and stating your intention.
