Contribution (management) policy proposal

[baentsch]

This is to discuss a proposal regarding contribution management and (ideally self-)governing the people participating in this process: Please take a look at the proposal: (link updated: https://github.com/open-quantum-safe/oqs-provider/blob/mb-newpolicy/GOVERNANCE.md).

As the person with probably (at least currently :) most interest in seeing this project mature, I volunteer editing this as this discussion goes on -- and at the end PR this into the project.

I'm particularly inviting feedback from the people I currently deem having --thankfully-- done most to move this project forward, even though not all are part of the OQS project. Most notably, inviting comments by @levitte @thb-sb @dstebila @christianpaquin @bhess.

If this goes well, we may want to adopt something similar (possibly with different people being listed in different positions) at the very least for liboqs -- but possibly also for other OQS subprojects we may want to see move into a "not-only-experimental" usage phase.

Background/Rationale for the proposal:

Key goals:

• keep things as short as possible while still being sufficiently precise
• do not exclude any "doer" from taking decisions (e.g., based on project or organizational affiliation)
• allow this project to keep living on as a "do-ocracy" managed by the people that do things (and not the people that shout loudest or have most lawyers) even as/if/when the original authors may withdraw.

Quite a few ideas have been taken off the OpenSSL policies and the structure from the Linux Foundation "Technical Project Charter" template (see an implemented Charter here). Further aspects have been "adopted" from some constitutions.

Looking forward to the discussion.

[levitte]

Oh, I'm a committer? Hadn't realised that...

[baentsch]

Well, this designation is a proposal based on the facts that the initial code structure is yours, the project had been forked from your repo for a long time and you always provided support when problems in the OpenSSL integration came up. I would be honoured if you'd accept this role and help move the project forward.

[levitte]

I'm equally honored that you think of me this way!

That being said, I think I must decline for now. Being a Committer as per this file puts more demands on my regularity than I feel I can meet, at least for the time being.
I'm perfectly happy with being a Contributor.

[baentsch]

Sorry to hear that -- but fully understandable. If you'd be able to suggest someone else from the OpenSSL community who may be willing to take this on, please let us know: I personally really value a close(r) relationship with your team and would like to see this continue independent of any future legal project control changes. IMO best therefore would be a person not being affiliated with Linux Foundation such as to retain the voice of the non-commercial open source community in this project.

[levitte]

I've looked at this new file, and while the old CONTRIBUTE.md does look like a contribution guide, this new file doesn't, it looks more like a governance description.

Now, Github comes to the rescue; if you look at their guide for creating default community files, they do give an example of a governance file name: GOVERNANCE.md. That's looks to me to be a much more fitting name for this new file.

As for the contents of this governance description, I see no big issues.
I have one detail thing, though: you'll want a method to clearly mark a vote as such, so it doesn't "drown" in all other discussion items. A discussion category for votes, or a label, should do fine.

[baentsch]

Thanks for the feedback and suggestions, @levitte : Incorporated as proposed.

[levitte]

Yup, saw the move.

I'd suggest keeping the current CONTRIBUTE.md and remove CONTRIBUTE entirely. Having them both is just confusing.

[baentsch]

Fully agreed. But that would need a change of wording in an LF contract..... Let me try to see how they react to such proposal.

[levitte]

That sounds like a small detail correction... I would be quite surprised if anyone would make a stink over that.

[bhess]

Thanks for preparing this proposal @baentsch. I have just two points for clarification:

• Reading the document, it isn't clear to me if PRs and their approval are considered a vote, where the voting rules would apply.
• It seems to be not defined which roles can vote.

[levitte]

This picked my interest, so I proposed some simple changes: #287

[baentsch]

Resolved by merging #287: Thanks @levitte @bhess .

[baentsch]

Following feedback by the SustainOSS community a clarification to Maintainer status and consequences of not following the code of conduct have been added in 1b35f93.

[SWilson4]

I left feedback on #286, since in a couple of places it was easier to refer directly to text inline than to link to it here.

My only feedback of discussion significance is on this paragraph:

Any Committer may voluntarily temporarily for a documented period step down from the role losing voting rights for the specified period. If such period extends beyond one year, the Committer permanently loses role and rights. The period is documented in this file next to the person's name below.

I'll copy what I wrote on #286:
What is meant by "permanently" here? As written, it sounds like someone who steps down from the Committer role for a year is banned from regaining that status in the future. That seems heavy-handed to me. If the intent is more lenient (e.g., "permanently" means restarting from User), then I think this needs to be reworded.

Thanks very much for taking the lead on this, @baentsch!

[baentsch]

Thanks @SWilson4 for the feedback here and in the PR. All proposed changes are very logical (and necessary) and I'd like to invite you to do a PR to incorporate all your proposals in one commit -- just be sure to target the proper branch.

it sounds like someone who steps down from the Committer role for a year is banned from regaining that status in the future

This is not the intention. Please propose in your PR a wording that makes it clear that anyone can re-attain a role after leaving it, be it pro-actively -- e.g., by long-term leave-of-absence-- or inactively --e.g., simply not participating any more. Different rules would apply in case of a "ban", i.e., being voted out of a role due to violation of code of conduct etc.

In addition, I'd be very glad if you --as a native speaker-- would be willing to give this a glance over from the perspective of "tone of text": I heard feedback that it seems overly "harsh" -- that's not the intention. It just should be precise. But my "Germanic" language background could have lead to an unnecessarily "unpleasant tone" :-/

[SWilson4]

In addition, I'd be very glad if you --as a native speaker-- would be willing to give this a glance over from the perspective of "tone of text": I heard feedback that it seems overly "harsh" -- that's not the intention. It just should be precise. But my "Germanic" language background could have lead to an unnecessarily "unpleasant tone" :-/

I must admit that I quite like precision and think it's useful when defining things, and I found it difficult to modify the role and process definitions to be more warm without losing succinctness. I took the approach of adding a brief foreword in a more welcoming tone explaining the purpose of the governance document and what we hope to accomplish with it. Think of it like an Internet cookbook---start with the story of your grandma's recipe and have the step-by-step details at the bottom to consult when needed. Anyway, I made PR #297 if you want to take a look and see if you think it accomplished what we're looking for.

[levitte]

I was reading the section in question, and still found it unclear (even though "permanently" was removed... and also, couldn't quite see why leave of absence should be in the voting section.

So, er, I propose a bit of re-arrangement, see #298