StarlingX Initial Governance
The initial draft of this document with feedback from the reviewers is on this Etherpad.
The StarlingX project is governed according to the OpenStack Foundation's "four opens", which are open source, open design, open development and open community. Technical decisions are made by technical contributors, technical leaders and by a representative Technical Steering Committee. Our community is committed to diversity, openness, and encouraging new contributors and leaders to rise up.
StarlingX is both a development project and an integration project. It includes new services that provide important features and combines them with components from many other Open Source projects into a complete Edge Cloud solution. To help manage the complexity of the project, we have divided the project up into several sub-projects, each with project and technical leadership, to help distribute the overall work and to acknowledge in the community that there are multiple ways to contribute to the project. The sub-project lifecycle is managed by the project's Technical Steering Committee who approve the creation of new sub-projects and the retirement of sub-projects that are no longer active.
StarlingX is a brand new project and is in an initial "bootstrapping" phase in which the leadership positions will be volunteers. All leadership positions will transition to be elected by the project's Contributors within one year.
StarlingX defines the following roles for the project.
A Contributor to StarlingX is someone who has made a Contribution to the project within the last 12 months. Contributions can include merged code, test or document submissions, or serving in a leadership role as defined below. All Contributions are welcome and will be accepted based on their technical merit.
The project's Technical Steering Committee can grant Contributor status for other contributions at its discretion.
Contributors are eligible to vote in the elections for Technical Steering Committee positions and for the leadership roles described in this document. Contributors are also eligible to become members of the Technical Steering Committee and/or serve in a leadership role.
Core Reviewers are active Contributors and participants in a sub-project that have the additional responsibility to review the changes proposed to the sub-project, to ensure that approved changes are aligned with the project's design & architecture, and meet the project's quality requirements. Core Reviewers have the ability to approve code to be merged into the StarlingX repositories. Core Reviewers for a sub-project are appointed by the sub-project Technical Lead with input from other StarlingX Core Reviewers. Contributors can become Core Reviewers for multiple sub-projects.
A Technical Lead in StarlingX is a Core Reviewer who has additional responsibility for guiding the overall technical direction of one or more of the sub-projects, under the overall technical guidance of the Technical Steering Committee. Technical Leads are responsible for resolving disagreements between the sub-project's Contributors and Core Reviewers. A sub-project's Technical Lead should be included as a reviewer and approver for any Feature Specification that impacts their sub-project. The initial Technical Leads are appointed to one year terms at launch by the Technical Steering Committee but will be fully elected by the sub-project's Contributors on an annual basis. Technical Lead elections will be held in September of every year starting in 2019 and will be administered by the TSC or their delegates. Contributors can be Technical Leads for multiple sub-projects.
A Project Lead in StarlingX is an outside facing role for a StarlingX sub-project that is responsible for requirements gathering, tracking progress, reporting results, handling outside communication, serving as a project ambassador and facilitating the four opens within the sub-project. The Project Lead works with the Technical Lead and the sub-project team to break down large work items for the team into Stories and Tasks. The Project Lead can help guide Contributors to the work items most needed by the sub-project, as defined by the Project Priorities established by the Technical Steering Committee. The initial Project Leads are appointed to one year terms at launch by the Technical Steering Committee but will be fully elected by the sub-project's Contributors on an annual basis with the first election to be held in April 2019. Contributors can be Project Leads for multiple sub-projects.
The same person can become a Technical Lead and Project Lead for a StarlingX sub-project. That person's role would then be similar to an OpenStack PTL. The StarlingX project has split these roles to enable Technical Leaders to focus more of their attention on technical issues and to leverage the skills and strengths of Project Leaders in the initial community.
Technical Steering Committee
The Technical Steering Committee is responsible for overall project architectural decisions, managing the sub-project life-cycle including approving new sub-projects and making final decisions if sub-project Core Reviewers, Technical Leads or Project Leads disagree. It defines the overall project architecture and sets the overall Project Priorities in collaboration with the community. It will be comprised of 7 members who will be appointed at Launch but fully elected by the Contributors within the first year.
The initial Technical Steering Committee members will be:
- Brent Rowsell and Ian Jolliffe from Wind River
- Dean Troyer and Saul Wold from Intel
We are actively recruiting for additional Technical Steering Committee members
In September 2019, 3 of the 7 seats will be up for election by the project's Contributors. Anyone who is a Contributor to the project will be eligible to run, and anyone who is a Contributor is eligible to vote. In that election the TSC positions held by one each of the members from Wind River and Intel will be opened for election, to be determined randomly. In April 2020, the remaining 4 seats will be up for election. In that election, the other initial TSC members from Wind River and Intel will be opened for election. TSC elections will continue on this staggered cycle (3 seats and 4 seats) every six months in order to allow new leaders to rise up and ensure some consistency across the terms. TSC members will serve at least one year terms after the initial bootstrapping phase. There are no term limits, but in order to encourage diversity, no more than 2 of the 7 seats can be filled by any one organization.
The Technical Steering Committee will meet regularly in an open forum with times and locations published in community channels. The Technical Steering Committee can elect a Chair at its discretion. Meetings with be hosted and facilitated by the OpenStack Foundation.
Voting within the TSC requires a quorum of 5 members present. In the initial phase when the TSC does not have 5 members, a quorum will be 4 members. TSC members should seek consensus on most technical issues but if needed they can be resolved through a simple majority vote. Voting to create a new or archive an inactive StarlingX sub-project or to change the project's formal Governance document requires a 2/3rds super-majority.
The exact size and model for the Technical Steering Committee will evolve over time based on the needs and growth of the project, but the governing body will always be committed to openness, diversity and the principle that technical decisions are made by technical contributors.
All elections for leadership positions in StarlingX shall follow standard OpenStack procedures and methods. Ballots will be distributed to each Contributor's primary email address. Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using Governance_TieBreaking. In the event that a candidate runs unopposed for a position, the TSC can waive a formal vote. Membership in the Foundation itself is not a requirement for holding an elected position though it is preferred. Elections are appointing an individual to a position in the project, not a company or organization. Individuals are expected to continue to support the project in the event of career changes unless they notify the project that they are resigning their position.
The project's formal governance document shall be maintained in a git repository. Changes to the document can be proposed by any project Contributor but would need to be ratified by the TSC with a super-majority (2/3rds) vote. The TSC should strive for consensus for any change to the project's formal governance.