Section 1. Guiding Principle. The AllSeen Alliance, Inc. (the “Alliance”) will operate transparently, openly, collaboratively, and ethically. The Technical Steering Committee (“TSC”) shall ensure that all technical decisions are made in an open and transparent fashion, and that all communication between and within Working Groups will be fair, open and consistent.
Section 2. Terminology
“Project” – The most fundamental organizational unit. There will be many of these in the Alliance. Projects may formally become a part of the Alliance following approval by the TSC.
“Service” – Modular units of code produced by a Project that extend the core project code.
“Working Group” – Logical grouping of Projects in a way that makes sense. Grouping is done by the TSC.
Section 3. Evolution of the Alliance Governance. Most large, complex open source communities have both a business and a technical governance model. The Alliance's technical leadership contains both a TSC Chair and Chairs for its Working Groups (“Working Group Chairs”). The Alliance'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 the Alliance. As both the Board and the TSC gain more experience with the Alliance’s specific operations, the Board and the TSC have the ability to amend this Charter, subject to the policies and By-laws of the Alliance. The normal amendment process is for the TSC to propose changes using a simple majority of the full TSC to resolve conflicts, with these proposed changes subject to review and approval by the Board.
Section 4. Board’s Role in Setting the Alliance Strategic Direction. The Board will set overall Working Group policies in consultation with the TSC. These policies will describe: the Alliance's scope (the aggregate scope of Projects and Working Groups); the Alliance’s technical vision and direction; Project release guidance to the TSC (e.g., deliver via regularly-scheduled release trains); and other appropriate matters. Typically the Board will have no say on technical issues, individual Working Group or Project scope and direction as long as they remain within the scope and direction of the policies established by the Board.
Section 5. Establishment of the TSC. There will be a single TSC that will span all Working Groups of the Alliance.
- Membership of the TSC is defined in section 5.5 (b) of the AllSeen Alliance Bylaws.
- The TSC shall be under the leadership of the TSC Chair.
- The TSC Vice-Chair shall lead the TSC when the TSC Chair is unable to do so and will serve as an advisor to the TSC Chair on the direction and running of the TSC..
Section 6. 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, monitoring technical progress, mediating technical conflicts between Committers and Working Group Chairs, and organizing inter-Working Group collaboration. The TSC will define the Alliance’s release vehicles. The TSC will serve as the Alliance’s technical liaison with other consortia and groups.
Section 7. The Alliance Operations. The TSC will establish rules of operation and process (the Development Process) for the Alliance and present the Development Process to the Board for approval as the TSC’s procedures are established or updated from time to time.
(a) Projects. There will be multiple Projects under the Alliance. 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. Each Project will have a maintainer and function as an open source Project.
(b) Working Groups. As necessary, Working Groups shall be established by the TSC in order to logically group and coordinate appropriate Projects. The Development Process will include a process for the TSC to oversee and approve the progress of a Working Group, which will include consideration of the following criteria:
- Cleanliness of code base
- Ample and diverse Contributors and Committers to assure vitality of the Working Group.
- Stability (e.g., presence of test suites and use of an appropriate source-code control system).
- Predictability of releases
- Alignment with the Alliance’s goals.
(c) Voting. 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 Chair, Working Group Chairs, etc.), a multiple-candidate method will be used. Unless otherwise designated by the Board, an Instant-runoff election will be conducted. (For example: http://en.wikipedia.org/wiki/Instantrunoff_voting.)
- 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, a vote will be taken and a simple majority will prevail.
- A majority of the members of the TSC who have active voting rights shall constitute a quorum for the transaction of business, and the act of a majority of such members present at any meeting at which there is a quorum shall be the act of the TSC pursuant to section 5.5 (c) of the Bylaws.
- A member of the TSC with suspended voting rights can not vote in absentia via email and they can not participate in email votes.
(d) Contributions. 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 8. Working Group Roles. Each Project has one or more Contributors, who produce code, and one or more Committers, who control technical direction. Each Working Group will be headed up by a Working Group Chair who sets overall direction for the Projects within the Working Group and reports to the TSC. Contributors and Committers, including Working Group Chairs, remain in the pay of their respective employers.
- A Working Group Chair who is disruptive, or has been inactive for an extended period (e.g., six or more months) may have his or her Working Group Chair status revoked by the TSC.
(a) Committers. For each Working Group there is a set of people with rights to commit code to the source code management system, called Committers.
- The Committers will be the decision makers on design, code, and patches for their Working Group. Each Committer must be an employee of (or expressly sponsored by) an Alliance member company (at any membership level) and 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 or Working Group.
- Initial Committers will be specified at Working Group creation. Additional Committers will be admitted by a vote of existing Committers, subject to TSC approval, with appropriate process to handle dissent. If a Working Group has no active Contributors or Committers, the TSC may designate a Committer for such Project.
- Committers are the best available individuals, but usually full-time for any components in active development.
- Committers will use the process established in the Working Group 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).
- 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 Working Group Chair.
(b) Contributors. Contributors will generally work with their Committer and their Project’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 Working Group’s Committers. The Contributors should rarely be encumbered by the TSC and never by the Board.
(c) Working Group Chairs. The Working Group Chair is elected by the Working Group’s Committers to act as the head of the Working Group, and represent the Working Group and its Projects on the TSC. The Working Group Chair must be from a member company (at any level of membership), and may be a Committer selected by vote from the Committers in the Working Group. If there is initially only one member of the Working Group, then that member is automatically the Working Group Chair. It is possible, and in some cases desirable, for one person to take on roles of Working Group Chair, Committer, and Contributor.
Section 9. Working Group Principles. The following relate to the Working Groups initiated by the TSC and the artifacts created therein:
- Singularity: To the extent possible, there should be no overlap between the goals of the various Working Groups and artifacts created by them.
- Cohesiveness: The artifacts created within each mature Working Group should connect appropriately to other mature / core Working Groups to form a cohesive system. (It is understood that this will not apply to artifacts that are stand-alone by design).
- Non-interference: Services should work in any configuration and not create negative interference with each other’s functionality.