Anuket Operational Procedures

Technical Steering Committee Procedures - SAMPLE ONLY - Anuket TSC to establish operational procedures.

Section 1. Guiding Principle.

These TSC procedures (the “TSC Procedures”) detail the certain aspects of the operation of the Anuket technical project and election of voting members of the technical steering committee (the “TSC”) of the Anuket Project a Series of LF Projects, LLC (the “Project”). Capitalized terms not defined in the TSC Procedures will have the meanings ascribed to them in the technical charter for the Project. The TSC Procedures may be amended from time to time by the TSC, and is subject to the terms of the Project’s technical charter.

The Project will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

To encourage a thriving community, the Anuket community has developed and will maintain a code of conduct for community participation, which is available at http://wiki.anuket.io 

Section 2. Anuket Operations.

The TSC will establish and maintain a development process for Anuket.

There will be multiple projects under Anuket. Each project must be within such policies as may be set by the TSC, 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 TSC’s 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 Anuket’s goals and priorities.

Section 3. Elections and Voting

Leadership roles in the Anuket community, including, within the timeframes required by the Project’s technical charter, TSC membership, will be held by peer elected representatives of the community. The development process for Anuket will include provisions for a voting process to be implemented for decision-making in accordance with the following guidelines:

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

  • Condorcet: Election method that elects the candidate that would win by majority rule in all pairings against the other candidates or

  • Single Transferable Vote: A voting system designed to achieve proportional representation through ranked voting in multi-seat constituencies

Multiple-candidate methods reduce to simple majority voting when there is only one position to be filled.

• For internal project decisions where no consensus can be reached, a majority vote among all Committers of the project via +1 voting should be used.

A simple majority voting should be used for decisions within the TSC at which a quorum is present, unless otherwise required. (A majority of TSC representatives then in office shall constitute a quorum.)

Section 4. Project Roles.

Each project within the 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 that sets overall direction for the project and reports to the TSC will head each project up.

“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. The TSC has the authority to remove a committer. 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. Committers are not necessarily from Member companies. Committers are best available individuals, but usually full-time for any components in active development.

The Committers will use the process established in the 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 Project Lead. The Project Lead is responsible for informing the TSC of any committers that are removed.

“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. Contributors should rarely be encumbered by the TSC.

“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 Anuket community refine, and provide clarification of, the project roles and responsibilities.

Section 5. TSC Member Proxy.

TSC members should make an effort to attend all TSC meetings and related activities. However, it may be necessary for a TSC member to miss one or more meetings due to illness or other unavoidable personal or professional commitments. The purpose of this section is to provide guidance to the community for the use of proxies. This policy is in-force from the date of approval, January 21, 2020, and not retroactive on current proxies.

Proxy Eligibility

• Active contributor

  • In order to maintain the objective that the TSC should consist of active contributors, a proxy must be an active contributor, as identified in the last annual community election. An exception may be made if approved by the TSC.

• TSC member status

  • A proxy may only be designated by an active TSC member. Also, a proxy is only valid as long as the TSC member that appointed the proxy remains on the TSC. In addition, proxies may not designate another proxy.

• TSC member as proxy

  • A TSC member may not be a proxy for another TSC member, unless approved by the TSC (by vote or #agree).

• Concurrent proxy

  • A proxy for one TSC member may not also serve as the proxy for another TSC member, concurrently.

Notification

A TSC member must notify the TSC of a proxy designation by sending email to the TSC mailing list, or by announcing a proxy in a regular TSC meeting and having the designation recorded in the minutes. A proxy may not "self-announce", that is, attend the TSC meeting and announce that they are the proxy for a TSC member, with no previous notification from the TSC member.

Term

In general, a proxy should not serve for more than 6 consecutive meetings, unless approved by the TSC. In addition, a TSC member may not designate a proxy for more than 25% of the meetings in a TSC term (typically 1 year), unless approved by the TSC. If a TSC member anticipates being unavailable for longer than that, then they should offer to step down. An exception may be made by approval of the TSC.