Want to try fastn for your company's website?

Explore

Get Started

undefined

3: Variable Interpolation

fastn-package crate 🚧

ftd p1 grammar

RFC-1: The RFC Process

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the language, fasnt cli and tha standard libraries, so that all stakeholders can be confident about the direction the language is evolving in.

📝

This is a RFC document

This document exists to describe a proposal for enhancing the fastn language. This is a Request For Comment. Please share your comments by posting them in the pull request for this RFC if this RFC is not merged yet. If the RFC is merged, you can post comment on our official Discord, or open a discussion on Github.

Learn about our RFC process. View all active RFCs. WIP RFCs, and RFCs awaiting initial comments can be found on Github, as Pull Requests, with label rfc.

Status

accepted

Motivation

Note: This RFC is heavly inspired by and borrows from the Rust's RFC process document.

The freewheeling way that we add new features to fastn has been good for early development, but for fastn to become a mature platform we need to develop some more self-discipline when it comes to changing the system. This is a proposal for a more principled RFC process to make it a more integral part of the overall development process, and one that is followed consistently to introduce features to fastn.

Detailed Design

Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the fastn community and the core team.

When you need to follow this process

You need to follow this process if you intend to make "substantial" changes to the fastn distribution. What constitutes a "substantial" change is evolving based on community norms, but may include the following.

Any semantic or syntactic change to the language that is not a bugfix.
Removing language features.
Changes to the interface between the compiler, CLI and libraries
Additions to std

Some changes do not require an RFC:

Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning".
Additions that strictly improve objective, numerical quality criteria (warning removal, speedup, better platform coverage, more parallelism, trap more errors, etc.)
Additions only likely to be noticed by other developers-of-fastn, invisible to users-of-fastn.
If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.

What the process is

In short, to get a major feature added to fastn, one must first get the RFC merged in fastn.com repo. At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into fastn.

Fork the fastn.com repo: https://github.com/fastn-stack/fastn.com
Copy rfcs/0000-template.ftd to `rfcs/0000-my-feature.ftd (where 'my-feature' is descriptive. don't assign an RFC number yet).
Fill in the RFC
Submit a pull request. The pull request is the time to get review of the design from the larger community.
Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments.
Eventually, somebody on the core team will either accept the RFC by merging the pull request, at which point the RFC is 'active', or reject it by closing the pull request.

Whomever merges the RFC should do the following:

Assign an id, by incrementing the RFC number of the last merged RFC.
Add the file in the rfcs/ directory.
Fill in the remaining metadata in the RFC header, including links for the original pull request(s).
Add an entry in the Active RFC List of the rfcs/index.ftd
Commit everything.
Once an RFC becomes active then authors may implement it and submit the feature as a pull request to the Rust repo. An 'active' is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it.

Modifications to active RFC's can be done in followup PR's. An RFC that makes it through the entire process to implementation is considered 'complete' and is removed from the Active RFC List; an RFC that fails after becoming active is 'inactive' and moves to the 'inactive' folder.

Teaching Notes

We have to only teach developers-of-fastn about this new process, so teaching impact of this RFC is minimal. Even for developers-of-fastn, given fastn is implemented in Rust, so all developers of fastn are familiar with Rust, and also given we have heavily borrewed from Rust's RFC process, teaching this should not pose a challenge in terms of new concepts.

People will be proposing ideas via Github Issues, and we will have to direct them to fastn.com/rfcs/.

Alternatives

Retain the current informal RFC process. The newly proposed RFC process is designed to improve over the informal process in the following ways:

Discourage unactionable or vague RFCs
Ensure that all serious RFCs are considered equally
Give confidence to those with a stake in Rust's development that they understand why new features are being merged
As an alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Python's PEP process for inspiration.

Unresolved Questions

Does this RFC strike a favorable balance between formality and agility?
Does this RFC successfully address the aforementioned issues with the current informal RFC process?
Should we retain rejected RFCs in the archive?