-
Introduction The Software Project is an open source software project led by contributors, code committers, and optionally a technical steering committee (TSC). The Software Project is administered by the OCP Foundation and the IC, which has reviewed and adopted (by majority vote) the Software Project charter and its governance policy (if applicable). This governance model is based on the best practices and values of the open source culture and pursues the goals set by the OCP Foundation. The Software Project functions under the auspices of OCP. Each Software Project shall author a Project Charter that shall be accepted by a majority vote of the IC.
-
Charter and Scope of the Software Project The approved charter of the Software Project shall be published on the OCP website under its corresponding Project web page.
- The scope of the Software Project shall include software development under an OSI-approved open source license.
- The specifications must be under the OCP Software Contributor License Agreement
The Software Project accepts contributions via GitHub pull requests. The following section outlines the process for merging contributions to the source code and the spec.
- Issues Issues are used as the primary method for tracking anything to do with the source code and specification repository.
- Issue Types
For the source code contributions, the issue types could be any of the following:
- Sub-task: This is the sub-task of an issue. In a logged issue, there can be different tasks to resolve, which are called sub-tasks.
- Bug: A problem that impairs or prevents the functions of the product.
- Epic: A big user story that needs to be broken down.
- Improvement: An improvement or enhancement to an existing feature or task.
- New feature: A new feature of the product, which is yet to be developed.
- Task: A task that needs to be done to achieve the team's goal.
Specification issue types are listed below:
-
Discussion: These are support or functionality inquiries that we want to have a record for future reference. Depending on the discussion, these can turn into "Spec Change" issues.
-
Proposal: Used for items that propose new ideas or functionality that require a larger discussion. This allows for feedback from the community before a specification change is actually written. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Spec Change" and does not require a milestone.
-
Spec Change: These track specific spec changes and ideas until they are complete. They can evolve from "Proposal" and "Discussion" items, or they can be submitted individually depending on the size. Each spec change should be placed into a milestone.
The Software Project requires no admission processes, contracts, or membership fees. Any individual or organization can use and contribute to a Software Project. We welcome any contributions that lead to the success of the project - including software development, documentation, testing, delivery and advocacy.
The Software Project may also provide a compliance or branding program for individuals or organizations to register as participants, or to register products, board support packages (BSPs), or software layers as Project Compatible. Any compliance or branding programs must be approved by the OCP Foundation. The compliance or branding program is intended to promote the use and adoption of the open sourced software, regardless of an individual or corporate affiliation with OCP. Participants in the compliance program, at the discretion of the Foundation and with their permission, may be listed on the OCP Marketplace, OCP Integrated solutions and any OCP portal pages or on the OCP GitHub pages.
The Software Project is developed and designed using a collaborative effort by an open community of professionals and volunteers. The success of the Software Project is based on collaboration and governance based on meritocracy.
Roles and Responsibilities
● PLs are responsible for the success of the Software Project and to align with the approved charter. The PL is a volunteer position, initially appointed by OCP and approved by the IC. After initial appointment, the PL position will be elected in accordance with OCP Governance. The PLs will be accountable for the following:
○ Wiki Maintenance
○ Meeting agenda and minutes
○ Engineering Workshops – agenda and content
● Contributors are people who have submitted work to the Software Project. Contributors include anyone in the technical community that contributes code, documentation or other technical artifacts to the Software Project. In addition to their actions as users, Contributors may also find themselves doing one or more of the following:
○ Supporting new users (existing users are often the best people to support new users)
○ Reporting bugs
○ Identifying requirements
○ Assisting with project infrastructure
○ Writing documentation
○ Fixing bugs
○ Adding features
● Committers: Committers are contributors who have earned the ability to modify (“commit”) source code, documentation or other technical artifacts in a Software Project’s repository. A contributor may become a committer by a majority approval of the existing committers. A committer may be also removed by a majority approval of the other existing committers.
● Maintainers: There are two types of maintainers
- Source code maintainers
- Specification maintainers.
Source code Maintainers have permission to accept pull requests and merge them into the master branch of a given repository. Each repository contains a MAINTAINERS file listing the maintainers. There must be one or more named maintainers per repository. Specification Maintainers are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the working project. These maintainers are also responsible for determining consensus and coordinating appeals.
● Editor: Editors are required for specification management only and are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the project, and that the specification adheres to formatting and content guidelines. Project will designate an Editor.
● Participants: They are required for specification management only and are those that have made contributions to the Working Group or to the specification repository.
● ICR (IC Representative): The ICR is an ambassador to other OCP Project Communities. They will work with the PLs and other ICRs to ensure that the Software Project is fitting within the OCP ecosystem.
● Technical Steering Committee (TSC) Optional- TSC may be formed to provide leadership and resolve technical differences that may arise from time to time. The decision to create or dissolve a TSC must be approved by the OCP Foundation
-
The TSC will be responsible for oversight of the open source project and assure the Software Project aligns with the approved charter.
-
The TSC members are initially the Software Project’s code Committers when the Software Project exits the “Incubation Phase” and enters the “Impact Phase”. The Committers will determine the Project’s code repository.
-
Any meetings of the TSC are intended to be open to the public and can be conducted electronically, via teleconference, or in person.
-
The TSC may
- Establish workflow procedures for the submission, approval, and closure/archiving of Project.
- Set requirements for the promotion of contributors to committer status, as applicable.
- 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.
-
The TSC shall elect a chair who will preside over meetings of the TSC. The TSC shall elect a new chair every 12 months. A current or previous chairperson is eligible to serve any number of terms as chair.
-
The TSC shall review its membership every 12 months, in the month following the election of the TSC chair. Membership on the TSC is limited to OCP Corporate Tiered Members and code committers (or persons employed by a code committing company). Members are added or removed by majority vote of the TSC. An existing TSC member that has not committed code within the prior 12 months may be disqualified from the TSC.
-
The TSC will be responsible for all technical aspects or oversight relating to the Software Project. When such responsibilities involve vital functions performed by the OCP Foundation, the TSC shall seek support and ratification. These responsibilities may include (but not limited to) the following:
- Maintain a roadmap of planned feature additions or subtractions, with expected timeline for feature release.
- Approve Software Project or system proposals (including, but not limited to, incubation, deprecation and changes to a Sub-Project’s scope);
- Appointing representatives to work with other open source or open standards communities;
- Establishing community norms, workflows, issuing releases, and security issue reporting policies;
- Approving and implementing policies and processes for contributing (to be published in the repository) and coordinating with the OCP Foundation and IC to resolve matters or concerns that may arise;
- Holding open discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects;
- Coordinating any marketing, events, or communications regarding the Software Project with the OCP Foundation.
- Publishing the list of TSC members and contact information on the repository.
- While the Software Project aims to operate as a consensus-based community, if any TSC decision requires a vote to move the Software Project forward, the voting members of the TSC will vote on a one vote per voting member basis.
- Quorum for TSC meetings requires at least two-thirds of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met, but the TSC will be prevented from making any decisions at the meeting.
- Decisions by vote at a meeting require a majority vote of those in attendance, provided a quorum is met. Decisions made by electronic vote without a meeting require a majority vote of all voting members of the TSC.
- In the event a vote cannot be resolved by the TSC, any voting member of the TSC may refer the matter to the OCP IC for assistance in reaching a resolution. In the case of a tie vote, the IC will cast the deciding vote.