Relentlessly focused on data IO speed and efficiency for more flexible and scalable networks and storage
This Technical Community Document sets forth additional details concerning the operation of the technical community of FD.IO Project a Series of LF Projects, LLC (the “Project”). Capitalized terms not defined in the Technical Community Document will have the meanings ascribed to them in the technical charter for the Project. The Technical Community Document may be amended from time to time by the TSC, and is subject to the terms of the Project’s technical charter.
FD.IO will operate transparently, openly, collaboratively, and ethically. Project discussions, proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
FD.IO will consist of multiple, independent, projects.
Each project will have a single code repository, and its own set of Committers who have exclusive rights to commit code into that project’s repository. Being accepted as a Committer on one project does not grant commit rights to other projects.
Technical decisions (including release decisions) for a project should be made by consensus of that project’s Committers. If consensus cannot be reached, decisions are made by a majority vote of a project’s Committers. Committers on a project may, by majority vote, delegate (or revoke delegation of) any portion of the project’s decisions to an alternate open, documented, traceable decision-making process.
Nothing in this Technical Community Document shall be interpreted in such a way as to violate these principles.
The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.
A “Contributor” is someone who contributes code or other artifacts to a project.
Contributors work with a project’s Committer and the project’s sub-community. A
Contributor may be promoted to a Committer by the project’s Committers after
demonstrating a history of meritocratic contribution to that project.
For each project there is a set of Contributors approved for the right to commit code to the source code management system (the “Committers”) for that project.
Committer rights are per project; being a Committer on one project does not give an individual committer rights on any other project.
The Committers will be the decision makers on all matters for a project including design, code, patches, and releases for a project.
Committers are the best available individuals, but usually work full-time on components in active development.
Each project will have one PTL. Each PTL has a term of one year, but may be removed at any time by majority vote of the project’s committers.
A single individual may serve as PTL for one or more projects.
Technical and release decisions for a project should be made by consensus of that project’s Committers. If consensus cannot be reached, decisions are by majority vote of a project’s Committers. Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented, and traceable decision making process.
Initial Committers for a project will be specified at project creation.
Committer rights for a project are earned via code contribution and community trust. Committers for a project select and vote for new Committers for that project, subject to TSC approval.
New Committers for a project should have a demonstrable established history of meritocratic code contribution.
A Committer may voluntarily resign from a project by making a public request to the PTL to resign.
A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader (PTL) or by super-majority vote of the project’s committers.
The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resign.
Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’. That title expresses gratitude for their service, but conveys none of the privileges of being a Committer.
A project is required to elect a PTL. The PTL acts as the de facto spokesperson for the project.
Candidates for the project’s PTL will be derived from the Committers of the Project.
Candidates must self nominate.
Only Committers for a project are eligible to vote for a project’s PTL.
Election of a project’s PTL shall use a multiple-candidate method, e.g.:
Projects have a lifecycle. That lifecycle is characterized by project ‘states’ and project ‘state transitions’. In addition, all projects are required to be within the ‘Scope’ for FD.IO projects.
Project creation reviews approved by the TSC are limited to the following scope:
| Project State | Description |
|---|---|
| Proposal | Doesn’t exist yet, has no real project resources, but is proposed for review by the TSC |
| Incubation | Project has resources, but is recognized to be nascent |
| Mature | Project is a fully functioning open source project with resources in community roles and established cadence of releases |
| Core | Project is core to fd.io |
| Grouping | Project used to voluntarily ‘group’ together thematically related projects. Grouping projects have a Project Management Committee (“PMC”), which votes on its decisions including accepting new PMC members and accepting (or expelling) new projects into the grouping. PMC Members must be Committers of projects grouped by the Grouping Project, and their lifecycle is similar to those for Committers. Projects must vote to join a Grouping Project, and may at any time vote to leave a grouping Project. |
| Archived | Project that has ben recognized as dead or abandoned, and has been archived, as it is no longer a going concern. |
The valid state transitions and their associated reviews are:
| From State | To State | Review |
|---|---|---|
| <null> | Proposal | |
| Proposal | Incubation | Creation Review |
| Incubation | Mature | Graduation Review |
| Mature | Core | Promotion Review |
| Proposal | Grouping | Group Creation Review |
| {Incubation, Mature, Core, Grouping} | Archived | Termination Review |
For each review, there will be a publicly visible wiki/web template filled out containing relevant review information.
The review document must be posted and announced for public comment for at least 2 weeks prior to the date the review is scheduled.
Revised ideally should be conducted in a manner that is sensitive to the global nature of the community (i.e., geography and time zone dispersion)
Proposal Posted and Announced for 2 weeks:
Creation reviews should be an evaluation of the TSC as to whether the proposal meets the mechanical criteria of:
In addition the TSC is counseled to consider that to broad or all encompassing a scope can be unhealthy for the community at large, and thus to take that into consideration when approving project creation.
Project Infrastructure resources will be provisioned upon approval of a project’s creation review.
Graduation Proposal Posted and Announced for 2 weeks:
Graduation reviews should be an evaluation of the TSC as to whether the proposal meets the mechanical criteria of:
Promotion Proposal Posted and Announced for 2 weeks:
Promotion reviews should be an evaluation of the TSC as to whether the Statement of Centrality of Role for the project truly rises to the level of being central to fd.io.
Grouping Proposal Posted for 2 weeks
Grouping Reviews should be an evaluation of the TSC as to whether:
Termination Proposal Posted and Announced for 2 weeks:
A Project’s Committers make all decisions about Releases of that Project. However, to be eligible to be considered ‘Mature’, and project must demonstrate a history of following the Mature Release Process. The purpose of the Mature Release Process is to insure openness and maximum opportunity for participation. The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle. Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.
Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist project in coordinating amount themselves and the general world in gaining visibility.
These should contain roughly the following sections:
TSC Membership shall consist of:
No Member may be admitted to the TSC if their admission would cause the percentage of TSC seats held by persons employed by the same company to exceed 50%.
Decisions of the TSC should be made by majority vote.
The TSC will elect from among TSC members, the TSC Chairperson.
Candidates for a TSC Chair must be TSC Members.
Candidates must self nominate.
Only TSC Members are eligible to vote for TSC Chair.
Election of a TSC Chair shall use a multiple-candidate method, e.g.:
Each Core Project is entitled to one Member on the TSC.
The TSC Member from a Core Project must be a committer on that Core Project.
By default, each Core Projects TSC Member will be its PTL.
A Core Projects PTL may choose to appoint another committer from that Core Project to represent the core project in their stead.
Candidates for a Committer-at-Large Membership on the TSC must be Committers on a fd.io project in good standing.
Candidates must self nominate.
All of the Committers on all fd.io projects vote together for Committer-at-Large members of the TSC.
The TSC shall establish a clear procedure for nomination and election of Committer- at-Large members.
Election of a TSC Chair shall use a multiple-candidate method, e.g.:
The TSC may itself appoint up to two members of the TSC.
TSC Appointed Members shall serve a two-year term.
The TSC has three Legacy Members from its time as an independent foundation:
The status of Legacy TSC membership should be revisited annually.
The TSC is responsible for, pursuant to the requirements of the Project’s technical charter:
The TSC may choose to organize a Coordinated Release. Such a Coordinated Release
may impose additional requirements on projects that choose to participate in it.
Projects must choose to participate; they cannot be compelled to do so.
Should the TSC choose to create a Coordinated Release it should provide, up front a Coordinated Release Plan (CRP) detailing:
The TSC has ability to amend this Technical Community Document, subject to the technical charter of the Project.
The normal amendment process is for either the TSC or the Committers-at-Large to propose changes using simple majority of the full TSC to resolve conflicts.