Governance#
Overview#
predictably is a consensus-based project that is part of the predictably
community. Anyone with an interest in the project can join the community, contribute
to the project, and participate in the governance process. The rest of this document
describes how that participation takes place, which roles we have in our community,
how we make decisions, and how we acknowledge contributions.
Note
As a new project, predictably has adopted a provision governance structure.
We expect this to change as the project grows.
Code of Conduct#
The predictably project believes that everyone should be able to participate
in our community without fear of harassment or discrimination (see our
Code of Conduct guide).
Roles#
predictably distinguishes between the following key community roles:
Contributors#
Anyone is welcome to contribute to the project. Contributions can take many forms – not only code – as detailed in the contributing guide
For more details on how we acknowledge contributions, see the acknowledging contributions section below.
All of our contributors are listed under the contributors section of our documentation.
Core developers#
Core developers are contributors who have shown dedication to project’s development through ongoing engagement with the community ( see the core development team).
The core developmer team helps ensure the smooth functioning of the project by:
ongoing engagement with community
managing issues and Pull Requests
closing resolved issues
reviewing others contributions in accordance with the project reviewers guide)
approving and merging Pull Requests
participating in the project’s decision making process
nominating new core developers and steering committee members
Any core developer nominee must receive affirmative votes from two-thirds of existing core developers over the course of a 5 business day voting period.
Core developers can remain in their role for as long as they like as long as they continue to perform the role’s duties. Core developers who no longer want to perform the role’s duties can resign at any time, while core developers that become inactive for a 12-month period will move to a “former” core developer status.
Steering Committee#
Steering Committee (SC) team members are core developers with additional rights and responsibilities for maintaining the project, including:
providing technical direction
strategic planning, roadmapping and project management
managing community infrastructure (e.g., Github repository, etc)
fostering collaborations with external organisations
avoiding deadlocks and ensuring a smooth functioning of the project
SC nominees must be nominated by an existing core developer and receive affirmative votes from two-thirds of core developers and a simple majority (with tie breaking) of existing SC members.
Like core developers, SC members who continue to engage with the project can serve as long as they’d like. However, SC members who do not actively engage in their SC responsibilities are expected to resign. In the event, a SC member who no longer engages in their responsibilities does not resign, the remaining SC members and core developers can vote to remove them (same voting rules as appointment).
Decision making#
The predictably community tries to take viewpoints and feedback from all
community members into account when making decisions in order to arrive at
consensus decisions.
To accomplish this, this section outlines the decision-making process used by the project.
Where we make decisions#
Most of the project’s decisions and voting takes place on the project’s issue tracker, pull requests or an enhancement proposal. However, some sensitive discussions and all appointment votes occur on private chats.
Core developers are expected to express their consensus (or veto) in the medium where a given decision takes place. For changes included in the Project’s issues and Pull Requests, this is through comments or Github’s built-in review process.
Types of decisions#
The consensus based decision-making process for major types of project decisions are summarized below.
Type of change |
Decision making process |
|---|---|
Code additions or changes |
|
Documentation changes |
|
Changes to the API design, hard dependencies, or supported versions |
Lazy consensus based on an PREP |
Changes to predictably’s governance |
Lazy consensus based on an PREP |
Appointment to core developer or steering committee status |
Anonymous voting on slack |
How we make decisions#
Lazy consensus#
Changes are approved “lazily” when after reasonable amount of time the change receives approval from at least one core developer and no rejections from any core developers.
This is approach is designed to make it easier to add new features and make changes to the project as it develops. To make sure things run smoothly, core developers should make sure that the reasonable time other community members have to provide feedback on the changes is commensurate to the scope of the change. For changes to the API or other larger changes, core developers should actively solicit feedback from their peers.
predictably enhancement proposals#
Project design decisions have a more detailed approval process,
commensurate with their broader impact on the project. Any changes
to the project’s core API design, hard dependencies or supported versions
should first be presented in a predictably enhancement proposal (PREP).
See the developer guide for more information on creating a PREP.
Resolving conflicts#
When consensus can’t be found lazily, the project’s core developers will vote to decide how to proceed on an issue. Any core developers can call for a vote on a topic. A topic must receive two-thirds of core developer votes cast (abstentions are allowed) via comments on the relevant issue or Pull Request over a 5 day voting period.
In the event a proposed change does not gather the necesssary votes, then:
The core developer who triggered the vote can choose to drop the issue
The proposed changes can be escalated to the SC, who will seek to learn more about the team member viewpoints, before bringing the topic up for a simple majority vote of SC members.
Acknowledging contributions#
The predictably project values all kinds of contributions and the
development team is committed to recognising each of them fairly.
The project follows the all-contributors specification to recognise all contributors, including those that don’t contribute code. Please see our list of all contributors.
Please let us know or open a PR with the appropriate changes to predictably/.all-contributorsrc if we have missed anything.
Note
predictably is an open-source project. All code is contributed
under our open-source
license.
Contributors acknowledge that they have rights to make their contribution
(code or otherwise) available under this license.
Outlook#
As with other parts of the project, the governance may change as the project matures. Suggestions on potential governance changes are also welcome.
References#
Our governance model is inspired by various existing governance structures. In particular, we’d like to acknowledge: