The official version of this document, along with a list of individuals and institutions in the roles defined in the sections below, is contained in The Project Governance Repository at:
https://github.com/bqplot/governance
The BQplot Project (The Project) is an open source software project. The goal of The Project is to develop open-source software for exploratory and interactive data visualization.
The Software developed by The Project is released under the Apache (or similar) open source license, developed openly and hosted in public GitHub repositories under the bqplot GitHub organization. Examples of Project Software include the bqplot package, the xplot C++ backend to bqplot, the bqscales project, etc.
The Project is developed by a team of distributed developers, called Contributors. Contributors are individuals who have helped the project with code contributions, documentation, designs, community management, etc. 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, Google+, Hackpad, Gitter chat rooms and mailing lists. The foundation of Project participation is openness and transparency.
Here is a list of the current Contributors to the main BQplot repository:
https://github.com/bqplot/bqplot/graphs/contributors
There are also many other Contributors listed in the logs of other repositories of the bqplot projects.
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.
This section describes the governance and leadership model of The Project.
The foundations of Project governance are:
- Openness & Transparency
- Active Contribution
- Institutional Neutrality
The Project leadership consists of a Steering Council.
The Project will have a Steering Council that consists of Project 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, through working and taking input from the Community, the long-term well-being of the project, both technically and as a community.
During the day-to-day Project activities, Council Members participate in discussions, code review and other Project activities as peers with all other Contributors and the Community. In these day-to-day activities, Council Members do not have any special power or privilege through their membership on the Council. Most day-to-day activities do not block on the Steering Council. However, it is expected that because of the quality and quantity of their contributions and their expert knowledge, Council Members will provide useful guidance, both technical and in terms of Project direction, to potentially less experienced contributors.
The Steering Council and its Members play a special role in certain situations. In particular, the Council may:
- Make decisions about the overall scope, vision and direction of the project.
- Make decisions about strategic collaborations with other organizations or individuals.
- Develop funding sources and spending money.
- Make decisions when regular community discussion does not produce consensus on an issue in a reasonable time frame.
- Mediate significant conflict between community participants regarding the direction of the project
- Resolve code of conduct issues
- Grant or revoke privileges (e.g., releasing, committing, triaging) to Project Contributors.
- Mentor Project Contributors
- Make decisions on major architectural or backward-incompatible changes, as well as major releases of The Project.
The Steering Council may delegate some of the above responsibilities to other Project Contributors or committees.
To become eligible for being a Steering Council Member, an individual must be a Project Contributor who has produced contributions that are substantial in quality and quantity, and sustained over at least one year. Potential Council Members are nominated by existing Council Members and voted upon by the existing Council. Based on a successful vote, the newly elected Member is invited to serve in that capacity. The Council is initially selected from the set of existing Core Developers who, as of 2020, have been significantly active over the last year.
When considering potential Members, the Council will look at candidates with a comprehensive view of their contributions. This will include, but is not limited to, code, code review, infrastructure work, mailing list and chat participation, community help/building, education and outreach, design work, etc. We are deliberately not setting arbitrary quantitative metrics (like “100 commits in this repo”) to avoid encouraging behavior that plays to the metrics rather than The Project’s overall well-being. We want to encourage a diverse array of backgrounds, viewpoints and talents in our team, which is why we explicitly do not define code as the sole metric on which Council membership will be evaluated.
Council membership terms last two years. Initial terms will be staggered so that there is a new selection of Steering Council Members every year. Council Members can serve multiple consecutive terms.
When a Steering Council Member term ends, or when they leave the Steering Council, a new Steering Council will be nominated.
The Steering Council will have regular meetings at least monthly. Council Members should participate in 3/4 of the regular meetings, and engage regularly in discussions and offline votes on the Steering Council mailing list.
If a Council member becomes inactive in The Project for a long period of time, they may be considered for removal from the Council. Before removal, the inactive Member will be approached by the other members of the Council to see if they plan on returning to active participation. If not, they will be removed immediately upon a Council vote.
If they plan on returning to active participation soon, they will be given a grace period of one year. If they do not return to active participation within that time period, they will be removed by vote of the Council without further grace period. All former Council Members can be considered for membership again at any time in the future, like any other Project Contributor.
Retired Council Members will be listed on the project website, acknowledging the period during which they were active in the Council.
The Council reserves the right to eject current Members, if they are deemed to be actively harmful to the project’s well-being and attempts at communication and conflict resolution have failed.
It is expected that the 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 a range of interests related to the project, and possibly conflicts 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.
- An issue where the person privately gains an advantage from The Project resources, but The Project has no gain or suffers a disadvantage.
All members of the Council shall disclose to the rest of the Council any interest they may have as it relates to the project. The Council will evaluate whether it constitutes a conflict. 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.
Unless specifically required, all Council discussions and activities will be public and done in collaboration and discussion with the Project Contributors and Community. The Council will have a private mailing list 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.
The Steering Council is the primary leadership for the project. No outside institution, individual or legal entity has the ability to own, control, usurp or influence the project other than by participating in the Project as Contributors and Council Members. However, because institutions are the primary funding mechanism for the project, it is important to formally acknowledge institutional participation in the project. Such institutions are Institutional Partners. Institutional Partners include recognized legal entities that employ at least one Steering Council Member participating in Council work as part of their official duties at the Institutional Partner.
Changes to the governance documents are submitted via a GitHub pull request to The Project's governance documents GitHub repository at https://github.com/bqplot/governance. There are two phases to the process:
The discussion phase begins when the person first opens a pull-request. During this time, the pull-request must be in a draft state. The pull request is refined in response to public comment and review, with the goal being consensus in the community.
The pull request author may call a vote when they believe enough feedback and iteration has occurred. This is triggered by moving the pull request from the draft state to an active state. This triggers the voting phase.
The voting phase begins when the PR enters an active state. The proposed changes in the pull request are frozen, and may not be substantively modified after voting has begun. During the voting phase, the Steering Council votes on whether the changes are ratified and the pull request merged (accepting the proposed changes) or that the pull request be closed without merging (rejecting the proposed changes).
All votes are limited in time to 4 weeks after the voting phase begins. At the end of 4 weeks, the proposal passes if at least 80% of the Steering Council has voted and 2/3 of the votes are in favor; otherwise the proposal does not pass. Prior to the four-week limit, if at least 80% of the Steering Council has voted in favor, the proposal passes. A council member may abstain from voting, which counts towards the 80% quorum requirement.