f802281c5a
We currently have a set of aspirational linting rules in the project's golangci-lint configuration, but this codebase was derived from a much older codebase that was not written under those lint rules and so we made the pragmatic decision that only code that has changed since the addition of the lint rules is subjected to those lint rules. That approach aims to make the compromise of encouraging us to gradually improve code "while we're in the area" working on other changes, while avoiding the need for a huge retrofit of existing code. However, that compromise seems to be less appropriate for the subset of linting rules related to code complexity in particular. That category of rules typically imposes some arbitrary limit on a qualitative metric that the linting tool can measure. These particular rules therefore have a relatively broad scope and tend to require very disruptive changes to existing code in order to resolve them. This proposal aims to find a pragmatic path that will lead to a codebase that _does_ conform to the complexity lint rules in the long run, but to treat those improvements as a separate project in their own right rather than as something we aim to gradually improve as part of other work. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The OpenTofu RFCs
This folder contains Request For Comment (RFC) documents that have been discussed, reviewed, and accepted. They represent a proposal of changes to one or more of the repositories in the OpenTofu organization.
RFCs are primarily created by the OpenTofu Community in response to one or more GitHub issues that require a more in-depth discussion than the GitHub Issue process can provide. They are organized by date to help show the progression of concepts over time.
Authoring an RFC
When an Issue is given the needs-rfc label, any community member may propose an RFC by following these steps:
- Copy the yyyymmdd-template.md to
./rfc/${isodate}-${rfc title}.mdon a branch in their fork of the OpenTofu Repository - Edit the newly created Markdown file and fill in the template fields
- Submit a Pull Request in the OpenTofu Repository, linked to the open issue(s)
Note
It's ok to file an incomplete RFC. Please submit it as a draft pull request to get early feedback.
Once an RFC is submitted, community members discuss the RFC in detail until all open questions are resolved
To Accept an RFC, the majority of the OpenTofu Core Team must approve the Pull Request. If a consensus is not reached, the Pull Request is closed and the Core Team may ask for a new RFC or close the original issue entirely.
Once an RFC is Accepted and Merged, the Core Team creates issues in the relevant repositories to track the work required to implement the RFC.
Amending an RFC
RFCs are not set in stone, Approval signifies that an initial consensus has been reached and work can be started. If you realize that parts of the implementation won't work, feel free to amend the RFC in a subsequent PR. Doing so will serve as an important point of discussion if something doesn't go according to plan.