Governance¶
The purpose of this document is to formalise the governance process used by the aeon
project, to clarify how decisions are made and how the various elements of our community
interact. Our goal is to ensure a transparent, democratic, and inclusive decision-making
process that empowers all community members to contribute to the project.
aeon is a community-owned and community-run project. Anyone with an interest in the
project can join the community, contribute to the project design and participate in the
decision-making process.
This document establishes the decision-making structure used by aeon which strives to
find consensus from the community, while avoiding any deadlocks. Our decision-making
process involves different roles, each with specific responsibilities.
Roles¶
Contributors¶
Contributors are community members who have contributed in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms – not only code – as detailed in the contributing guide. Contributors play a crucial role in shaping the project through participating in discussions and influencing the decision-making process.
Supporting Developers¶
Supporting developers are contributors who have been nominated by a core developer
and granted write access to the aeon repository. No vote is required for this role,
but the nominator must notify the Core Developers and create a Pull Request.
Supporting developers can have their access revoked at any time by a core developer
if it is determined that they are abusing this access. Access will also be removed
after 6 months of inactivity.
Core Developers¶
Core developers are community members that have made significant contributions and are
trusted to continue the development of the project and engage with its community.
Core developers are granted write access to the aeon repository and voting rights
on all project decisions. They are expected to review code contributions
and engage with topics or code they are knowledgeable about.
New core developers are nominated by existing core developers and are subject to a two-thirds majority vote of voting core developers. Core developers are expected to maintain a reasonable amount of engagement with the project. Developing code, interacting with contributions and engaging with the broader community are all valid contributions for core developers.
Core developers who no longer want or are able to engage with the project are expected
to resign. Core developers may lose their role after a year of inactivity with no
contributions (see above) and engagement with fellow developers. If this lack of
engagement has been demonstrated, another core developer can suggest removal and create
a pull request on the aeon repository. The removal will complete if this pull request
is successfully merged.
Workgroups¶
Extra responsibilities are delegated to workgroups, which are groups of contributors with a core developer lead. Workgroups are responsible for specific areas of the project and are expected to manage and make decisions in their area of responsibility. Workgroups are expected to be transparent about their activities and decisions, and to engage with the community where possible.
Membership of workgroups and the leadership position of a workgroup is subject to a two-thirds majority vote of core developers. Workgroup members unable to fulfill their responsibilities are expected to resign from the workgroup. It is the responsibility of the workgroup lead to safeguard access to relevant project resources and accounts.
Infrastructure Workgroup¶
The infrastructure workgroup maintains the infrastructure of aeon to ensure the
smooth running of the project. This includes ensuring the website remains online, that
CI remains functional and other related tasks.
The infrastructure workgroup maintains ownership of the aeon GitHub organisation and
ReadTheDocs account.
Release Management Workgroup¶
The release management workgroup manages aeon releases. This includes deciding on
release schedules, managing release candidates and publishing releases.
The release management workgroup maintains ownership of the aeon PyPi project and
conda feedstock.
Finance Workgroup¶
The finance workgroup is responsible for managing the project finances. This includes approving any project expenses and managing any finance related accounts.
Communications Workgroup¶
The role of the communications workgroups is to interact with the broader community
through the aeon social network accounts and discussion forums. It is the
responsibility of the communications workgroup to manage and maintain the aeon
LinkedIn, Medium blog, Discord and other relevant communications accounts.
The communications team maintains access to social networking accounts and is
responsible for managing access to the aeon email address. To help manage
GitHub discussions, the communication workgroup is given triage access to the aeon
GitHub repository.
Code of Conduct Moderators¶
The Code of Conduct Moderators (CoCM) consists of contributors tasked with making sure
aeon remains a welcoming and inclusive community. CoCM responsibilities include
ensuring the Code of Conduct (CoC) remains up to date, keeping contact with the
NumFOCUS Code of Conduct Workgroup and managing reports of breaking the CoC.
CoCM members are expected to review reports of CoC violations, refer cases to the
NumFOCUS workgroup when applicable and make decisions on report actions while
consulting with the greater community.
Any CoCM members involved in a CoC report or CoCM members which have a conflict of
interest regarding the report are expected to recuse themselves from the process. The
CoCM is given triage access to the aeon GitHub repository to moderate discussions if
necessary.
Decision-Making Process¶
Decisions about the future of the project are announced publicly to allow discussion with all members of the community. The whole process from proposal to implementation is fully visible, apart from topics considered sensitive. All non-sensitive project management discussion takes place on the project Discord and/or the issue tracker. Occasionally, sensitive discussion and votes such as appointments will occur in private Discord channels or meetings.
For most decisions, a consensus seeking process of all interested contributors is used. Contributors try to find a resolution that has no open objections among core developers. If a reasonable amount of time (at least 7-days for non-trivial changes) has passed since the last change to a proposed contribution, the proposal has at least one approval (+1), and no rejections (-1) from core developers, it can be approved by lazy consensus. If a change is rejected, it is expected that an explanation and description of conditions (if any) to withdraw the rejection is provided.
At any point during the discussion, any core developer in favour of a change can call for a vote, which will conclude two weeks from the call for the vote. Any vote to bypass a rejection from a core developer must be backed by an AEP (see the following section). For major contributions (such as a new module or major framework redesigns) an AEP may be requested without a rejection or vote. In the event a vote is called, the proposal must receive a two-thirds majority of voting core developers to be approved.
All changes to the aeon code or documentation should be done via Pull Request.
By default, push rights to the main GitHub branch are restricted for all core developers.
In emergencies, the infrastructure workgroup may temporarily revoke the branch
protection for group members and make direct commits, but this should happen only in
emergencies where harm will come to the project unless timely action is taken.
Enhancement Proposals¶
For contentious decision-making votes (not including appointment votes), a proposal should be made public for discussion before the vote. It is recommended that this proposal is made as a consolidated document, in the form of an “aeon Enhancement Proposal” (AEP). The AEP template is available here, but the use of said template is not a requirement. A detailed issue or pull request can substitute an AEP if all parties believe it is enough, but a more formal proposal can be requested by any core developer.
Having a rejection on a pull request does not require the creation of an AEP and further discussion to find consensus can be held, but one must be created prior to any vote to bypass a rejection.
A vote does not have to be called for an AEP to be submitted. If a contributor wants to make a more formal proposal or believes a change will be controversial, an AEP can be submitted to the community for discussion and comment.
Acknowledgements¶
Portions of this document were adapted from or inspired by the following projects governance documents: