...
Please do not comment these anymore, but comment the referred pages instead. Any comments to this page will be deferred.
Charter
Based on the current Anuket charter
Technical Charter (the “Charter”)
for
Anuket Project a Series of LF Projects, LLC
This charter (the “Charter”) sets forth the responsibilities and procedures for technical
contribution to, and oversight of, the Aunket Project, established as Anuket Project a Series of
LF Projects, LLC (the “Project”). LF Projects, LLC (“LF Projects”) is a Delaware series limited
liability company. All Contributors to the Project must comply with the terms of this Charter.
1. Mission and Scope of the Project
a. The mission of the Project is to empower the global communications community
by creating and developing reference cloud infrastructure models, architectures,
tools, and programs to deliver network services faster, more reliably, and
securely.
b. Anuket develops open reference infrastructure models, architectures, tools, and
programs. Open source software developed within the project will leverage OSIapproved
licenses, while documentation, including specifications, will leverage
open licenses. The scope of the project includes but is not limited to:
i. Enabling member communities to align on model, architecture and
implementation requirements and specifications for cloud-based
communications infrastructure and workloads,
ii. Supporting open source and open standards communities in the ecosystem,
iii. Developing an integrated, tested, and validated open software reference
infrastructure (including interfaces to hardware), with tools of its own
design and from upstream testing projects,
iv. Helping design a conformance framework and validation programs,
v. Contributing to and influencing upstream projects leveraging the reference
infrastructure,
vi. Creating new open source components within the reference infrastructure
where needed,
vii. Supporting ongoing strategic activities and evaluating emerging
technologies to foster continued deployment success.
2. Technical Steering Committee
The Technical Steering Committee (the “TSC”) will be responsible for all
technical oversight of the open source Project.
b. TSC Voting Members
i. “Transition Period”: From effective date of this amendment of the
Charter, (“Project Merger”) up to but no more than twelve (12) months
following Project Merger or such other date as determined by the TSC
(such period the “Transition Period”), the TSC voting members will
consist of:
1. 7 seats allocated to the CNTT community (to be determined via a
process to be approved by the CNTT technical steering community
and governance committee); and
2. 8 seats allocated to the OPNFV community (to be determined via a
process to be approved by those individuals that comprised the
OPNFV TSC immediately prior to the start of the Transition
Period).
ii. The list of voting members of the TSC will be maintained on
wiki.anuket.io.
iii. “Steady State”: After the Startup Period, the size, makeup and procedure
for determining voting members of the TSC will be as determined by the
TSC and documented within a TSC procedures document (the “TSC
Procedures Document”) and on wiki.anuket.io.
c. Any meetings of the Technical Steering Committee are intended to be open to the
public, and can be conducted electronically, via teleconference, or in person.
d. TSC projects generally will involve Contributors and Committers. The TSC may
adopt or modify roles so long as the roles are documented on wiki.anuket.io.
Unless otherwise documented:
i. Contributors include anyone in the technical community that contributes
code, documentation, or other technical artifacts to the Project;
ii. Committers are Contributors who have earned the ability to modify
(“commit”) source code, documentation or other technical artifacts in a
project’s repository; and
iii. A Contributor may become a Committer by a majority approval of the
existing Committers. A Committer may be removed by a majority
approval of the other existing Committers.
e. Participation in the Project through becoming a Contributor and Committer is
open to anyone so long as they abide by the terms of this Charter.
The TSC may (1) establish workflow procedures for the submission, approval,
and closure/archiving of projects, (2) set requirements for the promotion of
Contributors to Committer status, as applicable, and (3) amend, adjust, refine
and/or eliminate the roles of Contributors, and Committers, and create new roles,
and publicly document any TSC roles, as it sees fit.
g. The TSC elects a TSC Chair, who will preside over meetings of the TSC and will
serve until their resignation or replacement by the TSC. The TSC Chair, or any
other TSC member so designated by the TSC, will serve as (a) the Project’s
representative to the Technical Advisory Committee (“TAC”) of the LF
Networking Fund of The Linux Foundation (“LFN”) and (b) the primary
communication contact between the Project and the LFN. The TSC Chair will
have responsibility for providing input on Project resource requirements to the
TAC. The TSC may also elect a co-chair or vice chair who will share
responsibilities with the Chair.
h. Responsibilities: The TSC will be responsible for all aspects of oversight relating
to the Project, which may include:
i. coordinating the technical direction of the Project;
ii. approving project or system proposals (including, but not limited to,
incubation, deprecation, and changes to a sub-project’s scope);
iii. organizing sub-projects and removing projects;
iv. creating sub-committees or working groups to focus on cross-project
technical issues and requirements;
v. appointing representatives to work with other open source or open
standards communities;
vi. establishing community norms, workflows, issuing releases, and security
issue reporting policies;
vii. approving and implementing policies and processes for contributing (to be
published on wiki.anuket.io) and coordinating with the Series Manager to
resolve matters or concerns that may arise as set forth in Section 7 of this
Charter;
viii. amending the TSC Procedures Document and other policies and
documents of the TSC;
ix. approving license exceptions under Section 7;
x. discussions, seeking consensus, and where necessary, voting on technical
matters relating to the code base that affect multiple projects; and
coordinating any marketing, events, or communications regarding the
Project with the LF Projects Manager or their designee.
3. TSC Voting
a. While the Project aims to operate as a consensus based community, if any TSC
decision requires a vote to move the Project forward, the voting members of the
TSC will vote on a one vote per voting member basis.
b. Quorum for TSC meetings requires at least a majority of all voting members of
the TSC to be present. The TSC may continue to meet if quorum is not met, but
will be prevented from making any decisions at the meeting.
c. Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require
a majority vote of those in attendance, provided quorum is met. Decisions made
by electronic vote without a meeting require a majority vote of all voting
members of the TSC.
d. In the event a vote cannot be resolved by the TSC, any voting member of the TSC
may refer the matter to the Series Manager for assistance in reaching a resolution.
4. Compliance with Policies
a. This Charter is subject to the Series Agreement for the Project and the Operating
Agreement of LF Projects. Contributors will comply with the policies of LF
Projects as may be adopted and amended by LF Projects, including, without
limitation the policies listed at https://lfprojects.org/policies/.
b. The TSC may adopt a code of conduct (“CoC”) for the Project, which is subject to
approval by the Series Manager. Contributors to the Project will comply with the
CoC or, in the event that a Project-specific CoC has not been approved, the LF
Projects Code of Conduct listed at https://lfprojects.org/policies/.
c. When amending or adopting any policy applicable to the Project, LF Projects will
publish such policy, as to be amended or adopted, on its web site at least 30 days
prior to such policy taking effect; provided, however, that in the case of any
amendment of the Trademark Policy or Terms of Use of LF Projects, any such
amendment is effective upon publication on LF Project’s web site.
d. All participants must allow open participation from any individual or organization
meeting the requirements for contributing under this Charter and any policies
adopted for all participants by the TSC, regardless of competitive interests. Put
another way, the Project community must not seek to exclude any participant
based on any criteria, requirement, or reason other than those that are reasonable
and applied on a non-discriminatory basis to all participants in the Project
community.
The Project will operate in a transparent, open, collaborative, and ethical manner
at all times. The output of all Project discussions, proposals, timelines, decisions,
and status should be made open and easily visible to all. Any potential violations
of this requirement should be reported immediately to the LF Projects Manager.
5. Community Assets
a. LF Projects will hold title to all trade or service marks used by the Project
(“Project Trademarks”), whether based on common law or registered rights.
Project Trademarks will be transferred and assigned to LF Projects to hold on
behalf of the Project. Any use of any Project Trademarks by participants in the
Project will be in accordance with the license from LF Projects and inure to the
benefit of LF Projects.
b. The Project will, as permitted and in accordance with such license from LF
Projects, develop and own all Project GitHub and social media accounts, and
domain name registrations created by the Project community.
c. Under no circumstances will LF Projects be expected or required to undertake any
action on behalf of the Project that is inconsistent with the tax-exempt status or
purpose, as applicable, of LFP, Inc. or LF Projects, LLC.
6. General Rules and Operations.
a. The Project will:
i. engage in the work of the project in a professional manner consistent with
maintaining a cohesive community, while also maintaining the goodwill
and esteem of LF Projects, LFP, Inc. and other partner organizations in the
open source software community; and
ii. respect the rights of all trademark owners, including any branding and
trademark usage guidelines.
7. Intellectual Property Policy
a. Participants acknowledge that the copyright in all new contributions will be
retained by the copyright holder as independent works of authorship and that no
contributor or copyright holder will be required to assign copyrights to the
Project.
b. Except as described in Section 7.c., all code contributions to the Project are
subject to the following:
i. All new inbound code contributions to the Project must be made using the
Apache License, Version 2.0 (available here:
https://www.apache.org/licenses/LICENSE-2.0) (the “Project License”).
ii. All new inbound code contributions must also be accompanied by a
Developer Certificate of Origin (http://developercertificate.org) sign-off in
the source code system that is submitted through a TSC-approved
contribution process which will bind the authorized contributor and, if not
self-employed, their employer to the applicable license;
iii. All outbound code will be made available under the Project License.
iv. Documentation and specifications will be received and made available by
the Project under the Creative Commons Attribution 4.0 International
License (available at http://creativecommons.org/licenses/by/4.0/).
v. The Project may seek to integrate and contribute back to other open source
projects (“Upstream Projects”). In such cases, the Project will conform to
all license requirements of the Upstream Projects, including dependencies,
leveraged by the Project. Upstream Project code contributions not stored
within the Project’s main code repository will comply with the
contribution process and license terms for the applicable Upstream
Project.
c. The TSC may approve the use of an alternative license or licenses for inbound or
outbound contributions on an exception basis. To request an exception, please
describe the contribution, the alternative open source license(s), and the
justification for using an alternative open source license for the Project. License
exceptions must be approved by a majority vote of the entire TSC. Contributed
files should contain license information, such as SPDX short form identifiers,
indicating the open source license or licenses pertaining to the file.
8. Amendments
a. This charter may be amended by a two-thirds vote of the entire TSC and is subject
to approval by LF Projects.
TSC Procedures
Technical Steering Committee Procedures
Section 1. Guiding Principle.
These TSC procedures (the “TSC Procedures”) detail the certain aspects of the
operation of the OPNFV technical project and election of voting members of the
technical steering committee (the “TSC”) of the OPNFV 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 OPNFV community has developed and will
maintain a code of conduct for community participation, which is available at
wiki.opnfv.org.
Section 2. OPNFV Operations.
The TSC will establish and maintain a development process for OPNFV.
There will be multiple projects under OPNFV. 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 sourcecode
control system).
• Predictability of releases.
• Alignment with OPNFV’s goals and priorities.
Section 3. Elections and Voting
Leadership roles in the OPNFV 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 OPNFV 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.:
o Condorcet: Election method that elects the candidate that would win
by majority rule in all pairings against the other candidates or
o 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 OPNFV community refine, and provide
clarification of, the project roles and responsibilities.