Re: [Ledger] Proposed Interledger RFC process

Just to clarify:


   - Would working drafts and candidate specifications live in different
   places? Which one would github.com/interledger/rfcs hold?
   - If I have a new Interledger-related idea, would I just submit a PR to
   the RFCs repo and claim the next available number? Or should I submit a PR
   with no number and have a maintainer assign the number (got that idea from
   Yarnjs <https://github.com/yarnpkg/rfcs#what-the-process-is>).
   - Is "version 1" of ILQP, for example, always going to "live" in the
   same numbered RFC? Would "version 2" then be a different RFC number and
   minor updates to the original one just increment the draft number?
   - Trickier question: what defines "consensus to publish"? Who are the
   stakeholders that need to agree?


On Tue, Jun 20, 2017 at 12:03 PM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> As discussed before we have an issue whereby our Interledger RFCs are
> regularly changing and it's not possible for someone to refer to a static
> version of the document and be sure that the content won't substantially
> change the next time they visit the URL.
>
> I had initially proposed that we introduce semantic versioning on the RFCs
> but we decided against this on the basis that we should:
>
> a) Differentiate between specs that are incubating (similar to IETF
> Internet Drafts) and those that are mature (similar to IETF RFCs)
> b) Assign an RFC number to stable specs and a new number to revisions of
> that
>
> As such my proposal is that we adopt the following process for the
> Interledger RFCs going forward (this is something of a hybrid between the
> IETF and W3C processes and is in keeping with the process defined for us as
> a W3C Community Group):
>
> 1. There are two document types *Working Drafts* and *Candidate
> Specifications*.
> 2. Interledger RFCs are living documents that start as *Working Drafts*.
> 3. Working Drafts have an RFC number AND a draft number starting at 0 and
> increasing by 1 each time the content is changed. Attempting to merge
> changes to a Working Draft without incrementing the draft number should
> result in a build failure of the publishing process.
> 4. When a *Working Draft* is considered stable there is a call for review
> from the community to publish the document as a *Candidate Specification*
> 5. Assuming there is consensus to publish, the document becomes a *Candidate
> Specification* and no further substantive changes are allowed under the
> same RFC number.
>
> NOTES:
>
>    - Candidate Specifications SHOULD also be published as W3C Community
>    Group reports.
>    - Candidate Specifications MAY be published as IETF Internet Drafts.
>    - A different template should be used for Working Drafts and Candidate
>    Specifications to help readers differentiate between them.
>    - An explanation of this process should be available on the website
>    and linked from the RFCs
>
>
> _______________________________________________
> Ledger mailing list
> Ledger@ietf.org
> https://www.ietf.org/mailman/listinfo/ledger
>
-- 

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>