Skip to main content
search

Technical Steering Committee Charter


Section 1.  Guiding Principle.  The OpenDaylight Project (ODL) 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 ODL Governance.  Most large, complex open source communities have both a business and a technical governance model.  ODL’s technical leadership contains both a Technical Steering Committee (TSC) and project leads for major components.  ODL’s business leadership is instantiated in a Board of Directors (the “Board”).  This Technical Steering Committee Charter reflects a carefully constructed balanced role for the TSC and the Board in the governance of ODL.  As both the Board and the TSC gain more experience with ODL’s specific operations, the Board and the TSC have the ability to amend this Charter, subject to the policy and by-laws of the organization.  The normal amendment process is for TSC to propose changes using simple majority of the full TSC to resolve conflicts, with these proposed changes subject to review and approval by the Board.

Section 3.  Board’s Role in Setting ODL Strategic Direction.  The Board will set overall Project policy in consultation with the TSC.   This policy will describe:  ODL’s scope (the aggregate scope of projects); ODL’s technical vision and direction; and project release guidance to the TSC (e.g., deliver via regularly-scheduled release trains).   Typically the Board will have no say on technical issues, individual project scope & direction as long as they remain within the scope and direction of the policies established by the Board.  

Section 4.  Establishment of the TSC.  The TSC will span the entire ODL.  Initially, the TSC shall be formed from the representatives designated by the Platinum Members.

  • The TSC members are the project leads from the Core projects.  There is only one project lead per project.
  • The active Committers will elect a number of TSC members; the exact number to be determined by the TSC after the organization is formed. In order to ensure a true community is in place prior to election, these TSC community seats will be elected six months after the organization forms. These elected community seats must be filled with individuals from separate, unaffiliated companies.
  • If not otherwise represented, each Platinum member may designate a TSC member. This is expected to be a temporary measure and will be re-evaluated by the Board every year. If an event occurs causing a non-designated TSC member associated with a given Platinum Member to join the TSC, the designated TSC member must step down immediately, unless waived by a Super Majority Vote (as defined in the Bylaws) of the Board prior to the precipitating event and for a specified amount of time, not to exceed one year. After such specified amount of time the designated TSC member must step down, unless the waiver is renewed.
  • The TSC will elect a Chair who will communicate with the Board.  The Chair may attend Board meetings as non-voting observer.
  • The term for TSC members, including the Chair, is one year.  There are no term limits for TSC members.

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 Development Process), monitoring technical progress, mediating technical conflicts between Committers and project leads, and organizing inter-project collaboration. The TSC will define ODL’s release vehicles. The TSC will serve as ODL’s liaisons with other consortiums and groups.

Section 6. ODL Operations. The TSC will establish the Development Process for ODL and present the Development Process to the Board for approval as the procedures are established or updated from time to time.

There will be multiple projects under ODL.  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 Daylight Project Lifecycle document, the initial version of which is attached, which provides definition and context for the terms Incubator, Mature, and Core projects.  The Development Process will include a process for the TSC to oversee and approve changes in the state of a project (e.g. Incubator to Mature or Mature to Core), 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 ODL’s goals.

Incubator projects may be thought of as proposals for new projects.  Proposals to create incubator projects may be made by anyone. Creation of incubator projects is subject to TSC approval in accordance with the Development Process: Creating a new incubator project is expected to be a lower hurdle than moving from Incubator to Core project.

The Development Process will include provision for a voting process to be implemented for decision making in accordance with the following guidelines:

  • For election of persons (TSC chairs, project leaders, etc.) a multiple-candidate method should be used, e.g.:

Condorcet: http://en.wikipedia.org/wiki/Condorcet_method or

Single Transferable Vote: http://en.wikipedia.org/wiki/Single_transferable_vote

  • Multiple-candidate methods reduce to simple majority when there is only one position to be filled.
  • For project internal decisions where no consensus can be reached, simple majority vote by Committers via +1 voting should be used.
  • Simple majority voting should be used for decisions within the TSC, unless otherwise specified in Development Process.

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 produce code, and one or more Committers, who control technical direction. Each project will be headed up by a project lead who sets overall direction for the project and reports to the TSC. Contributors and Committers, including project leads, remain in the pay of their respective employers.

Committers: For each project there is a set of people with rights to commit code to the source code management system: the Committers.

  • The Committers will be the decision makers on design, code, and patches for their project. They must responsibly participate in the consensus decisions of the TSC
  • Committer rights are earned via code contribution and community trust. Committers select and vote for new Committers, subject to TSC approval.  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 will be specified at project creation. Additional Committers will be admitted by a vote of existing Committers with appropriate process to handle dissent.
  • Committers are not necessarily from Member companies. Committers are the best available individuals, but usually full-time for any components in active development.
  • The Committers will use the process established in the Daylight Project Lifecycle document maintained by the TSC in its Development Process to accept/force modifications/reject code submissions and to add/delete Committers (and other development details).
  • Initial projects that form ODL’s base may designate Committers. In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project will commit to taking on at least three Committers not from the company of origin within the first three months after ODL is publicly launched based upon evaluation of participation of Contributors during that time.
  • 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 project leads.

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.  The Contributors should rarely be encumbered by the TSC and never by the Board.  

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.

Close Menu