Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
THIS PAGE IS BEING DEPRECATED. See Governance 3.0.
Version 2.0, Bill Snow (ONF), Scott Nicholas (Linux Foundation)
Ratified at ONOS board meeting 17 June 2016
Changed ON.Lab references to ONF August 4, 2017 after the assets of ON.Lab were transferred to ONF.
Governance Model
Governance of the ONOS® project is intended to foster a technical meritocracy within the context of stewardship by the ONOS Chief Architect and the ONF Board of Directors. ONF is a nonprofit organization, and provides engineering resources on behalf of the ONOS Project.
DRAFT - UNDER EDIT - DO NOT USE OR UPDATE
Governance Model
Governance of the ONOS™ project is a hybrid. It attempts to take what has worked well for open source projects and leave out what didn’t work so well. Mostly, it is governed as a technical meritocracy – those who contribute the most have the most influence on the technical direction and decisions. There is also an element of benevolent stewardship. This is what gives the project its strong vision, goals, and technical shepherding. More specifically, ONOS governance is
...
A technical meritocracy because technical teams manage themselves to do what is technically right for the community. People who make the most contributions to their teams have the most influence. In addition, technical project leaders and steering team members are elected by active contributors.
A benevolent stewardship because ON.lab’s board of directors retains the right to select the chairman of the ONOS advisory board and the leaders of the technical steering team, release management team, and community team. ON.Lab anticipates that it will rarely exercise this right, and that the project will operate autonomously; however, it retains this right in order to ensure that the project is successful. The ONOS project is a collaborative project in the Linux Foundation. Funding for the core engineering team comes from the ONOS partnership set up by the Open Networking Laboratory ("ON.Lab"), a nonprofit public benefit corporation.
Goals
The goals of ONOS project governance are to:
Provide an environment that thrives on technical meritocracy. Merit is based on technical contribution, not on financial contribution.
- Have strong technical vision and shepherding. This ensures architectural integrity of the codebase.
Provide a framework for ONOS teams and projects – how they are started, how they are managed, how members are elected, how conflicts are resolved, how they are disbanded when no longer needed.
Be clear on how ONOS software evolves – how code is added to (or removed from) the project.
Be clear on how decisions are made and conflicts resolved in the community.
Make it easy for community members to participate.
Avoid bureaucracy.
- Create a great codebase.
Principles
The principles of ONOS governance are in line with these community values:
...
In addition, the over-arching governance principle is To act in the best interest of the broader community.
Governance Structure
The ONOS project is governed by four steering teams and a board of directors. The four teams are the technical steering team, the use case team, the release management team, and the community team. ONOS subprojects are formed as part of one of the four teams.
ONOS Board
The board is a group of representatives from the partner organizations. It is governed by the Chairman of the Board (the “Chairman”). The board has the following roles and responsibilities:
- Strategic direction
- New member recruiting
- Conflict resolution between teams
- Ambassadors for ONOS
- ONOS trademark management management
- Elect the lead of the Use Case Steering Team
The board leaves all technical decisions to the technical steering team in the spirit of open source technical meritocracy practice.
The governance document for the board can be found found here.
Steering Teams
Four steering teams govern the ONOS project.
Technical Steering Team
The technical steering team is responsible for all technical decisions in the project. They are responsible for the content and structure of the code base and for all technical priorities with respect to the code base. The ONOS chief architect (“Chief Architect”) is the team lead of the technical steering team. The ON.Lab ONF board of directors reserves the right to remove and replace the lead of the technical steering team Chief Architect at any time.
Email: onos-tech-steering-team@onosproject.org - Archive
Use Case Steering Team
The use case steering team is responsible for prioritizing the use cases that will be developed. They are responsible for the prioritization of all use cases and for all capabilities within those use cases. The use case steering team provides the customer requirements to the ONOS technical team. The use case steering team is lead by an elected representative nominated from the group of members who are customers (in this case, service providers).
Email: onos-use-case-team@onosproject.org - Archive
Use Case Steering Team now operates at the ONF level and is no longer a part of ONOS governance.
Release Management Team
The release management team owns the release management process and is responsible to make sure that releases happen on time with the highest quality. The release management team owns the responsibility for determining the priority of features targeted for a particular release. The release management team lead is elected by the technical committersvoting community. The ON.Lab ONF board of directors reserves the right to approve or veto this selection, and to appoint the team lead.
Email: onos-release-team@onosproject.org - Archive
Community Steering Team
The community steering team is responsible for the care and feeding of the community. It is responsible to address community issues, to grow the community and to make sure that the community thrives. The community steering team lead is elected by the technical committers. The ON.Lab voting community. The ONF board of directors reserves the right to approve or veto this selection, and to appoint the team lead.
Email: onos-community-team@onosproject.org - Archive
Governance Details
Classes of Participation
There are four classes of participation in the governance process. Each plays a different role in governance.
- Open Networking Lab Foundation - the board of directors and employees of Open Networking LaboratoryFoundation
- Service Providers - the primary end users of ONOS derived products
- Vendors - the companies who build products based on ONOS for consumption by the service providers
- Community - independent members of the community
ONOS Board
Composition of the Board
The Board is composed of a chairman and one member from ON.Lab ONF and each partner organization. In addition, each partner may name one alternative member to attend meetings in case the primary member is unable to attend. The maximum number of partner board members is 1520. Each organization may only have one member on the board. The current board is found is found here.
Elections
The Chairman of the Board is chosen by the Open Networking Laboratory Foundation Board of Directors. Each organization is responsible for nominating their board member. The chairman of the board Chairman must approve the nomination. Board members are (re) nominated/approved every year. Nominations/approvals are held in the first quarter of each calendar year. If any board member must leave before the end of their term, their organization will nominate a new member and that member must be approved by the Chairman of the Board. If the Chairman of the Board must step down, then the ON.Lab ONF Board of Directors will select a new Chairman.
2018 Elections Process and Information can be found here.
2017 Elections Process and Information can be found here.
2016 Elections Process and Information can be found here.
Voting
There are three classes of voting: ON.LabONF, Vendors and Service Providers. Each receives votes according to the following allocation of 100 votes. Votes may be fractional.
...
Should a tie occur on a vote, the Chairman of the Board will break the tie.
Technical Steering Team
The technical steering team is responsible for all technical decisions having to do with the ONOS project and the ONOS core codebase (“ONOS Core”). The ONOS core codebase is the software distribution represented by the ONOS trademark. Use case applications, southbound plug-ins for non-OpenFlow devices, sample applications, vendor proprietary extensions may or may not be part of the ONOS coreCore. It is entirely up to the technical steering team to decide what constitutes the ONOS core codebaseCore. Projects within the ONOS Project follow the project lifecycle document which can be found here. The TST may amend the project lifecycle document (“Project Lifecycle”) with the approval of the Chief Architect.
As per the Project Lifecycle, incubated projects may graduate to either Mature-state or Core-state status. It is intended that threshold for having projects graduate to Mature-state will be lower and the process streamlined relative to having projects graduate to Core-state. The TST is intended to be an oversight body, and is not intended to have responsibility for patch-level project decisions.
The membership is found on the home page.
Roles
The definitive section describing technical roles can be found here. The TST, with approval of the Chief Architect, shall have authority to modify, delete and create new technical roles from time to time.
- "Contributor": Anyone who signs a CLA and contributes a patchset and has had their code accepted in review by any Project (whether an ONOS Core Project or a non-Core Project). Provided that the CLA is signed, anyone can participate in the project by submitting code for consideration. For additional information on how to start contributing code to the project please see A Beginner's Guide to Contribution.
- "Reviewer": Everyone can review any patchset.
- "Module owner": Someone who can give a +2 review for a part of the codebase and submit code in that area
- "Project owner": Someone who can give a +2 review and submit anywhere in the codebase
Voting member: A Any contributor, a module owner, or a project owner who has submitted (and/ had accepted) or reviewed, as applicable, at least two patchsets in the prior twelve (12) months.
TST Membership Elections
...
Becoming a Member of the TST
There are several ways to become a member of the TST.
- The Chief Architect is
...
- by definition a member as the lead of the TST.
- The voting community will elect members annually as positions open.
- When a core project is deemed to be important enough to the success of ONOS, then the TST may choose to add the project lead to the TST. It is entirely up to the TST to make the decision on whether the project warrants consideration. This decision is made at the time the project undergoes the review to become a core project.
Membership Elections
New technical steering team members will be elected on a yearly basis. Elections are held in the first quarter of each calendar year. At the time of election the following occurs:
- The Chief Architect is (re) appointed by the board of Open Networking Foundation.
- The Chief Architect decides the appropriate size of the technical steering team. The ONF board of directors has veto power on the choice of size.
- The voting community elects TST members to the open positions.
- The full election procedures are documented here.
If a team member leaves the team during the year, it is up to the Chief Architect to decide whether or not to hold an election to put someone else into the position before the next scheduled election
...
The number of members on the TST is determined by the Chief Architect, subject to veto by the Board of Directors of ON.Lab. The TST will consist of the Chief Architect and elected TST members (the “Elected Members”). Unless otherwise agreed to by the TST with the approval of the Chief Architect, each Elected Member shall be elected to serve for a term of two (2) years, or until his or her earlier resignation or removal. TST elections shall be staggered, if possible, so that roughly half of the Elected Member seats are up for election each year.
The TST shall hold annual elections in the first quarter of the year. In the event that any Elected Member seat becomes vacant more than one (1) month prior to the annual election, the Chief Architect may call for elections for any such seat.
Elections shall be conducted as follows:
- The TST shall solicit the voting members for nominations via the main developer mailing list (onos-dev@onosproject.org)
- Interested voting members may nominate themselves or other voting members
- The TST shall distribute to the mailing list a slate of nominees and conduct the election.
The TST should use a multiple-candidate method of voting, such as Helios or single transferable vote. Multiple-candidate methods may be replaced by a simple election by a plurality of votes when there are only two candidates for one position to be filled. No election is required if there is only one candidate running and no voting member voices an objection. In the event of a tied outcome, the Chief Architect may determine the winner.
Other Changes
- If the ONOS Chief Architect leaves ON.Lab ONF for any reason the ON.Lab ONF board of directors reserves the right to appoint a new ONOS Chief Architect.
If any member of the technical steering team changes their corporate affiliation during their
tenure, and if the change of employment is to an employer already represented in the TST, continued membership in the TST must be approved by the Chief Architect.tenure and, as a result, joins an organization that already has (on a consolidated basis) direct representation on the TST, the ONF board of directors reserves the right to remove them from their role on the technical steering team.
The ONF
The ON.Labboard of directors reserves the right to select a new Chief Architect at any time.
Technical Advisory Group (currently not used)
The Technical Steering Team may organize a technical advisory group of architects, developers, and/or other community members. Members of this group do not have to have any affiliation with the ONOS project. The goal of this group is twofold: solicit input from other experts in the field to guide the ONOS architecture and generate advocacy in the larger ecosystem for the work being done with ONOS. The people on the technical advisory group are all chosen by the Technical Steering Team.
The technical steering team will meet with the technical advisory group (if such a group is organized) 2-4 times a year.
Use Case Steering Team
The use case steering team is responsible for choosing and prioritizing the use cases worked on by the community.
Each service provider has one representative on the use case steering team.The current team members are found on their home page.
Membership
The team representatives are by definition the group of board members from the service providers. The lead is elected on a yearly basis by the board. How each service provider chooses their representative is outside the scope of this document. Elections Elections are held in the first quarter of each calendar year. At At the time of the election, the following will take place:
- The team lead is nominated by any service provider partner, including themselves, to be the team lead.
- The entire board votes on the candidates to select the team lead.
...
If the team lead must step down before an election then a special election will be called to elect a new team leader.
Release Management Team
The Release Management team is responsible for all decisions having to do with requirements and packaging of the release components (note, one can substitute the Agile term “stories” for “requirements” - in this context it is the same thing). More specifically, they own the
Requirements database maintenance (Jira)
Requirements acceptance process
Requirements prioritization process
Release content prioritization
Release process (how subprojects get project code integrated)
Team Lead Election
Elections are held in the first quarter of each calendar year. The team lead of the release management team will be (re) elected by the technical committersvoting community. during During an election, the following will occur:
- Lead candidates are nominated by anyone, including themselves.
- The technical community of committers and maintainers votes to elect the lead. Each voter has one vote.
Members
Anyone may volunteer to be a member of the team. It is up to the team lead to decide how large the team is and who is accepted onto the team. If you would like to volunteer for one or more of the above teams, please send an email to the email address of the team (see above).
Community Steering Team
The community steering team is responsible for the care and feeding of the community. This team will be responsible to make sure the community has what it needs to function effectively. That may include
proactively checking in with members to see what can be improved
starting projects to improve the community
providing a structured way to handle conflict in the community
making sure communication tools work well for the community
owning the on-ramp process for the community
Team Lead Election
Elections are held in the first quarter of each calendar year. The team lead of the community steering team will be (re) elected by the technical committersvoting community. In an election, the following will occur:
- Lead candidates are nominated by anyone, including themselves.
- The technical community of committers and maintainers votes to elect the lead. Each voter has one vote.
Membership
Anyone may volunteer to be a member of the team. It is up to the team lead to decide how large the team is and who is accepted onto the team.
Subprojects
It is up to the subproject team to govern themselves as they feel appropriate. Since subprojects are attached to steering teams, the steering team may get involved to help with decision making and/or conflict resolution.
Decision Making
Subprojects govern themselves and are driven by those who volunteer to be on them. When a more formal decision must be made (outside impact or coordination with other teams/subprojects is needed) lazy consensus is used: a few positive votes with no negative votes is sufficient to get things moving. Negative votes must provide an alternative proposal and a detailed explanation of the reason for the negative vote. The subproject team will then work to resolve the negative vote.
Conflict Resolution and Escalation
When conflicts cannot be resolved in a subproject, the appropriate steering team will take responsibility to make the decision for the subproject. If the steering team cannot reach agreement then the Board will make the decision.