| status | flip | authors | sponsor | updated |
|---|---|---|---|---|
draft |
NNN (set to the issue number) |
My Name (me@example.org), AN Other (you@example.org) |
AN Expert (core-contributor@example.org) |
YYYY-MM-DD |
What are we doing and why? What problem will this solve? What are the goals and non-goals? This is your executive summary; keep it short, elaborate below.
Why is this a valuable problem to solve? What background information is needed to show how this design addresses the problem?
Which users are affected by the problem? Why is it a problem? What data supports this? What related work exists?
How will users (or other contributors) benefit from this work? What would be the headline in the release notes or blog post?
This is the meat of the document where you explain your proposal. If you have multiple alternatives, be sure to use sub-sections for better separation of the idea, and list pros/cons to each approach. If there are alternatives that you have eliminated, you should also list those here, and explain why you believe your chosen approach is superior.
Make sure you’ve thought through and addressed the following sections. If a section is not relevant to your specific proposal, please explain why, e.g. your FLIP addresses a convention or process, not an API.
Why should this not be done? What negative impact does it have?
- Make sure to discuss the relative merits of alternatives to your proposal.
- Do you expect any (speed / memory)? How will you confirm?
- There should be microbenchmarks. Are there?
- There should be end-to-end tests and benchmarks. If there are not (since this is still a design), how will you track that these will be created?
- Dependencies: does this proposal add any new dependencies to Flow?
- Dependent projects: are there other areas of Flow or things that use Flow (Access API, Wallets, SDKs, etc.) that this affects? How have you identified these dependencies and are you sure they are complete? If there are dependencies, how are you managing those changes?
- Do you expect changes to binary size / build time / test times?
- Who will maintain this code? Is this code in its own buildable unit? Can this code be tested in its own? Is visibility suitably restricted to only a small API surface for others to use?
- Does this proposal change best practices for some aspect of using/developing Flow? How will these changes be communicated/enforced?
- If design changes existing API or creates new ones, the design owner should create
end-to-end examples (ideally, a tutorial) which reflects how new feature will be used.
Some things to consider related to the tutorial:
- It should show the usage of the new feature in an end to end example (i.e. from the browser to the execution node). Many new features have unexpected effects in parts far away from the place of change that can be found by running through an end-to-end example.
- This should be written as if it is documentation of the new feature, i.e., consumable by a user, not a Flow contributor.
- The code does not need to work (since the feature is not implemented yet) but the expectation is that the code does work before the feature can be merged.
- Does the design conform to the backwards & forwards compatibility requirements?
- How will this proposal interact with other parts of the Flow Ecosystem?
- How will it work with FCL?
- How will it work with the Emulator?
- How will it work with existing Flow SDKs?
- What are the user-facing changes? How will this feature be rolled out?
What related issues do you consider out of scope for this proposal, but could be addressed independently in the future?
Does the proposed idea/feature exist in other systems and what experience has their community had?
This section is intended to encourage you as an author to think about the lessons learned from other projects and provide readers of the proposal with a fuller picture.
It's fine if there is no prior art; your ideas are interesting regardless of whether or not they are based on existing work.
State where you would want the community discussion to take place (choosing between the PR itself, or forum post) Seed with open questions you require feedback on from the FLIP process. What parts of the design still need to be defined?