Pixie (The Project) is an open source software project. The goal of The Project is to develop open source software and enable out-of-the-box visibility into developer’s Kubernetes applications. The Software developed by The Project is released under the Apache 2.0 license and is developed openly and hosted in public Github/Phabricator Repositories under the PixieLabs organization. Examples of Project Software include the Pixie core library, Pixie Python API, Pixie Go API, and Pixie documentation.
The Project is developed by a distributed team of developers, called Contributors. Contributors are individuals who have contributed code, documentation, designs, user support, 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 Code Contributions and Issues and participating in open and public Project discussions on GitHub, JIRA, Phabricator, Slack, and mailing lists. The foundations of Project participation are openness and transparency.
Here is a list of some code Contributors to the main Pixie repository.
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 following structure will remain in place until May 2023, at which point at the sole discretion of the BDFL we will revisit the structure. The proposed future structure is a semi-democratic process for selecting project leadership.
The Project will have a BDFL (Benevolent Dictator for Life), who is currently Zain Asgar, and a Deputy BDFL, who is Michelle Nguyen. As Dictator, the BDFL has the authority to make all final decisions for The Project. As Benevolent, the BDFL, in practice chooses to defer that authority to the consensus of the community discussion channels and the Governance Board (see below). It is expected, and in the past has been the case, that the BDFL will only rarely assert their final authority. Because rarely used, we refer to BDFL’s final authority as a “special” or “overriding” vote. When it does occur, the BDFL override typically happens in situations where there is a deadlock in the Governance Board or if the Governance Board asks the BDFL to make a decision on a specific matter. The BDFL is chair of the Governance Board (see below) and may delegate their authority on a particular decision or set of decisions to any other Board member at their discretion.
The project will have a governance board that consists of two project members, two community members, and two end-user community members. The overall role of the Board is to ensure, working with the BDFLs and taking input from the Community, a long-term well-being of the project, both technically and as a community.
The Governance Board and its Members play a special role in certain situations. In particular, the Board may:
- Make decisions about the overall scope, vision and direction of the project.
- Make decisions about strategic collaborations with other organizations or individuals.
- Make decisions about specific technical issues, features, bugs and pull requests. They are the primary mechanism of guiding the code review process and merging pull requests.
- Make decisions about the Services that are run by The Project and manage those Services for the benefit of the Project and Community.
- Make decisions when regular community discussion doesn’t produce consensus on an issue in a reasonable time frame.
All community and end-user community member positions are appointed for 12-months and are expected to rotate under the consensus and discretion of the BDFLs.
To become eligible for a Community Member board position, an individual should meet some of the following criteria:
- Be a Project Contributor who has produced contributions that are substantial in quality and quantity.
- Sustain this development consistently over several months.
- Support the community through various activities (some examples below):
- code review
- answering user questions
- triaging bug reports
- participating constructively in broader conversations
- contributing to documentation
- maintaining infrastructure
- Demonstrate breadth by supporting the community outside of their particular work interests or sub-project
- Be civil in public discourse
We are currently looking to fill the position for two end-user community members! Please reach out to the Pixie project team to apply.
It is expected that the Governance Board and BDFL 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.
- 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 Governance Board, BDFL included, shall disclose to the rest of the Board any conflict of interest they may have. If the BDFL has recused themselves for a particular decision, they will appoint the deputy BDFL for that decision. If the deputy BDFL has also recused themselves for that decision, they will appoint a substitute BDFL.
In general, the Board makes decisions by lazy consensus with a minimum of participation based on the importance of the decisions to be made. Conversations happen on public GitHub or JIRA issues for most cases, and through private e-mail for more sensitive issues.
To make a decision the Board discusses the topic, a proposal is made, and a suitable wait time occurs for Board members to either agree or veto. By consensus we mean that any Board member can veto a decision with justification. By lazy we mean that not all Board members must participate, and that absence is interpreted as assent. By a minimum of participation we mean that we require the participation of a certain number of individuals based on the importance of the issue; for non-contentious issues a single Board member may move forward after a suitable time, while for contentious issues we will often require a few, often from different institutions.
Unless specifically required, all Board discussions and activities will be public and done in collaboration and discussion with the Project Contributors and Community. The Board 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 Board 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.
Changes to the governance documents are submitted via a GitHub/Phabricator pull request to The Project's governance document. The pull request is then refined in response to public comment and review, with the goal being consensus in the community. Since the BDFL holds ultimate authority in The Project, the BDFL has authority to act alone in accepting or rejecting changes.