ifa-0000.md

Guidelines & Process RFC

ifa-0000.md

@@ -0,0 +1,202 @@
+```
+  RFC: 0
+  Title: IFA RFC Guidelines & Process
+  Author: Zachary Lym "indolering" <zachlym@indolering.com>
+  Status: Draft
+  Type: Process
+  Created: 2015-05-25
+```
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+**Table of Contents**
+
+- [Abstract](#abstract)
+- [Types](#types)
+- [RFC Workflow](#rfc-workflow)
+  - [Status](#status)
+  - [Rejection](#rejection)
+  - [Discussion](#discussion)
+- [Content](#content)
+  - [Sections](#sections)
+  - [Format](#format)
+  - [RFC Header](#rfc-header)
+      - [Authors](#authors)
+      - [Created](#created)
+      - [Resolution](#resolution)
+- [Copyright](#copyright)
+- [RFC Editor Responsibilities](#rfc-editor-responsibilities)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+
+Abstract
+========
+
+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.
+
+
+Types
+=====
+
+There are three kinds of RFCs:
+
+* 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.
+
+RFC 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.
+
+An RFC champion should begin writing their RFC by forking the IFA-WG RFC repo  and following the formatting instructions found in this RFC. 
+
+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.
+
+Status
+------
+
+The possible paths for a Draft RFC are as follows:
+
+![][/ifa-wg/rfc/blob/master/rfc-0000/process-diagram.svg]
+
+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.
+
+<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>
+  
+  <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>
+  
+  <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>
+  
+  <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>
+  
+  <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>
+
+  <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>
+  
+  <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>
+  
+</dl>
+
+Rejection
+---------
+
+An RFC editor can reject an RFC without discussion for any number of reasons, including:
+
+* Being too broad.
+* Not relying on existing standards/duplicating effort.
+* Incorrect formatting.
+* 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.
+
+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.
+
+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).
+
+Sections
+--------
+
+Each RFC *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.
+
+* 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.
+
+* 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.
+
+* 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.
+
+* The final implementation must include test code and documentation.
+
+Format
+------
+
+* NFCs 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`).
+* When appropriate, include a [DocToc][doctoc] markup for a Table of Contents after the header:
+
+    <!-- START doctoc -->
+    <!-- END doctoc -->
+
+[GHMarkdown]: https://help.github.com/articles/github-flavored-markdown/
+[doctoc]: https://github.com/thlorenz/doctoc
+
+RFC Header
+----------
+
+Each RFC must begin with the following header, lines marked with an asterisk are optional.
+
+```Plaintext
+  RFC: <RFC number>
+  Title: <RFC title>
+  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: <RFC number>
+* Superseded-By: <RFC number>
+* Resolution: <link to announcement>
+```
+
+####Authors
+
+Real names **must** be used unless the author is anonymous.
+
+####Created
+
+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.
+
+Copyright
+=========
+All RFCs must be licensed as [CC0][cc0], although we are waiving the requirement to label each individually.
+
+[cc0]: http://creativecommons.org/publicdomain/zero/1.0/
+
+RFC Editor Responsibilities
+===========================
+
+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.
+
+Once the RFC is ready for the repository the RFC editor will accept the pull request.
+
+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.
+
+RFC editors are not critics, their job is to facilitate RFC processing through constructive feedback and perform administrative functions.