Add information about project governance and team

[yrodiere]

I semt an email about this to hibernate-dev, it warrants a discussion among all members: https://lists.jboss.org/archives/list/[email protected]/thread/WMNJHAWAVAAJVWFWNBIJV2GNRMUHOIW2/

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. => See discussions below, it looks like consensus was reached for those who had a look so far. Waiting for a few more...

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

[yrodiere]

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

If you read this, and you're not on this page, 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]

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

[emmanuelbernard]

Thanks @yrodiere for the updates. Looks good for me. I wondered about one thing. AFAI could see, you are only a member @yrodiere. Is that fine or is that a sign that a Project lead at the Hibernate level is missing?

[yrodiere]

AFAI could see, you are only a member @yrodiere.

That's right. I'm not leading any project at the moment.

Is that fine or is that a sign that a Project lead at the Hibernate level is missing?

This role, I think, has never been totally clear -- even before I took it on :)

The way I see it my role is more internal to our employer, around effort coordination and consistency of technical choices initiated within our company. If other companies want to help out and make significant, regular contributions, it is in their right to have their own strategy, their own internal coordination, and it seems fair to me to handle related decisions/conflicts at a (sub)project level. I doubt they would like having yet another person to say "pretty please" to, especially if they are only interested in one relatively independent (sub)project (e.g. Hibernate Validator).

There is the question of cross-project technical decisions, such as "which observability stack are we going to focus our efforts on". But then it's really about effort; I could see scenarios where multiple companies maintain separate efforts for separate integrations to different observability stacks. It'd be a mess, sure, but it would truly be open, and project leads would still be able to veto problematic contributions (e.g. force these integrations to remain outside of the core artifacts).

We could probably advertise my role within Red Hat on the website, but I'm not sure it makes sense to have the Hibernate governance model give me elevated decision power, on top of my influence within Red Hat. After all, Red Hat does encourage technical choices that are what's best for a project, technically, even if that is not what's best for Red Hat :)

[emmanuelbernard]

AFAI could see, you are only a member @yrodiere.

That's right. I'm not leading any project at the moment.

Is that fine or is that a sign that a Project lead at the Hibernate level is missing?

This role, I think, has never been totally clear -- even before I took it on :)

The way I see it my role is more internal to our employer, around effort coordination and consistency of technical choices initiated within our company. If other companies want to help out and make significant, regular contributions, it is in their right to have their own strategy, their own internal coordination, and it seems fair to me to handle related decisions/conflicts at a (sub)project level. I doubt they would like having yet another person to say "pretty please" to, especially if they are only interested in one relatively independent (sub)project (e.g. Hibernate Validator).

There is the question of cross-project technical decisions, such as "which observability stack are we going to focus our efforts on". But then it's really about effort; I could see scenarios where multiple companies maintain separate efforts for separate integrations to different observability stacks. It'd be a mess, sure, but it would truly be open, and project leads would still be able to veto problematic contributions (e.g. force these integrations to remain outside of the core artifacts).

We could probably advertise my role within Red Hat on the website, but I'm not sure it makes sense to have the Hibernate governance model give me elevated decision power, on top of my influence within Red Hat. After all, Red Hat does encourage technical choices that are what's best for a project, technically, even if that is not what's best for Red Hat :)

+1
Let's not add weight to it and see how things go.

[emmanuelbernard]

BTW @Sanne that's the PR I mentioned to you

[Sanne]

Sorry for being late, but have some thoughts as well.

1. Current "members" listed on:

• https://staging.hibernate.org/community/team/
  I understand from your comments that this is taken from github, but it feels odd: I see some people listed there who I know have contributed very little, while some major contributors are clearly missing.
  I don't mean to have you embark in a complex quest in making this look better though; perhaps adding a note on the list to clarify how to get there? My goal is not to have an accurate representation, but to make sure that significant contributors don't feel left out and understand how this works.
  Not highly important, but I see project leads are repeated among the members as well.

2. Definition of "Project Leaders"
   currently reads:

Members (at most one per code repository) with higher decision power whenever the project they lead is affected. Responsible for steering project direction, and for enforcing compliance with requirements of the Commonhaus Foundation.

I think it would be nice to have a stronger accent on collaboration rather than the project lead appearing to be solely responsible for such aspects.
"steering the direction" and "requirements guard" to be a shared responsibility of all contributors of all levels: it's just something the project needs and contributions are welcome in all areas, in fact we should motivate novel suggestions from "fresh" perspectives so including total newcomers (with some guardrails against time-wasters).
Perhaps it's just my personal opinion, but I've always regarded the "project lead" as being primarily responsible for intervening to make a decision happen in case of deadlock : sometimes a suboptimal, fast decision is better for the health of the project over a lenghty, tiring debate which could sap energy from more valuable aspects, or simply due to time requirements.
The project lead would have the seniority, experience and broader view to tip the scales on complex and nuanced decisions, but otherwise he/she should be able to go on holidays occasionally, or work on complex issues w/o having to constantly watch chats, and trust that the other members kinda know what needs to be done, or what they would say.

I appreciate this is difficult to express, sorry for that.

3. Decision Making
   currently reads:

Actual implementation of consensus decision-making is up to Members and can vary based on the audience and criticality of the discussion. Inspiration may be found in the Lazy Consensus model as defined by the Apache Foundation, and in Martha’s Rules.

I'm a little confused here - isn't this precisly the paragraph that should explain how we do it, rather than suggesting options? Perhaps this is the right place in which we can elaborate on the role of the project lead I expressed in the previous point? We could say something among the lines "member consensus, or project lead decision if no consensus could be defined in reasonable time".

4. Project Leader election
   It states:

Discussions regarding the role of Project Leader may not last less than 30 days.

What happens if the 30 days are over?
Also it looks like the decision process is "anything we want" based on the previous point, but that's going to be a bit problematic when, for example, a project lead is a vacant position, as we wouldn't have a way to ensure a decision is reached.
Considering the role of the Project lead is extremely important, I'm afraid we need to nail this one properly: especially when opening the project's control to wider access there's going to be higher risk of conflict which we need to prevent, and this also needs to be clear to actually attract more significant contributions.

[Sanne]

There's also the need to have a well defined way to take cross-project decisions. In the current structure it seems to revolve around the Project Leads, but they are by definition scoped to particular projects.
Just as an example, suppose Gavin were to be unable to continue in his role - the Foundation would require the members of the Hibernate project to appoint a new representative. There's probably some more day-to-day examples to be made as well, if principles we want all projects to adopt or coordinate consistently, e.g. infrastructure strategy

[yrodiere]

Thanks for taking the time to review, Sanne.

I understand from your comments that this is taken from github, but it feels odd: I see some people listed there who I know have contributed very little

I agree and think choices have been made that were perhaps a bit too liberal when it comes to adding people to the GitHub org. But then I'm not going to try and remove people, because I've already tried some softer approaches, and even that usually comes right back in my face.

We need a discussion about people having unnecessary access rights on GitHub, though; it's in my plans, but unrelated to the governance model. Will happen later.

Relegating the (few) members "added by accident" to "contributor" status is also something we can investigate -- but, similarly, it'd require a separate discussion.

while some major contributors are clearly missing.

As I explained on this PR, and as is highlighted on the website, people who don't make their membership public are hidden.

If, aside from that, some major contributors that you consider members are missing from the GitHub org, please give me a list.

Without a formal definition of what it means to be a Hibernate member, we just don't know who is a member right now.

We need some authoritative list, and GitHub was just the most obvious choice. It seems good enough to me if everyone just agrees.

I don't mean to have you embark in a complex quest in making this look better though; perhaps adding a note on the list to clarify how to get there? My goal is not to have an accurate representation, but to make sure that significant contributors don't feel left out and understand how this works.

Like See [the governance model](link) for information on how to become a Hibernate organization member?

I think it would be nice to have a stronger accent on collaboration rather than the project lead appearing to be solely responsible for such aspects.

We can talk about the "steering the direction" part, but enforcing compliance with Commonhaus rules is definitely the role of the project lead, per Commonhaus' own policy. No way around that. There's even rules to evict a project leader if rules aren't complied with.

"steering the direction" and "requirements guard" to be a shared responsibility of all contributors of all levels: it's just something the project needs and contributions are welcome in all areas, in fact we should motivate novel suggestions from "fresh" perspectives so including total newcomers (with some guardrails against time-wasters).

I think that description is overly optimistic, but I agree we don't need to require the "steering" part in the governance model.

What we need to do is justify the higher decision power.

So, what about:

"Responsible for keeping the project's technical direction consistent, safe and sustainable, and for enforcing compliance with requirements of the Commonhaus Foundation."

Or whatever adjectives you think make sense.

Perhaps it's just my personal opinion, but I've always regarded the "project lead" as being primarily responsible for intervening to make a decision happen in case of deadlock : sometimes a suboptimal, fast decision is better for the health of the project over a lenghty, tiring debate which could sap energy from more valuable aspects, or simply due to time requirements.

This is pretty much what the decision-making process describes.

The project lead would have the seniority, experience and broader view to tip the scales on complex and nuanced decisions, but otherwise he/she should be able to go on holidays occasionally, or work on complex issues w/o having to constantly watch chats, and trust that the other members kinda know what needs to be done, or what they would say.

Fair enough. Seems the governance model as it is wouldn't prevent that?

I'm a little confused here - isn't this precisly the paragraph that should explain how we do it, rather than suggesting options?

@emmanuelbernard doesn't want to mandate a particular, strict process, because we haven't had one so far and there's time to introduce something stricter later -- if we want to. I think it makes sense.

Perhaps this is the right place in which we can elaborate on the role of the project lead I expressed in the previous point?
We could say something among the lines "member consensus, or project lead decision if no consensus could be defined in reasonable time".

That's... what it says? "Conflict Resolution" > "Project Leaders hold the power to make the final decision, be it individually for the project they lead, or collectively for cross-project matters."

What happens if the 30 days are over?

Then discussions can end, with whatever outcome.

Also it looks like the decision process is "anything we want" based on the previous point, but that's going to be a bit problematic when, for example, a project lead is a vacant position, as we wouldn't have a way to ensure a decision is reached.

"Conflict Resolution" > "Project Leaders hold the power to make the final decision, be it individually for the project they lead, or collectively for cross-project matters."

If consensus cannot be reached, other project leaders decide.

Considering the role of the Project lead is extremely important, I'm afraid we need to nail this one properly: especially when opening the project's control to wider access there's going to be higher risk of conflict which we need to prevent, and this also needs to be clear to actually attract more significant contributions.

I felt that way too. I proposed a voting system similar to Commonhaus. Emmanuel remarked this does not reflect how we currently work, and thus should probably be discussed separately.

Given our divergence of opinions, I tend to agree with this. Let's nail down how it works now, and discuss improvements later.

There's also the need to have a well defined way to take cross-project decisions. In the current structure it seems to revolve around the Project Leads, but they are by definition scoped to particular projects.
Just as an example, suppose Gavin were to be unable to continue in his role - the Foundation would require the members of the Hibernate project to appoint a new representative. There's probably some more day-to-day examples to be made as well, if principles we want all projects to adopt or coordinate consistently, e.g. infrastructure strategy

The decision process describes that: we discuss this, try to reach a consensus, and if we don't, project leaders decide collectively, and if someone disagrees very strongly they can appeal to (very) higher instances at Commonhaus.

I could come up with arbitrary rules to resolve conflicts between project leaders, but we'd need to agree on those rules. So, like above... let's describe how it works now?

[gavinking]

If felt that way too. I proposed a voting system similar to Commonhaus. Emmanuel remarked this does not reflect how we currently work, and thus should probably be discussed separately.

Definitely agree with Emmanuel here. Voting is the worst possible way to resolve a disagreement, since it doesn't actually resolve the disagreement.

[Sanne]

Ok, I better understand the proposal now - essentially we want to keep it light on specific restrictions at this stage, with the option to refine.
I'm cool with that 👍

I think that I'd prefer to rephrase the specific wording of project leads still a little, just to better reflect the nature of them being "final-word bearing to break deadlocks" rather than them having to do a lot of daily work to emphasize that everyone has shared responsibilities, but rather than going on a tangent on this already complex PR, I'm OK to accept this proposal and discuss minor nitpicks in a separate follow up.