Ibis's governance is inspired by many open source projects that have come before it, including but not limited to Apache Arrow, Substrait, Dask and others.
The closest concrete model to Ibis's governance is the liberal contribution model.
A major point in that model is:
the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions.
Another important point from that model is:
Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible.
The project artifacts are the code and documentation that reside in the
collection of git repositories under the
ibis-project GitHub organization.
The following categories are loose categories of people involved with the Ibis project.
These categories are not mutually exclusive.
Users are people using Ibis.
A contributor is someone who contributes code or documentation to the project. The primary way someone contributes these artifacts is through GitHub Pull Requests.
After a period of time, contributors are eligible to become committers.
A committer is someone who has the ability to make commits to the project without the approval of other committers or steering committee members, which includes the ability to approve and merge pull requests.
Pull requests should have at least one approving committer that isn't the person who created the PR, or a stated reason why a pull request bypassed approval.
Committers are responsible for things like:
- Code review
- Ensuring that CI remains green
- Helping on-board new contributors
- Maintaining existing code
Committers who have not made a commit to one or more repositories under the
ibis-project organization for a period of time will be contacted to determine
whether they are still interested in participating in the project and if not,
may have their commit rights removed.
Decision-making power leans towards those people who are currently active in the project.
To become a committer, a person must have sustained contributions to one or more projects in the organization. There is no explicit duration over which this must happen.
Candidates are nominated by a steering committee member, and must have approval from at least 2 other steering committee members.
Nominations should be made and discussed in a GitHub Issue.
A steering committee member is a committer that shows commitment to the long-term health of the Ibis project. In addition to the responsibilities of committers, committee members are responsible for things like:
- Nominating others for committership and steering committee membership
- Handling security reports in a timely manner
- Enforcing the code of conduct
The current steering committee members are:
- Phillip Cloud (@cpcloud)
- Jim Crist-Harif (@jcrist)
- Gil Forsyth (@gforsyth)
- Tim Sweña (@tswast)
- Krisztián Szűcs (@kszucs)
Steering committee members must already be committers.
Additionally, steering committee members must have been a committer for at least six months after becoming a committer and show commitment to long-term health of the project.
Candidates are nominated by a steering committee member, and must have approval from at least 2 other steering committee members.
Nominations should be made and discussed in a GitHub Issue.
Major technical decisions should be made in public using GitHub Issues.
Announcements of proposed major technical decisions can also be sent to the Zulip #general stream to help gather feedback.
Decisions around governance itself should be discussed in
ibis-project/governance's
issues or in pull requests
proposing changes to governance.
When in doubt prefer https://github.com/ibis-project/ibis/issues.
Decision-making should be done by seeking consensus from as many community perspectives as possible.
The community should be given at least one week to respond to a proposed decision.
Large, sweeping decisions must include the support of at least two steering committee members.
Any content whose majority is generated by an AI, large language model or otherwise non-human entity must have a visible disclaimer stating such tools were used in the creation of the content.
Use of GitHub Copilot during day to day development (for example, Python docstring generation, function signature generation) need no such disclaimer.