Add Governance

[tomicapretto]

Several months ago I talked to some people mentioning the idea that I wanted to add a governance structure to Bambi to make this a better project for all. Finally, we have a draft here. Highlights are

• I copied this from PyMC and ArviZ
• The only strong opinion I have is that I don't want a BDFL model
  • Please, feel free to open a discussion if you think I'm wrong
• I do have some questions
  • What's an appropriate number of members for the Council? ArviZ has 7. I don't know if we have that many people but I suspect I'm not aware of the drawbacks of having a small council.
  • How do we decide who's a Core contributor a who's not? I guess it depends on merge permissions right now?
  • Is there anything you would remove from the document?
  • Is there anything you would like to add?

This is a very first draft, everything can be discussed.

Tagging all of you because I mentioned this to you at some point in time:

@aloctavodia @ahartikainen @ColCarroll @canyon289 @juanitorduz @junpenglao @tyarkoni @GStechschulte @zwelitunyiswa

Anyone else seeing this and wanting to participate, feel free to comment! You're more than welcomed.

I'm leaving this as it is for 7 days to collect feedback and ideas. Then we can start iterating.

[codecov-commenter]

Codecov Report

Merging #709 (355a48f) into main (e53f8da) will decrease coverage by 0.06%.
Report is 9 commits behind head on main.
The diff coverage is n/a.

❗ Current head 355a48f differs from pull request most recent head c8764da. Consider uploading reports for the commit c8764da to get more accurate results

@@            Coverage Diff             @@
##             main     #709      +/-   ##
==========================================
- Coverage   89.56%   89.50%   -0.06%     
==========================================
  Files          44       44              
  Lines        3525     3526       +1     
==========================================
- Hits         3157     3156       -1     
- Misses        368      370       +2     

see 3 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[twiecki]

I wonder if a council isn't overkill. A BDFL structure with core members I think is a better fit for a project of this size, and as core members grow, BDFL can be replaced with a council. Any reason you don't want a BDFL?

Having said that, I also don't think it's problematic other than creating (unnecessary) overhead.

[tomicapretto]

maybe all core contributors are part of the council? that way we don't have to maintain two separate things. I think this is similar to how R Core works (I couldn't find any proper governance online)

[canyon289]

CC @OriolAbril whos great at this stuff

[aloctavodia]

I am also in favor of a council and against a BDFL.

The document refers to Bambi or Bambi project and then mentions that "The Project ... hosted in public GitHub repositories under the bambinos GitHub organization. "

Is this governance only for Bambi or it will include formulae and kulprit? I think it is better to include the 3 projects as they are closely related and small.

[tomicapretto]

Is this governance only for Bambi or it will include formulae and kulprit? I think it is better to include the 3 projects as they are closely related and small.

I agree, it should apply to the three projects.And I envision that if we happen to add another project to the organization, it will be intimately related to Bambi, so it would apply for that other case too.

[canyon289]

The number of council members is important. I suggest an odd number to avoid ties

[OriolAbril]

The number of council members doesn't really matter. The voting process is +1, 0 or -1, so ties are difficult yet possible independently of the number of council members. I'd recommend a range like 3-5 or something similar.

[canyon289]

Identify core contributors first through some critieria. Examples are asking anyone that's contributed to self nominate, that way you can start with folks who are involved and actively interested.

[OriolAbril]

I also prefer a council model, but I think the most important thing is not that but setting the culture and drafting the content and its layout to aim for the council/bdfl to be as uninvolved as possible.

I'm not aware of the drawbacks of having a small council.

We did tinker with this a bit when defining ArviZ governance and it shouldn't be a disastrous default, but yYou might want to update the threshold percentages for votes. Current line 206 says at least 60% yes and no more than 20% no. For 3 people this means a vote passes only if there are 3 yes or 2 yes and 1 neutral. Anything else is not enough. No votes have a lot of weight as they go against a proposal o nomination (which is done by a trusted contributor, hence the obligation to reasoning), so 2 yes and 1 no would not be enough for example. With 4 people, 3 yes and 1 no would also not be enough for the vote to pass.

How do we decide who's a Core contributor a who's not? I guess it depends on merge permissions right now?

As @canyon289 commented somewhere, not necessarly right now. You can take that as a start but also have a call for self-nominations or something similar. What really matters is that after this process, their permissions (or the governance) are updated.

I copied this from PyMC and ArviZ

They are more different than it initially appears, both on paper and in practice. It looks like you took ArviZ one, here are some examples in case you want to further discuss one of them:

• Recurrent contributor status is public in ArviZ, secret in PyMC
• It isn't very clear who can vote on ArviZ council elections (we didn't really have the discussion about who votes after the first election but it was even considered for the whole community to vote, keeping only core contributors as eligible), in PyMC it is and only core contributors do
• All core contributors get merge permissions in ArviZ even if they don't need them, not in PyMC, it depends on their teams
• Differences in handling institutional partners and sponsors (which is currently missing completely from bambi's governance)

[OriolAbril]

The number of council members doesn't really matter. The voting process is +1, 0 or -1, so ties are difficult yet possible independently of the number of council members. I'd recommend a range like 3-5 or something similar.

[tomicapretto]

After this is merged we need to open an issue ticket to add people to the recurring contributor list and emeritus team members.

[GStechschulte]

Thanks for initiating this @tomicapretto. My knowledge on this subject is lacking, but it looks good to me 👍🏼

[canyon289]

The only thing I see missing now is actual enforcement action. Doesnt need to be part of this governance doc, but somewhere it should be written that council can decide to ban anyone if theyre causing issues