Section 1. Guiding Principle.
The Dronecode Project (Dronecode) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
Section 2. Evolution of Dronecode Governance.
Most large, complex open source communities have both a business and a technical governance model. Dronecode’s technical leadership contains both a Technical Steering Committee (TSC) and Project Leads for major components. Dronecode’s business leadership is instantiated in a Board of Directors (the “Board”).
Section 3. Board’s Role in Setting Dronecode Strategic Direction.
The Board will set overall Project Policy in consultation with the TSC. The policy will describe the overarching scope of the Dronecode initiative, Dronecode’s technical vision and direction and project release guidelines in the form of expected cadence and intent. The Board will use the TSC as a delegate body for governing technical implementation, individual project scope and direction while they remain within the scope and direction of the policies as described in the TSC Policy document and approved by the Board.
Section 4. Establishment of the TSC.
The TSC members shall consist of Platinum member designates and Project Leads from “top level” projects as defined in the project lifecycle document. There may be only one Project Lead per project that shall be nominated by the project.
The TSC may choose to create community representative votes on the TSC in order to include more community members from the Dronecode projects. Such positions would be open for individual nominations and active committers would elect the representative to serve a term of one year.
The TSC will have a chairperson who will also represent the TSC to the Board for a term of one year according to the Dronecode ByLaws. The initial TSC Chair shall be selected by the Board of Directors to serve until December, 2015 and thereafter shall be elected from amongst voting TSC members. The TSC shall hold elections to select a TSC Chair annually; there are no limits on the number of terms a TSC Chair may serve.
Section 5. Responsibilities of the TSC.
Subject to such policies as may be set by the Board, the TSC is responsible for simultaneous release dates, release quality standards, technical best practices (including the establishment and maintenance of a Development Process), monitoring technical progress, mediating technical conflicts between Committers and Project Leads, and organizing inter-project collaboration. The TSC will define Dronecode’s release vehicles and serve as Dronecode’s primary technical liaison body with other open source projects, consortiums and groups.
Section 6. Dronecode Operations.
The TSC will establish and maintain a development process for Dronecode to be documented on the website or wiki.
There will be multiple projects under Dronecode. Each project must be within such policies as may be set by the Board, have a well-defined scope and must work within that scope. The development process will provide for projects to follow the life-cycle process as described in the Project Lifecycle document. The development process will include a process for the TSC to oversee and approve changes in the lifecycle of a project which will include consideration of the following criteria:
- Cleanliness of code base.
- Ample and diverse Contributors and Committers to assure vitality of the project.
- Stability (e.g. presence of test suites and use of an appropriate source-code control system).
- Predictability of releases.
- Alignment with Dronecode’s goals and priorities.
Section 7. Elections and Voting
Leadership roles in Dronecode, project leadership, and TSC community representative roles, will be held by peer elected representatives of the community. The development process for Dronecode will include provisions for a voting process to be implemented for decision-making in accordance with the following guidelines:
For election of persons (e.g. TSC chair) a multiple-candidate method should be used. For example:
- Condorcet: http://en.wikipedia.org/wiki/Condorcet_method or
- Single Transferable Vote: http://en.wikipedia.org/wiki/Single_transferable_vote
If there is only one candidate, a simple majority vote should be used.
Simple majority voting should be used for decisions within the TSC, unless otherwise required. For internal project decisions where no consensus can be reached, simple majority vote by Committers via +1 voting should be used.
The development process will include such processes as may be specified by the Board from time to time relating to the intake and license compliance review of contributions.
Section 7. Project Roles.
Each project has one or more Contributors, who provide project contributions such as code and documentation, and one or more Committers, who may also contribute and additionally control technical direction and the project repository. A Project Lead sets overall direction for the project and represents the project on the TSC.
Committers: For each project there is a set of people with rights to commit code or artifacts to the source code management system: the Committers.
- The Committers will be the decision makers on design, code, packaging, and patches for their project. They must responsibly participate in the consensus decisions of the project.
- Committer rights are earned via code contribution and community trust. Committers select and vote for new Committers. A standard meritocracy model with new Committers will be approved and implemented by the TSC which will include provision for fully open code submission, review, acceptance, build, test, delivery, and support model.
- Committer rights are per project; being a Committer on one project does not necessarily give an individual committer rights on any other project.
- Initial Committers and a nominated Project Lead will be specified at project creation. Additional Committers will be admitted by a vote of existing Committers with appropriate process to handle dissent.
- The Committers will use the process established in the Dronecode Project Lifecycle document and development process maintained by the TSC to manage releases and accept/force modifications/reject code submissions and to add/delete Committers (and other development details).
- A Committer who is disruptive, or has been inactive for an extended period (e.g., six or more months) may have his or her Committer status revoked by the TSC. Project Leads must request the TSC for such an action to be taken.
Contributors: Most Contributors work with their Committer and their component’s sub-community. They contribute code or other artifacts, but do not have the right to commit to the code base. A Contributor may be promoted to a Committer by the projects’ Committers.
Project Leads: The Project Lead is a Committer selected by vote from the Committers in the project. If there is initially only one member of the project, then that member is automatically the Project Lead. It is possible, and in some cases desirable, for one person to take on roles of Project Lead, Committer, and Contributor.
The TSC shall in conjunction with the Dronecode community refine, and provide clarification of, the project roles and responsibilities.
