Hi, > The proposals you put forward would mean that we write a four sentence BCP > into a RIPE document as the BCP, which then points to a GitHub repository for > more detailed guidance. And that seems a bit thin. Something that may fit the > typical BCP process more is to publish the actual policy document[1] as the > BCP, as that documents the actual practice. However, this has the downside > that a git PR/commit is much easier than updating a RIPE document in the > future. Is that something the authors would actually want? > > This raises some questions for the working group: > • Do we want to publish this as a BCP? > • Is it our intention to publish something like the text suggested as a > four sentence BCP? > • Or is that too thin and would we want to publish the full policy guide > as a BCP? > • Is that desirable, due to the difficulty of updating a RIPE document > later? > • Is this a sufficiently established best practice to be appropriate for > a BCP?
I'd say that for a WG to publish a RIPE document, it would need to have consensus on the content. A four-sentence document referencing an external document that will change over time is technically possible. It would define that the WG trusts the maintainers of that external document to the point that the BCP is "do whatever they say". I can see issues with that :) Personally I would prefer a style where the community works together on the text (whether in GitHub or elsewhere), reaches consensus that a certain revision is "ready enough", and then publishes that as a BCP. Potentially referring to the GitHub repo as "this is the place where future work on this will take place". When the live document has been updated enough that the community doesn't feel that the RIPE document represents the new best practices, a new revision can be taken and the consensus process can be done again, resulting in a new RIPE document which obsoletes the old RIPE document. That way the actual text is declared a BCP by consensus, the document can evolve, and consensus can be reached on the updates. We had the same issues with RIPE501/554/772. We used a different mechanism to discuss the updates, but in essence did what I described above: collect updates, propose a certain text for the new version, get consensus and publish it as a new RIPE document. Cheers, Sander Speaking as one of the RIPE501/554/772 authors ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/opensource-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
