Those wishing to submit an RFC should first should propose their idea to the relevant communities and then submit a new RFC as outlined in the [RFC Guidelines & Process][0000].
Those wishing to submit a proposal should first should bring their idea to the relevant communities and then submit a new RFC as outlined in the [RFC Guidelines & Process][0000].
Discussion relevant to a **pending** draft should, whenever possible, take the form of Gitub issue tickets. Github tickets should reference the RFC and/or pull requests to help ensure that all discussion is captured.
Discussion relevant to a pending draft should, whenever possible, take the form of Gitub issue tickets. Github tickets should reference the proposal and/or pull requests to help ensure that all discussion is captured.
The Internet Freedom Alliance Working Group (IFA-WG) is an organization designed to promote collaboration between projects that empower online civil rights. IFA-RFCs are modeled after IETF RFCs and seek to create shared standards that are used by multiple projects, reducing duplicative work and combating insular decision making.
The Internet Freedom Alliance Working Group (IFA-WG) is an organization designed to promote collaboration between projects that empower online civil rights. IFA proposals are modeled after IETF RFCs and seek to create shared standards that are used by multiple projects, reducing duplicative work and combating insular decision making.
Types
=====
There are three kinds of RFCs:
There are three kinds of proposals:
* A Standards Track RFC describes standards and changes to existing standards that impact multiple implementations such as DNS records for decentralized TLDs.
* An Informational RFC provides general guidelines or information to the community, but does not propose a new feature. Informational RFCs do not necessarily represent community consensus or recommendation, so users and implementors are free to ignore Informational RFCs or follow their advice.
* A Process RFC describes a process surrounding the RFC creation process. Unlike Informational RFCs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools used to format RFCs.
* A Standards Track Proposal describes new standards and changes to existing standards that impact multiple implementations, such as DNS records for decentralized TLDs.
* An Informational Proposal provides general guidelines or information to the community, but does not propose a new feature. Informational Proposals do not necessarily represent community consensus or recommendation, so users and implementors are free to ignore Informational Proposals or follow their advice.
* A Process Proposal describes a process surrounding the proposal creation process. Unlike Informational Proposals, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools used to format proposals.
RFC Workflow
============
Proposal Workflow
=================
Each RFC must have a champion – someone who writes the RFC and attempts to build community consensus around the idea. A champion should publicly vet the idea before going as far as writing a RFC.
Each proposal must have a champion – someone who writes the proposal and attempts to build community consensus around the idea. A champion should publicly vet the idea before going as far as writing a proposal.
An RFC champion should begin writing their RFC by forking the IFA-WG RFC repo and following the formatting instructions found in this RFC.
An proposal champion should begin writing their proposal by forking the IFA-WG proposals repo and following the formatting instructions found in this proposal (IFA-0).
When complete, assign the RFC a number (usually by incrementing form the most recent RFC), update the listing of active RFCs in the `README.md` file, perform the post-professing steps outlined in `README.md`, and submit a pull request.
When complete, assign the proposal a number (usually by incrementing form the most recent proposal), update the listing of active proposals in the `README.md` file, perform the post-professing steps outlined in `README.md`, and submit a pull request.
Status
------
The possible paths for a Draft RFC are as follows:
The possible paths for a Draft proposals are as follows:
The arrow diagrams are not absolutes, a Withdrawn or Rejected RFC *can* regain Draft status, but this is fairly rare. Statuses that are grey indicate that the RFC will be removed from the list of current RFCs.
The arrow diagrams are not absolutes, a Withdrawn or Rejected proposal *can* regain Draft status, but this is very rare. Statuses that are grey indicate that the proposal will be removed from the list of current proposals.
<dl>
<dt>Draft</dt>
<dd>If an RFC is not rejected outright, it attains draft status and the reference number becomes permanently reserved for that RFC. A Draft RFC can be updated using pull requests. The Git revision history serves as the historical record of the RFC.</dd>
<dd>If a proposal is not rejected outright, it attains Draft status and the reference number becomes permanently reserved for that proposal. A Draft proposal can be updated using pull requests. The Git revision history serves as the historical record of the proposal.</dd>
<dt>Deferred</dt>
<dd>When a Draft RFC lacks consistent progress it becomes deferred. Deferred is not necessarily a bad thing, it may be that other standards are being worked on first.</dd>
<dd>When a Draft proposal lacks consistent progress it becomes deferred. Deferred is not necessarily a bad thing, it may be that other standards are being worked on first.</dd>
<dt>Accepted</dt>
<dd>Rough consensus is reached to adopt a Draft Standards Track RFC and work on a reference implementation is in progress. Note that in some cases it may be prudent to complete a reference implementation when the RFC is still a draft. Informational and Process RFCs that intend to be updated (such as this RFC) retain accepted status.</dd>
<dd>Rough consensus is reached to adopt a Draft Standards Track Proposal and work on a reference implementation is in progress. Note that in some cases it may be prudent to complete a reference implementation when the proposal is still a Draft. Informational and Process Proposals that intend to be updated in the future (such as this proposal) retain Accepted status.</dd>
<dt>Final</dt>
<dd>In the case of Standards Track RFCs, Final status indicates that the reference implementation is complete. Informational and Process RFCs that are *not* intended to be updated and should be replaced instead of updated are marked as final.</dd>
<dd>In the case of Standards Track Proposals, Final status indicates that the reference implementation is complete. Informational and Process Proposals that are *not* intended to be updated should be marked as Final and Superseded by new proposals.</dd>
<dt>Rejected</dt>
<dd>Rough consensus to reject an RFC can come about as a response to a Draft RFC or after an RFC has been Accepted but rejected after attempting to implement it. A section summarizing the reason for rejection and links to relevant discussions **must** be appended to the RFC.</dd>
<dd>Rough consensus to reject a proposal can come about as a response to a Draft proposal or after a proposal was Accepted but then Rejected after attempting to implement it. A section summarizing the reason for rejection and links to relevant discussions **must** be appended to the proposal.</dd>
<dt>Withdrawn</dt>
<dd>Status of when a Draft has been withdrawn by the author. Authors/editors **should** append a section summarizing the reason for withdrawal and links to relevant discussions.</dd>
<dd>Status of when a Draft proposal has been withdrawn by the author. Authors/editors **should** append a section summarizing the reason for withdrawal and links to relevant discussions.</dd>
<dt>Superseded</dt>
<dd>When an Accepted or Final RFC has been replaced by another RFC. Editors **must** link to new RFC at the top of the document.</dd>
<dd>When an Accepted or Final proposal has been replaced by another proposal. Editors **must** link to new proposal in the header of the document (as outlined in the [Proposal Header](#proposal-header) section).</dd>
</dl>
Rejection
---------
An RFC editor can reject an RFC without discussion for any number of reasons, including:
An editor can reject a proposal without wider discussion for any number of reasons, including:
* Being too broad.
* Not relying on existing standards/duplicating effort.
@ -98,47 +97,47 @@ An RFC editor can reject an RFC without discussion for any number of reasons, in
* Not providing proper motivation.
* Not having consulted relevant communities.
Note that IFA-RFCs are designed to facilitate collaborate *across* communities, so the consultation requirement is fairly shallow.
Note that IFA proposals are designed to facilitate collaborate *across* communities, so the consultation requirement is fairly shallow.
Discussion
----------
Prior to submitting an RFC for Draft status, the primary means of communication for the relevant communities should be used. However, Draft RFC's **should** attempt to focus discussion through issue tickets on the IFA-RFC repository. Issue tickets **must** link to the RFC file and **should** link to relevant external discussions.
Prior to submitting a proposal for Draft status, the primary means of communication for the relevant communities should be used. However, Draft proposals **should** attempt to funnel discussion into issue tickets on the IFA proposal repository. Issue tickets **must** link/reference the proposal and **should** link to relevant external discussions.
Content
=======
RFCs are designed to codify standards, either proposed or existing. Each RFC should strive to embody a single key proposal or new idea. Whenever possible, proposals should defer and link to existing standards, even when those standards are external (such as an IETF RFC).
Proposals are designed to codify standards, either proposed or existing. Each proposal should strive to embody a single key proposal or new idea. Whenever possible, proposals should defer and link to existing standards, even when those standards are external (such as an IETF RFC).
Sections
--------
Each RFC*should* contain the following sections when appropriate:
Each proposal*should* contain the following sections when appropriate:
* Header -- RFC 822 style headers containing meta-data about the RFC, including the RFC number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
* Header -- RFC 822 style headers containing meta-data about the proposal, including the proposal number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
* Abstract -- a short (~200 word) description of the technical issue being addressed.
* Specification -- The technical specification should describe the syntax and semantics. The specification should be detailed enough to allow competing, interoperable implementations.
* Motivation -- The motivation is critical for RFC that want to alter existing standards. It should clearly explain why the existing specification is inadequate to address the problem that the RFC solves. RFC submissions without sufficient motivation may be rejected outright.
* Motivation -- The motivation is critical for a proposal that wants to alter existing standards. It should clearly explain why the existing specification is inadequate to address the problem that the new proposal solves. Proposals without sufficient motivation may be rejected without being assigned draft status.
* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
* Backwards Compatibility -- All RFCs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The RFC must explain how the author proposes to deal with these incompatibilities. RFC submissions without a sufficient backwards compatibility treatise may be rejected outright.
* Backwards Compatibility -- All standards that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The standard must explain how the author proposes to deal with these incompatibilities. Proposals without a sufficient backwards compatibility treatise may be rejected without being assigned draft status.
* Reference Implementation -- The reference implementation must be completed before any RFC is given status "Final", but it need not be completed before the RFC is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
* Reference Implementation -- A reference implementation must be completed before any standard is given status "Final", but it need not be completed before the standard is accepted. It is usually better to finish the specification and rationale first and reach consensus on it before writing code.
* The final implementation must include test code and documentation.
Format
------
* NFCs should be written in [Github flavored markdown][GHMarkdown] and allowed inline HTML.
* Proposals should be written in [Github flavored markdown][GHMarkdown] and allowed inline HTML.
* Links should use the `[content][ref]` format and references should appear at the end of the section in which they are used.
* Image files should be included in a subdirectory with a name reflecting that of the RFC number (i.e. `ifa-0001`).
* Image files should be included in a subdirectory with a name reflecting that of the proposal number (i.e. `ifa-0001`).
* When appropriate, include a [DocToc][doctoc] markup for a Table of Contents after the header:
Each RFC must begin with the following header, lines marked with an asterisk are optional.
Each proposal must begin with the following header, lines marked with an asterisk are optional.
```Plaintext
RFC: <RFCnumber>
Title: <RFCtitle>
IFA Proposal: <Proposalnumber>
Title: <Proposaltitle>
Author: Real Name "optional username" <real@example.tld>
Anonymous Handle <user@example.tld>
Status: Draft | Accepted | Final | Deferred |
Withdrawn | Rejected | Superseded
Type: Standards Track | Informational | Process
Created: yyyy-mm-dd
* Replaces: <RFCnumber>
* Superseded-By: <RFCnumber>
* Replaces: <Proposalnumber>
* Superseded-By: <Proposalnumber>
* Resolution: <linktoannouncement>
```
@ -176,27 +175,23 @@ The Created header should record the date of the initial pull request.
####Resolution
The Resolution header is required for Standards Track RFC only. It contains a URL that should point to the pronouncement about the RFC and when it will go into effect.
The Resolution header is required for Standards Track Proposal only. It contains a URL that should point to the pronouncement about the proposal and when it will go into effect.
Copyright
=========
All RFCs must be licensed as [CC0][cc0], although we are waiving the requirement to label each individually.
All proposals must be licensed as [CC0][cc0], although we are waiving the requirement to label each individually.
For each RFC pull request an editor does the following:
* Read the RFC to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
* The title should accurately describe the content.
* Edit the RFC for language (spelling, grammar, sentence structure, etc.), markup, and code style.
If the RFC isn't ready, the editor will send it back to the author for revision, with specific instructions.
Proposal Editor Responsibilities
================================
Once the RFC is ready for the repository the RFC editor will accept the pull request.
After PR for a proposal pull has been submitted, an editor does the following:
Many RFCs are written and maintained by developers with write access to the Bitcoin codebase. The RFC editors monitor RFC changes, and correct any structure, grammar, spelling, or markup mistakes we see.
* Read the proposal to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
* Ensure that the title should accurately describe the content.
* Edit the proposal for language (spelling, grammar, sentence structure, etc.), markup, and code style.
* If the proposal isn't ready, the editor will not assign a number nor draft status. Instead, they should reject the PR but feedback and specific instructions for the author.
* If the proposal is ready, ensure that the Draft number is accurate, update the list of current proposals found in the README file, and merge the PR.
RFC editors are not critics, their job is to facilitate RFC processing through constructive feedback and perform administrative functions.
Proposal editors are not critics, their job is to facilitate the process through constructive feedback and to perform administrative functions.
indolering
9 years ago