|X||Standard, Contributions, and Process Guidelines for the Factom® Protocol||Draft||Meta||Devon Katz <email@example.com>||20181124|
FIP-X is the initial standard that describes the core framework, conventions, contribution guidelines, and ecosystem of FIP standards.
What Is A FIP?
FIP is a formal proposal and process for accepting and integrating new standards into the Factom® Protocol standard collection.
Why Are They Important?
FIP provides an open forum for the community to collaborate on and accept new standards into the Factom® Protocol. The Factom® Protocol is completely open source, and we rely on our community and standing parties to keep us pointed in the right direction.
To submit your standard, fork this repo and then submit a pull request to have it reviewed and included for evaluation by the community.
Standards that define the basic building blocks, technology, and conventions that govern Factom® Protocol standards.
Apps & libraries
Standards that define application level functionality on top of the Factom® Protocol.
Standards that define API architecture, conventions, and specs.
Standards about FIP standards, processes, etc.
Work In Progress (WIP)
The standard's information is sufficient to be reviewed by the community. This is essentially an "Intent to submit" a FIP standard. The community member(s) submit a formatted pull request containing the preliminary version of the proposed standard.
- If reviewed and denied, the proposal may be revised and improved unless it is explicitly rejected
- If reviewed and approved it is assigned a FIP number and other metadata. The proposal moves on to drafting.
The standard is in the progress of being revised. Follow up pull requests will be accepted to revise the standard until it is ready to go through the last call process (explained below).
The standard is open to final evaluation by the community and general public.
- If the standard requires further changes, it reverts to drafting again.
- If the proposal is approved and it is a Core, or Interface FIP standard then it will move onto accepted.
- If the proposal is approved and it is an information standard then it will move onto final.
As FIP is young, currently no maximum timeline is set for this status.
The go ahead for development is given and the standard is finalized. Implementation in core, clients and APIs can occur. When the community reaches consensus on the implementation success, the status will change to final.
The proposal has been finalized and accepted by the community. The proposal is adorned with the final official prefix Factom-Protocol, replacing the former FIP prefix. Errata may be formally submitted following this stage if required.
For each new FIP that comes in, an editor does the following:
- Read the FIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.
- The title should accurately describe the content.
- Check the FIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style.
If the FIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the FIP is ready for the repository, the FIP editor will:
- Assign a FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP).
- Merge the corresponding pull request.
- Send a message back to the FIP author with the next step.
Many FIPs are written and maintained by developers with write access to the codebases of the Factom® Protocol or 3rd party applications. The FIP editors monitor FIP changes, and correct any structure, grammar, spelling, or markup mistakes they see.
A FIP Template is supplied to begin writing your standard.
An informational header containing metadata about the FIP being submitted, like so:
|N||Standard Name||Status||Category||Author Name <firstname.lastname@example.org>||7-23-2018|
Once accepted as a draft an editor will assign an official FIP number.
"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.
Clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright. What motivated the design and why were particular design decisions made?
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Factom® Protocol.
The implementations must be completed before any FIP is given status "Final", but it does not need to be completed before the FIP is given status "Accepted". While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of standard details.
The standard must have a copyright section that waives rights according to CC0. Please note that this is only applicable for the proposal itself:
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Inheritance & Dependencies
Factom® Protocol standards can extend and inherit functionality and rules from others. The
extends <FIP #> Keyword and Tag denotes feature inheritance on a feature
by feature basis. The author of the FIP must explain how and what is being
inherited, and if there are any changes being made. It is also possible to depend on another FIP. The
depends-on <FIP #> Keyword and Tag denotes dependency on a feature
by feature basis.
Copyright and related rights waived via CC0.