Hi, On 28 May 2024, at 13:56, Valerie Aurora wrote:

...

following up on my talk today, I’m sending here the BCP draft for further discussion.

Open-source projects SHOULD publish their contribution and credits policy and be open about how (and if) people can contribute. Open-source project maintainers SHOULD adhere to the published policy and update it when circumstances change.

To create such a policy, maintainers can use a policy guide as a starting point. Maintainers are advised to be as open and friendly as they can.

Thank you for the helpful talk and the well-written and concise BCP draft.

I have a suggestion to change the last sentence based on what we learned writing this policy, which is that plenty of maintainers have good reasons to not be open and friendly to new contributions. I think it would help improve adoption to avoid any suggestions about how to handle contributions. I suggest something like this instead:

"Maintainers are advised to describe the current reality of how contributions are handled, rather than how they aspire to handle them, so as to set expectations for contributors accurately."

Thanks for sending the draft. I/we have been thinking a bit on the adoption of a BCP around the contribution and credits policy. Looking at recent history and other discussions, it seems there aren’t a lot of hard rules about a BCP. However, common themes seem to be that the BCP is published as a RIPE document and documents a somewhat established practice, i.e. the “current practice” part. 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: 1. Do we want to publish this as a BCP? 2. Is it our intention to publish something like the text suggested as a four sentence BCP? 3. Or is that too thin and would we want to publish the full policy guide as a BCP? 4. Is that desirable, due to the difficulty of updating a RIPE document later? 5. Is this a sufficiently established best practice to be appropriate for a BCP? Perhaps Miriam, who originally suggested a BCP, would also like to elaborate on the ideas behind that suggestion :) We can also revisit the discussion at a later time, if we decide this is not the right time. For clarity, this are questions of the best process fit specifically around a BCP. It is not a criticism of the policy itself - with my personal hat I think it’s excellent work and am working on adopting it. From the last meeting it seemed the working group in general is very positive about it as well. Sasha working group co-chair [1] https://github.com/contribution-credit/policy/blob/main/policy_guide.md

Hi Sasha, Hi all, Sorry for not responding earlier.

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.

Sander, thanks for summarising this to eloquently. This is pretty much what I had in mind when suggesting to publish it as a BCP. Publishing this as a ripe-document has the advantages that it is a stable document and people can find it and refer to it. Prerequisite is - as you point out - that there is consensus in the community/WG that this is indeed a good practice that you want to implement and encourage.

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.

Indeed. Publishing an updated version of a ripe-document is really not that difficult. It is not uncommon to discover gaps or details that need to be changed in a document after we gained some more experience with a certain process or practice. Kind regards, Mirjam (RIPE Chair)