Add information about project governance and team

[yrodiere]

I will send an email about this to hibernate-dev, it warrants a discussion among all members.

The important changes are:

• A new "Governance" page (see on staging) describing the structure and decision-making of the Hibernate organization. This establishes a sort of "bylaws" that we were missing until now. It's important for openness: with it, people can know what to expect if they dedicate time to the projects. The intent is to link to this page from a GOVERNANCE.md file in all repositories (or at least the main ones).
• A new "Team" page (see on staging) listing project leaders and members who chose to make their membership public. It completes the governance information by clearly showing who contributors will have to work/argue with.

IMPORTANT: This is a first attempt. I worked on this by myself, so it needs reviews, comments, and adjustments. The final document must be something we all agree with, and commit to complying with.

[yrodiere]

This file is based on the Commonhaus template, with some heavy changes to better match what (I think) is the current governance model in the Hibernate team.

[yrodiere]

Note iteration 2 involves even heavier changes, the decision-making process is quite different.

[marko-bekhta]

I don't expect this to be a problem, but just thinking of "edge cases" should we consider saying something along the lines:

Suggested change

	Small or inactive projects may not have a leader,
	in which case Members interested in the project will steer the project direction.
	Small or inactive projects may not have a leader,
	in which case Members interested in the project will steer the project direction under the supervision of other project leaders.

I'm just thinking, let's say hibernate-models is driven in a direction that doesn't match what ORM/Search is doing 😄 but those two cannot influence it anymore 🙈

[yrodiere]

I think that's implicit in the statement:

Project Leaders hold the power to overrule any decision directly affecting the project they lead.

ORM/Search leaders would have power to overrule decisions in hibernate-models, since that directly affects ORM/Search.

Or is that unclear?

[marko-bekhta]

hmm, yeah, from reading it I didn't think that that "power" goes beyond the project itself (i.e. particular repository)

[yrodiere]

I tried to clarify this in the "Decision-Making" section.

[yrodiere]

Oddly, some very active members have made their membership private... Maybe by mistake?

If you read this, please check your membership's visibility. See https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership

[emmanuelbernard]

I have two high level comments

1. referring to the commonhaus rules vs embedding them is a bit confusing and harder to follow. So I'd inline.

2. I have not seen "sense vote" or member votes as part of the Hibernate operations but it could be that I've been away and that it is the unique motus operandi now. What I have seen is conversation with lazy consensus with an ultimate decision by the project leader based on what has been expressed in case the consensus is not reached. So you want to modify that behavior?

[yrodiere]

1. referring to the commonhaus rules vs embedding them is a bit confusing and harder to follow. So I'd inline.

Which rules are you talking about?

The code of conduct and trademark policy are quite large, I'm not sure it would make things clearer if we inlined them...

For the decision making process that'd be more reasonable, especially considering the confusing references to the "council" and similar in the Commonhaus document. I could try to inline that -- if I manage to remove some content so it fits in a reasonably-sized section.

[yrodiere]

(sent too fast...)

2. I have not seen "sense vote" or member votes as part of the Hibernate operations but it could be that I've been away and that it is the unique motus operandi now. What I have seen is conversation with lazy consensus with an ultimate decision by the project leader based on what has been expressed in case the consensus is not reached. So you want to modify that behavior?

Yeah that's one place where I tried to meet Commonhaus half-way... It's in the original template, I just added "overruling power" for project leaders.

I agree what you described is accurate: consensus if possible, leader decision otherwise. I haven't seen a vote take place.

But then, giving leaders "overruling power" over their project gives us pretty much that way of working -- votes would only be useful when leaders don't feel strongly either way, to resolve conflicts between non-project-leaders, or when a conflict arises about a decision that is not strictly about one project.

Fortunately such conflicts have been rare, so I don't really have examples of situations where the vote would have been useful.

However, if we are to formalize governance, I think we need an answer ahead of time. Conflict resolution is important if we hope that the move to Commonhaus will encourage other interested parties to become significant stakeholders -- with potentially diverging views and interests.
There is the option to turn to Commonhaus instances for this, but IMO that feels a bit extreme.

Perhaps I should rephrase the document to say that project leaders don't have "overruling power", but rather that decisions are made in this order:

1. Consensus.
2. Lacking consensus: leader decision -- if the decision is about a project in particular.
3. Lacking leader decision (leader does not feel strongly either way, or the decision is not about a project in particular): vote.
4. In case of remaining conflict after a vote: appeal through Commonhaus.

(I will try to phrase it better.)

It amounts to pretty much the same thing as what I wrote, but presented this way it does feel closer to how we've appraoched this in practice: item 1 and 2 are how it's always been done, and 3/4 are two further steps to address situations that could arise with a more heterogeneous pool of decision-makers.

[emmanuelbernard]

1. referring to the commonhaus rules vs embedding them is a bit confusing and harder to follow. So I'd inline.

Which rules are you talking about?

The code of conduct and trademark policy are quite large, I'm not sure it would make things clearer if we inlined them...

For the decision making process that'd be more reasonable, especially considering the confusing references to the "council" and similar in the Commonhaus document. I could try to inline that -- if I manage to remove some content so it fits in a reasonably-sized section.

Yes it's about the decision process, the sentence that triggered me was

Hibernate projects follow the Commonhaus decision-making process, with one additional provision.

So I was assuming I had to read the Commonhaus rules to understand the process.

[emmanuelbernard]

(sent too fast...)

2. I have not seen "sense vote" or member votes as part of the Hibernate operations but it could be that I've been away and that it is the unique motus operandi now. What I have seen is conversation with lazy consensus with an ultimate decision by the project leader based on what has been expressed in case the consensus is not reached. So you want to modify that behavior?

Yeah that's one place where I tried to meet Commonhaus half-way... It's in the original template, I just added "overruling power" for project leaders.

I agree what you described is accurate: consensus if possible, leader decision otherwise. I haven't seen a vote take place.

But then, giving leaders "overruling power" over their project gives us pretty much that way of working -- votes would only be useful when leaders don't feel strongly either way, to resolve conflicts between non-project-leaders, or when a conflict arises about a decision that is not strictly about one project.

Fortunately such conflicts have been rare, so I don't really have examples of situations where the vote would have been useful.

However, if we are to formalize governance, I think we need an answer ahead of time. Conflict resolution is important if we hope that the move to Commonhaus will encourage other interested parties to become significant stakeholders -- with potentially diverging views and interests. There is the option to turn to Commonhaus instances for this, but IMO that feels a bit extreme.

Perhaps I should rephrase the document to say that project leaders don't have "overruling power", but rather that decisions are made in this order:

1. Consensus.

2. Lacking consensus: leader decision -- if the decision is about a project in particular.

3. Lacking leader decision (leader does not feel strongly either way, or the decision is not about a project in particular): vote.

4. In case of remaining conflict after a vote: appeal through Commonhaus.

(I will try to phrase it better.)

It amounts to pretty much the same thing as what I wrote, but presented this way it does feel closer to how we've appraoched this in practice: item 1 and 2 are how it's always been done, and 3/4 are two further steps to address situations that could arise with a more heterogeneous pool of decision-makers.

I am uneasy about this.

Personally, I would describe what we have today. This does not prevent a lead to ask for a vote. And if everyone want to add this vote thing, then we can amend.

I am not sure commonhaus reps should be above on any subjects. Which leads to the question, which types of subjects make sense to be escalatable, and which is not? I'm sure the name of the Id generation interface is not something that would be useful to raise to a commonhaus board.

If some mad lead wants to ban 1/3rd of the community based on first name initials, then maybe a commonhaus appeal would make sense but even there it feels a bit counter to the CH rules of hands off and set your own governance model it was initially started as.

[yrodiere]

TL;DR:

I think this is the minimal decision process we can describe while sticking to the existing one:

1. Consensus.

2. Lacking consensus: leader decision, by leaders of affected projects. Possibly vote, at the leader's discretion.

3. In case of remaining conflict (presumably rare): appeal through Commonhaus.

I'd personally prefer some clear way of resolving conflicts that doesn't involve Commonhaus -- for example in case there is disagreement, including between leaders, regarding whether someone should join the Hibernate org.
But okay, this can wait until we've seen such a situation and learned from it. In the meantime I suppose the outcome of such a situation will be "no decision reached, that person won't join".

---

However, if we are to formalize governance, I think we need an answer ahead of time. Conflict resolution is important if we hope that the move to Commonhaus will encourage other interested parties to become significant stakeholders -- with potentially diverging views and interests. There is the option to turn to Commonhaus instances for this, but IMO that feels a bit extreme.
Perhaps I should rephrase the document to say that project leaders don't have "overruling power", but rather that decisions are made in this order:
[...]
It amounts to pretty much the same thing as what I wrote, but presented this way it does feel closer to how we've appraoched this in practice: item 1 and 2 are how it's always been done, and 3/4 are two further steps to address situations that could arise with a more heterogeneous pool of decision-makers.

I am uneasy about this.

Personally, I would describe what we have today. This does not prevent a lead to ask for a vote. And if everyone want to add this vote thing, then we can amend.

IMO joining Commonhaus to demonstrate openness, then presenting a decision-making process that gives absolute power to leaders, with no way to appeal... does not make much sense. Yes we can add vote thing later, but then I question whether joining Commonhaus changes anything at all for prospective contributors. That would amount to delaying the demonstration of openness.

Regarding appeal to Commonhaus, we can hide it from the governance model, but we cannot remove it completely -- see below.

I am not sure commonhaus reps should be above on any subjects.

To be clear, the vote between members mentioned in this document is between members of the Hibernate organization. Which may or may not be Commonhaus members -- that's completely orthogonal.

I agree that's unclear in this PR given the link about voting redirects you to a document that talks about votes between Commonhaus members. It would need to be inlined and adapted -- if we keep the vote thing.

If you're talking about the "last-resort" conflict resolution... see below.

If some mad lead wants to ban 1/3rd of the community based on first name initials, then maybe a commonhaus appeal would make sense but even there it feels a bit counter to the CH rules of hands off and set your own governance model it was initially started as.

That's true... to some extent. Joining Commonhaus implies some rules are forced upon us, most notably the code of conduct, trademark policy, ... At least any conflict around those would legitimately involve Commonhaus.
In fact, that provision is explicit in the code of conduct -- which we have to comply with as a Commonhaus project: https://www.commonhaus.org/policies/code-of-conduct/#escalate-an-issue

Sure we don't need to mention this in the decision-making process, but it's there anyway and we're bound by it anyway, so I feel this would make sense to mention -- especially since this actually makes the governance look better (safer) to prospective contributors (more on this below).

Which leads to the question, which types of subjects make sense to be escalatable, and which is not?

I think we don't have a choice when it comes to anything that Commonhaus allows escalating -- which would be code of conduct violations, trademark policy violations, etc.

For anything else, and in particular decisions related to development ("the name of the Id generation interface")

I'm sure the name of the Id generation interface is not something that would be useful to raise to a commonhaus board.

I'm not sure Commonhaus bylaws contain guidance around the naming of the Id generation interface, so indeed, this would be pointless to escalate: Commonhaus would have no grounds to decide how to name that interface.

I think it's more about how decisions are made than which decisions are made.

IMO what matters is that people have the option to escalate, and thus feel safe that their investment in the project won't be ruined by one decision that means everything to them. Like "renaming the Id generation interface at a time where my downstream product cannot tolerate a breaking change".

E.g. the Commonhaus code of conduct, in section 3.2 "standards" mentions:

Examples of behavior that contributes to creating a positive environment include:

[...]
Focusing on what is best for the community
[...]

I could imagine a decision being appealed if it's the best interest of a project leader (and their employer) at the expense of the rest of the community. And the code of conduct would give Commonhaus grounds to oppose such a decision. And I personally think that's good.

[yrodiere]

I tried to clarify this in the "Decision-Making" section.

[yrodiere]

@emmanuelbernard (and others) due to concerns around the voting system, I removed any mention of votes in order to better reflect the existing process.
I guess we can add voting later if "enlightened dictatorship" proves to be a real dealbreaker for some prospective contributors -- though I'm not sure how we'd ever hear about that.

This is where most changes are, but see the second commit for detailed changes.