FLIPs (Flow Improvement Proposals)

The purpose of a FLIP is to engage the Flow community in development by leveraging the collective ideas, insights, and experience of contributors and experts while also communicating design changes broadly.

Each FLIP describes a protocol change, governance change, or application level standard meant to improve the Flow protocol or ecosystem. Proposals can be submitted by anyone, and should follow the process below, as well as the [TDB] style guide for each category.

This repository will hold FLIPs to separate them from the onflow/flow repository. This is currently a work in progress, and legacy FLIPs are all in the flips directory. These FLIPs will be moved into the appropriate sub-directories over time.

Application

Application FLIPs are standards for applications built on top of FLOW. This could be token standards, contract interface standards, common design patterns that can benefit from social consensus etc. Application standards should not create protocol changes in themselves, and if they rely on any new protocol features that feature should be written up in its own protocol flip.

Governance

Governance FLIPs are proposals to take governance actions on the network, for instance changing staking rules, admitting new node operators to the allowlist, adjusting fees, or taking various actions with the the service account.

Protocol

Protocol FLIPs affect the core Flow protocol. This may include items such as: new algorithms which are required for any flow client to work on the network, payload API changes, cryptographic methods, etc.

Cadence changes will currently fall under Protocol FLIPs because they are tightly coupled with the FVM.

Current FLIPs

Process

Who is involved?

Everyone is welcome to propose and provide feedback on a FLIP.

A FLIP author writes a FLIP and is committed to championing it through the process.

A FLIP sponsor is any maintainer who sponsors the FLIP and will shepherd it through the FLIP review process.

A review committee is a group of maintainers who are responsible for the strategic direction of components, subcomponents, and public APIs. They have the responsibility to accept or reject the adoption of the FLIP via a community vote.

What is a FLIP?

A FLIP is a document that describes a requirement and the proposed changes that will solve it. Specifically, the FLIP will:

be formatted according to the FLIP template
be submitted as a pull request
be subject to discussion and a review meeting prior to acceptance

FLIP process

Before submitting a new FLIP, check for prior proposals, the Flow community forum and ask in the Discord server. The idea may have been proposed before or may be in active discussion. Consider contributing or giving feedback to existing proposals.

If a new proposal is appropriate, propose a rough sketch of the idea in the forum Flow community forum and engage in discussion with the community, project contributors, and maintainers, to get early feedback. Continue to expand the rough sketch into a draft using the FLIP template and further refine the proposal on the forums.

After writing the FLIP draft, gather feedback from project contributors and maintainers before submitting it.

Once the FLIP is ready for review:

(Optional) Recruit a sponsor from the maintainers of the project for which your FLIP concerns.

You are not required to recruit a sponsor; this step is entirely optional. However, a sponsor acts as a valuable resource who can streamline the review process and increase the likelihood of your FLIP being accepted.

If you do recruit a sponsor, identify them in the FLIP before posting the PR in step 2.
Submit your FLIP as a pull request to this repository (onflow/flips).

Name your FLIP file using the template YYYYMMDD-descriptive-name.md, where YYYYMMDD is the date of submission, and ‘descriptive-name’ relates to the title of your FLIP. For instance, if your FLIP is titled "Event Streaming API", you might use the filename 20180531-event-streaming-api.md. If you have images or other auxiliary files, create a directory of the form YYYYMMDD-descriptive-name in which to store those files.

Include the header table and the contents of the Objective section in the comment of your pull request, using Markdown. Include a mention of any of the GitHub handles of co-authors, reviewers and sponsors.

At the top of the PR identify how long the comment period will be. This should be a minimum of two weeks from posting the PR.
Send a message to the #developers channel on Discord with a brief description, and a link to the PR and a request for review.
The sponsor may request a review committee meeting after sufficient discussion has taken place. This meeting will include the FLIP author, core contributors and interested community members. If discussion is lively, wait until it has settled before going to review. The goal of the review meeting is to resolve minor issues; consensus should be reached on major issues beforehand.
The meeting may approve the FLIP, reject it, or require changes before it can be considered again. FLIPs will be merged into this repository (onflow/flips) with the outcome of the review process (approval, rejection).
Implementations of a successful FLIP should reference it in their documentation, and work with the sponsor to successfully land the code.

While implementation code is not necessary to start the FLIP process, its existence in full or part may help the design discussion.

If in any doubt about this process, feel free to ask on Discord, the community forum, or file an issue in this repository (onflow/flow).

Proposal states

Proposed: The FLIP has been proposed and is awaiting review.
Rejected: The FLIP has been reviewed and been rejected.
Accepted: The FLIP has been accepted and is either awaiting implementation or is actively being implemented.
Implemented (in VERSION): The FLIP has been implemented.

Community members

As the purpose of FLIPs is to ensure the community is well represented and served by new changes to Flow, it is the responsibility of community members to participate in reviewing FLIPs where they have an interest in the outcome.

Community members should:

provide feedback as soon as possible to allow adequate time for consideration
read FLIPs thoroughly before providing feedback
be civil and constructive (see Code of Conduct)

Review committees

The constitution of a review committee may change according to the particular governance style and leadership of each project. For the core Flow Protocol, the committee will exist of contributors to Flow who have expertise in the domain area concerned.

Review committees must:

ensure that substantive items of public feedback have been accounted for
add their meeting notes as comments to the PR
provide reasons for their decisions

If a review committee requires changes before acceptance, it is the responsibility of the sponsor to ensure these are made and seek subsequent approval from the committee members.

FLIP sponsors

A sponsor is a Flow maintainer responsible for ensuring the best possible outcome of the FLIP process.

In particular this includes:

advocating for the proposed design
guiding the FLIP to adhere to existing design and style conventions
guiding the review committee to come to a productive consensus
if the FLIP is approved and moves to implementation:
- ensuring proposed implementation adheres to the design
- liaison with appropriate parties to successfully land implementation

Keeping the bar high

While we encourage and celebrate every contributor, the bar for FLIP acceptance should be kept intentionally high. A design may be rejected or need significant revision at any one of these stages:

initial design conversations on the Flow community forum or Discord server
failure to recruit a sponsor
critical objections during the feedback phase
failure to achieve consensus during the design review
concerns raised during implementation (e.g., inability to achieve backwards compatibility, concerns about maintenance appearing once a partial implementation is available)

If this process is functioning well, FLIPs are expected to fail in the earlier, rather than later, stages.

FLIP Template

Use the template from GitHub, being sure to follow the naming conventions described above.

FLIP Evaluation

FLIPs should be evaluated for their impact on the three pillars of Flow. These are:

Community - consider how the FLIP will impact the ability for others to participate in the ongoing design and operation of the Flow network and the applications which depend on it.
Empowerment - consider how the FLIP will improve the economic opportunity for creators, contributors and participants in the community. The FLIP should result in a net positive on the marginal benefits and costs to all the impacted individuals (who choose to register their preference/vote on an issue).
Reliability - and finally, think about how the FLIP will impact the consistency, observability, verifiability, and overall performance of the Flow network for its users.

Acknowledgements

Note: the FLIP process and guidelines were adapted from the wonderful RFC process created by the TensorFlow community. ❤️

This work, "Flow Improvement Proposals", is a derivative of "The TensorFlow RFC process" by The TensorFlow Authors, used under CC BY 4.0.

bjartek/flips