The Bambi Project (The Project) is an open source software project. The goal of The Project is to develop open source software and deploy open and public content and services for reproducible, exploratory and interactive computing. The main focus of The Project is in scientific and statistical computing. The Software developed by The Project is released under OSI approved open source licenses, developed openly and hosted in public GitHub repositories under the bambinos GitHub organization. Examples of Project Software include the Bambi library and its documentation. The Services run by The Project consist of public websites and web-services that are hosted at https://bambinos.github.io and subdomains.
The Project is developed by a team of distributed developers, called Contributors. Contributors are individuals who have contributed code, documentation, designs or other work to one or more Project repositories. Anyone can be a Contributor. Contributors can be affiliated with any legal entity or none. Contributors participate in the project by submitting, reviewing and discussing GitHub Pull Requests and Issues and participating in open and public Project discussions on GitHub and Slack. The foundation of Project participation is openness and transparency.
There have been many Contributors to the Project, whose contributions are listed in the logs of any of the repositories under the bambinos organization.
The Project Community consists of all Contributors and Users of the Project. Contributors work on behalf of and are responsible to the larger Project Community and we strive to keep the barrier between Contributors and Users as low as possible.
- General Contributors
- Recurrent Contributors
- Core Contributors (of which Council members are also a part of)
- Steering Council
Anyone working with Bambi has the responsibility to personally uphold the Code of Conduct. Core Contributors have the additional responsibility of enforcing the Code of Conduct to maintain a safe community.
Recurrent Contributors are those individuals who contribute recurrently to the project and can provide valuable insight on the project. They are therefore actively consulted and can participate in the same communication channels as Core Contributors. However, unlike Core Contributors, Recurrent Contributors don't have voting, managing or writing rights.
In practice, this translates in participating from private team discussions (i.e. in Slack or live meetings) but not being able to vote in elections for the Council members nor having commit rights on GitHub.
The Recurrent Contributor position will often be an intermediate step for people in becoming Core Contributors once their contributions are frequent enough and during a sustained period of time. But it is also an important role by itself for people who want to be part of the project on a more advisory-like role, as they for example might not have the time availability or don't want the responsibilities that come with being a Core Contributor.
The process for new people to join the project as recurrent contributors is described at New Contributor Nominations and Confirmation Process. Recurrent or Core Contributors can nominate anyone to join the project as a recurrent contributor.
The list of Recurrent Contributors will be created after Core Contributors group is defined.
Core Contributors are those who have provided consistent and meaningful contributions to Bambi. These can be, but are not limited to, code contributions, community contributions, tutorial development etc. Core Contributors will be given the ability to manage the Bambi GitHub repository, including code merges to main. This does not necessarily mean Core Contributors must submit code, but more so signifies trust with the project as a whole.
The process for new people to join the project as Core Contributors is described at New Contributor Nominations and Confirmation Process. Only Recurrent Contributors are eligible to become Core Contributors, and only Core Contributorscan nominate them.
- Enforce Code of Conduct
- Maintain a check against Council
- Gabriel Stechschulte (@gstechschulte)
- Osvaldo Martin (@aloctavodia)
- Ravin Kumar (@canyon289)
- Tomás Capretto (@tomicapretto)
The Project will have a Steering Council that consists of Core Contributors who have produced contributions that are substantial in quality and quantity, and sustained over at least one year. The overall role of the Council is to ensure, taking input from the Community, the long-term well-being of the project, both technically and as a community.
During the everyday project activities, Council Members participate in all discussions, code review and other project activities as peers with all other Contributors and the Community. In these everyday activities, Council Members do not have any special power or privilege through their membership on the Council. However, it is expected that because of the quality and quantity of their contributions and their expert knowledge of the Project Software and Services that Council Members will provide useful guidance, both technical and in terms of project direction, to potentially less experienced contributors.
The Council will have between 4 and 7 members. No more than 2 Council Members can report to one person or company (including Institutional Partners) through employment or contracting work (including the reportee, i.e. the reportee + 1 is the max).
Council Members will have the responsibility of
- Removing members, including Council Members, if they are in violation of the Code of Conduct or don't comply with this governance document.
- Making decisions when regular community discussion does not produce consensus on an issue in a reasonable time frame. See Council Decision Making Process page for more details.
The Council may choose to delegate these responsibilities to sub-committees. If so, Council members must update this document to make the delegation clear.
Individual Council Members do not have the power to unilaterally wield these responsibilities. The Council as a whole must jointly make these decisions. In other words, Council Members are first and foremost Core Contributors, but only when needed they can collectively make decisions for the health of the project.
- Council members term limits are 4 years, after which point their seat will come up for reelection.
- Each year on April 7th council members will be asked to restate their commitment to being on the Council.
- Attempts should be made to reach every council member over at least 2 communication media. For example: email, Slack, phone, or GitHub.
- If a Council Member does not restate their commitment their seat will be vacated.
- Inactivity can be determined by lack of substantial contribution, including votes on council, code or discussion contributions, contributions in the community or otherwise.
- In the event of a vacancy in the council, an election will be held to fill the position.
- There is no limit on the number of terms a Council Member can serve
The current Council members are:
- Gabriel Stechschulte (@gstechschulte)
- Osvaldo Martin (@aloctavodia)
- Tomás Capretto (@tomicapretto)
Current Contributors can nominate candidates to become Contributors by requesting so in a GitHub issue, constraints on eligibility are detailed in the role descriptions. If nominated candidates accept their nomination (explicit comment approving nomination on the issue or "thumbs-up" emoji on the same issue), then they can be considered by the Council: on the first of the month following a nomination, the Council will vote on each nominee using this process.
In the case of recurring contributors, the nomination and voting process can be replaced by a somewhat similar selection process. Thus, for example, GSoC interns are considered recurrent contributors once accepted; similarly, contractors hired thanks to grants like CZI EOSS or GSoD ones are also considered recurrent contributors once hired.
Voting will be private with results published on the issue ticket. In the case of a rejection, results must include the reasons behind the decision (e.g. the time since starting to contribute is deemed too short for now). The candidate would then have to wait 3 months to be considered again.
By and large we expect the decisions in Bambi to be made ad hoc and require little formal coordination and with the community at large. However, for controversial proposals and new Core Contributors the council may need to intervene to make the final decision in a group vote.
Core Contributors can call for a vote to resolve a target issue they feel has been stale for too long and for which informal consensus appears unlikely. For a vote to be called, the target issue must be at least 2 months old.
To do so, they have to open a proposal issue ticket labeled "Council Vote". The proposal issue should contain a link to the target issue and a proposal on how to resolve it. Proposals should include a statement making clear what it means to "agree" or to "disagree".
Before voting starts, at least 3 days will be left for Core Contributors to raise doubts about the proposal's phrasing, no extra discussion will take place in the proposal issue. Proposal issues should be locked from creation to prevent attracting discussion from people not familiar with the decision process.
- Each Council Member will vote either "Yes", "No", or "Neutral".
- It is recommended that all Council Members expose their reasons when voting. "No" votes, however, must list the reasons for disagreement. Any "No" vote with no reason listed will be considered a "Neutral" vote.
- An absence of vote is considered as "Neutral".
- Voting will remain open for at least 3 days.
- For the proposal to pass, at least 60% of the council must vote "Yes", and no more than 20% can vote "No".
For decisions about the project the Council will perform it directly on the proposal issue. For decisions about people, such as electing or ejecting Core Contributors, the Council will vote privately. However the decision will be posted publicly in an issue ticket.
Unless specifically required, all Council discussions and activities will be between public (GitHub), and partially public channels (Slack) and done in collaboration and discussion with the Core Contributors and the Community. The Council will have a private channel that will be used sparingly and only when a specific matter requires privacy. When private communications and decisions are needed, the Council will do its best to summarize those to the Community after eliding personal/private/sensitive information that should not be posted to the public internet.
It is expected that Council Members will be employed at a wide range of companies, universities and non-profit organizations. Because of this, it is possible that Members will have conflict of interests. Such conflict of interests include, but are not limited to:
- Financial interests, such as investments, employment or contracting work, outside of The Project that may influence their work on The Project.
- Access to proprietary information of their employer that could potentially leak into their work with the Project.
All members of the Council shall disclose to the rest of the Council any conflict of interest they may have. Members with a conflict of interest in a particular issue may participate in Council discussions on that issue, but must recuse themselves from voting on the issue.
- Must be core contributor for at least one year
- Nominations are taken over a public GitHub issue ticket over the course of 2 weeks
- Only Core Contributors may nominate folks
- Self Nominations are allowed
- At the conclusion of the 2 weeks, the list of nominations is posted on the ticket and this ticket is closed.
- Voting occurs over a period of at least 1 week, at the conclusion of the nominations. Voting is blind and mediated by either an application or a third party like NumFOCUS. Each voter can vote zero or more times, once per each candidate. As this is not about ranking but about capabilities, voters vote on a yes/neutral/no basis per candidate -- "would I trust this person to lead Bambi?".
- Candidates are evaluated independently, each candidate having 60% or more of yes votes and less or equal than 20% of no votes is chosen. If the number of chosen candidates is >=4 and <=10 all candidates are confirmed and the election process stops here.
- In the event that either not enough or too many candidates were confirmed, candidates are ranked by interpreting yes=+1, neutral=0 and no=-1. If too many candidates were confirmed, the 10 candidates with higher rank are elected. If not enough candidates were chosen, the 4 candidates with higher rank are elected.
- In the event of a tie there will be a runoff election for the tied candidates. To avoid further ties and discriminate more among the tied candidates, this vote will be held by Majority Judgment (MJ): for each candidate, voters judge their suitability for office as either "Excellent", "Very Good", "Good", "Acceptable", "Poor", or "Reject". Multiple candidates may be given the same grade by a voter. The candidate with the highest median grade is the winner.
- If more than one candidate has the same highest median-grade, the MJ winner is discovered by removing (one-by-one) any grades equal in value to the shared median grade from each tied candidate's total. This is repeated until only one of the previously tied candidates is currently found to have the highest median-grade.
- If ties are still present after this second round, the winner will be chosen at random.
Each person tied will pick an integer number in the
[1, 100]interval and send it privately to the third party mediating the election. After receiving all the numbers, said third party will draw a random integer from random.org. The person with the closest circular distance, defined asmin(|a-b|, 100-|a-b|), will be selected. This process will be repeated as many times as necessary as there may be ties resulting from candidates choosing the same number. - At the conclusion of voting, all the results will be posted. And at least 24 hours will be left to challenge the election result in case there were suspicions of irregularities or the process had not been correctly carried out.
- In exceptional circumstances, council members as well as core contributors may remove a sitting council member via a vote of no confidence. Core contributors can also call for a vote to remove the entire council -- in which case, Council Members do not vote.
- A no-confidence vote is triggered when a core team member (i.e Council member or Core contributor) calls for one publicly on an appropriate project communication channel, and two other core team members second the proposal. The initial call for a no-confidence vote must specify which type is intended -- whether it is targeting a single member or the council as a whole.
- The vote lasts for two weeks, and the people taking part in it vary:
- If this is a single-member vote called by Core contributors, both Council members and Core contributors vote, and the vote is deemed successful if at least two thirds of voters express a lack of confidence.
- If this is a whole-council vote, then it was necessarily called by Core contributors (since Council members can’t remove the whole Council) and only Core contributors vote. The vote is deemed successful if at least two thirds of voters express a lack of confidence.
- If this is a single-member vote called by Council Members, only Council Members vote, and the vote is deemed successful if at least half the voters express a lack of confidence. Council Members also have the possibility to call for the whole core team to vote (i.e Council members and Core contributors), although this is not the default option. The threshold for successful vote is also at 50% of voters for this option.
- If a single-member vote succeeds, then that member is removed from the council and the resulting vacancy can be handled in the usual way.
- If a whole-council vote succeeds, the council is dissolved and a new council election is triggered immediately.
- Core contributors can be ejected through a simple majority vote by the council. Council members vote "Yes" or "No".
- Upon ejecting a core contributor the council must publish an issue ticket, or public document
detailing the
- Violations
- Evidence if available
- Remediation plan (if necessary)
- Signatures majority of council members to validate correctness and accuracy
Core contributors can also voluntarily leave the project by notifying the community through a public means or by notifying the entire council.
Unless they request otherwise, they will be listed on the Emeritus team members page.
Traditionally, project leadership was unstructured but primarily driven by a subset of Core Contributors whose active and consistent contributions have been recognized by their receiving "commit rights" to the Project GitHub repositories. In general all Project decisions are made through consensus among the Core Contributors with input from the Community.
While this approach has served us well, as the Project grows and faces more legal and financial decisions and interacts with other institutions, we see a need for a more formal governance model. Moving forward The Project leadership will consist of a Council. We view this governance model as the formalization of what we are already doing, rather than a change in direction.