Re: [Ledger] Proposed Interledger RFC process

On 21 June 2017 at 15:54, Evan Schwartz <evan@ripple.com> wrote:

> Just to clarify:
>
>
>    - Would working drafts and candidate specifications live in different
>    places? Which one would github.com/interledger/rfcs hold?
>
>
No, same place but they'd render on the website with a different template
(similar to W3C specs).
Once an RFC becomes a Candidate Spec attempting to merge changes will
result in test errors so unless a maintainer overrides they should never
change.

>
>    -
>    - 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>).
>
>
Good question. I like that suggestion. Will document i that way. To submit
a draft you submit a PR with the draft. If a maintainer accepts it they'll
add a commit to the PR renaming it to claim an RFC number.


>
>    -
>    - 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?
>
> That's the idea. Unless we start documenting v2 before v1 is stable and
moved to Candidate Spec.

>
>    - Trickier question: what defines "consensus to publish"? Who are the
>    stakeholders that need to agree?
>
> I'd consider consensus to mean nobody has objected strongly. W3C has a
formal process which we can use and that's roughly it. Dimi and I as the
chairs are responsible for getting and evaluating consensus.

Given the current makeup of the group and level of participation from
various people I expect we'd weight the opinion of the maintainers and
major contributors highly.

>
>
> 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
>