Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Introduction

The Nexoedge project has been established as Nexoedge Project a Series of LF Projects, LLC (alternatively, the “Project”).  LF Projects, LLC is a Delaware series limited liability company.  Governance for the Project is detailed within the Project Technical Charter available at the Nexoedge wiki.  This Technical Community Document is intended to provide additional operational guidelines for the Project, and is subject to the Technical Charter.

1   Guiding Principles 

The Nexoedge Project a Series of LF Projects, LLC (“Nexoedge”) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

2   Structure of the Technical Community

The Technical Community consists of a Technical Steering Committee and contributors.

3   The Project

3.1   Roles 

3.1.1   Contributor

A Contributor is someone who contributes to a project. Contributions could take the form of code, code reviews, Wiki and documentation contributions,  Jira activities or other artifacts. 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 contributions to that project.

3.1.2   Committer

A set of Contributors approved for the right to commit code to the source code management system (the “Committers”) for the 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.
  • All project committers information such as name, company, and Contact information should be documented in the wiki under the project.

3.2   Operations

3.2.1   Project Decisions Making Process

Technical and release decisions for a project should be made by consensus of the Project's Committers.  If consensus cannot be reached, decisions are taken by majority vote of Committers.  Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented (wiki), and traceable decision making process.

3.2.2   Committer Lifecycle

3.2.2.1   Adding Committers

  • Initial Committers will be specified by the TSC
  • Committer rights are earned via contribution and community trust.
  • New Committers should have a demonstrable established history of meritocratic contributions.

In the event that no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from the Project's active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status.  In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.

The method by which the TSC appoints an interim Committer is first by request to the Nexoedge-TSC email list (nexoedge-tsc@lists.lfedge.org) indicating the request to appoint an interim Committer.  After the reception of such an email, the normal TSC decision process applies.

3.2.2.2   Removing Committers

A Committer may voluntarily resign by making a public request to the project email list and cc to nexoedge-tsc@lists.lfedge.org) to resign.

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 or by 2/3 supermajority vote of the Project’s committers.

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.

3.3   Amendments to the Technical Community Document

The TSC may make amendments to this Technical Community Document at any time with a simple majority of the members of a quorum of the TSC as defined in section 4.4.1.

4   Technical Steering Committee

4.1   Nexoedge Community Active Contributors

Active Contributors are the cornerstone of the TSC.

Active Contributors are any Nexoedge community member with fifteen (15) or more measurable contributions as assessed by the TSC during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.

At the transition time the qualification period will be from the point of project inception to the transition date.

4.2   TSC Members

TSC Members consist of an elected subset of up to 15 people from (i) the community’s Active Contributors and (ii) the project founding members listed in the below.

  • Project Founding Members
    • Aldous Ng Kwok Sing
    • Shakeel Salamat Ullah
    • Prof. Patrick P. C. Lee
    • Helen H. W. Chan

Only TSC members have voting rights for decisions taken by the TSC and each TSC member has a single vote.

TSC Membership is bestowed to a subset of Active Contributors and project founding members through election(s) by the Active Contributors as defined in section 4.4.3.

The TSC functional roles of chair will be held by TSC members.

Nexoedge Community Structure

4.3   TSC Functional Roles

In addition to Active Contributors and TSC Members there are other roles within the community such as TSC Chair and committers.

Community members with functional roles are not TSC members in their own right.

4.3.1   TSC Chair

The TSC Chair is elected by the TSC members.

The TSC Chair is elected for a term of one year.

The TSC members shall hold elections to select a TSC Chair at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Point.

There are no limits on the number of terms a TSC Chair may serve. 

4.3.1.1   Responsibilities

The primary responsibility of the TSC Chair are to represent the technical community in communications with the LF Nexoedge Fund of The Linux Foundation and to be responsible for:

  • Leading TSC meetings;

    • This responsibility may be delegated to another TSC Member (in such case, this is to be informed via the TSC email list)

  • Representing the technical community to external organizations.

  • These responsibilities may be delegated to another member of the technical community.

  • Lead the TSC in the execution of the TSCs responsibilities (section 4.3).

4.4   TSC Operations

4.4.1   TSC Decision Making Process

At the transition point and until changed by the TSC there shall be up to 15 seats on the TSC including the chair.

Decisions of the TSC should be made by majority vote of TSC Members.

A TSC vote requires a quorum of TSC members to be valid, a quorum consisting of at least 51% of TSC Members present or casting a vote.

Any vote of TSC members that result in a tie shall be considered as not approved.

4.4.2   TSC Election Candidate and Voter Eligibility

4.4.2.1   TSC Members

There are no limitations on the number of candidates that can run in an election for TSC membership, nor is there a limit to the number of candidates from any organization including its subsidiaries (hereon termed simply an ‘organization’)  that can run for TSC membership. However the limits as defined in the section 4.4.3.2.1 section for the total number of TSC members from a given organization shall be enforced by means of the election and interim election process described in section 4.4.3.

Candidates must self nominate.

4.4.2.1.1   Candidate and Voter Eligibility

Any Active Contributor community member and project founding members is eligible to run for TSC membership.

Any Active Contributor community member and project founding members is eligible to vote in a TSC Member election.

Eligibility is effective as of the date and time the nomination process starts.

4.4.2.2   TSC Chair and functional roles

Elections for the role of TSC Chair shall be held immediately after each year TSC Member election.

Candidates must self nominate.

4.4.2.2.1   Candidate and Voter Eligibility

All TSC members are eligible to run for the roles of Chair.

There are no limits on the number of terms a TSC Chair may serve. 

All TSC Members are eligible to vote in a TSC Chair election.

4.4.3   TSC Election Mechanics

4.4.3.1   TSC Member Elections

All TSC members shall be elected at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Time.

4.2.3.2   TSC Member Election Mechanics

The annual election of TSC Members shall consist of a single stack ranked vote of all candidates to select the remaining 15 TSC members via CIVS  https://civs.cs.cornell.edu/

All TSC Active Contributors and project founding members may cast a single vote.

4.4.3.2.1   Enforcement of organization TSC member limits.

The CIVS election will rank all standing candidates from 1 to N.

At most two (2) person from any company, or a group of related companies can be elected as a TSC member at any given time.

If any organization entered more than the permitted limit of electable candidates all excess candidates shall be removed from the results from the least ranked upwards until the organization  limit is reached.

Once this is done the remaining 15 highest ranked candidates shall be elected to the TSC.

4.4.3.2.2   Interim elections

In case a TSC member, including Chair, steps down or is required to step down due to, no longer able to perform the TSC duties, organization limits being exceeded or as a result of company acquisitions or mergers after each yearly election.

In all above cases, the TSC member may inform via an email to the TSC email list, an interim election may be called by the TSC for that single position within 60 days of the notification from the leaving TSC member. Interim election can be used to reelect the open TSC position. The period of the TSC member elected using the interim election can be up to next full election.

In an interim election, any organization eligible contributors may only enter candidates if their current representation on the TSC is below their organization’s TSC Member limit.

Interim elections shall otherwise follow all the same procedures and use the same voting schemes as the yearly elections.

4.4.3.3   TSC Chair Election Mechanics

The TSC will elect from amongst TSC Members a chairperson for a term of one year.

The TSC shall hold elections to select a TSC Chair at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Point.

The TSC Chair election shall consist of a single stack ranked vote of all candidates using  CIVS  https://civs.cs.cornell.edu/.

4.5   Responsibilities of the TSC

Subject to the Technical Charter, the TSC is responsible for:

  • Defining Nexoedge’s release vehicles (such as a Coordinated Release) that align with the Project’s mission
  • Fostering cross-project collaboration
  • Serving as Nexoedge's primary technical liaison body with other consortiums and groups
  • Developing an architecture
  • Setting simultaneous release dates
  • Defining release quality standards
  • Defining technical best practices and community norms (including the establishment and maintenance of a Development Process)
  • Monitoring technical progress
  • Mediating technical conflicts between Committers
  • Organizing inter-project collaboration
  • Coordinating technical community engagement with the end-user community


  • No labels