How to Contribute

Following are the way of contributions and its process for the OCP community.

Technical Contributions

OCP members are welcome to contribute in any or all of the following development processes. The ways in which the members can contribute are explained in detail in the following sub sections.

1. Development

2. Reviews

3. Testing

4. Bug Fixing

5. Presentation and demos

6. Documentation

Software Contribution Guidelines (per our Governance Document)

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:

1. Discussion: These are support or functionality inquiries that we want to have a record of for future reference. Depending on the discussion, these can turn into “Spec Change” issues.

2. 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.

3. Spec Change: These track specific spec changes and ideas until they are complete. They can evolve from “Proposal” and “Discussion” items or can be submitted individually depending on the size. Each spec change should be placed into a milestone.

4. Software Community & Membership

The Software Project requires no admission processes, contracts, or membership fees. Any individual or organization who are OCP members, 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.

Software Compliance Program

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 Project GitHub pages.

Software Project Management

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 (see Sec 1- Volunteer Leaders) 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: 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 and 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: “Participants” are required for specification management only and are those that have made contributions to the Working Group or to the specification repository.

The Incubation Committee Representative (ICR): 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.

(OPTIONAL) A Technical Steering Committee (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, and

  • 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 shall 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; and

• 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.

• TSC Voting

  • 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.

Branding

In order to promote the Software Project, both within the community and externally, branding is needed. Each individual Software Project will undergo a dedicated branding exercise, with collaboration between the OCP Foundation and Project Lead(s) and TSC (if applicable), in order to determine the most appropriate brand framework from which to operate This may include “fitting” within an existing brand scheme (such as OCP), or as a stand-alone brand. “Branding” of a Software Project may include, but not be limited to:

• Naming conventions,

• Iconography,

• Logo marks,

• Landing pages,

• Website domains,

• Content,

• Social media profiles,

• Events,

• Co-marketing, etc.

Administrative Support

The OCP Foundation will provide administrative functions that are vital for the Software Project, including finance, advocacy, outreach, infrastructure, and community management. It will periodically assign tasks to the PLs or other members for assistance in such duties. The OCP Foundation will conduct regular conference calls and Engineering Workshops to facilitate these functions.

Licensing

Participants and/or Code Committers acknowledge that all the licensing and copyright information is clearly defined in every source code or documentation file that is being contributed and the source code license matches with the actual licensing information that the Software Project dictates.

All code contributions to the Software Project are subject but not limited to the following:

• The TSC OCP prefers to use MIT license for all of its Software Projects, regardless of the GitHub repository in which it resides but upon approval, may work with other OSI-approved open source licenses. The license specified for the Project must be stated within the “LICENSE” file within the Software Project’s code repository.

• The committers will also have the sign the “Developer Certificate of Origin (DCO)” from GitHub. This is a way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the OCP software project.

• A Software Project may, upon approval of the OCP Foundation, license its code under more than one Project code license.

• All outbound code will be made available under the Software Project License.

• Documentation will be received and made available by the Software Project under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/)

• Development of specifications, standards, best practices, guidelines, and other similar materials by the project shall use the Community Specification License.

• All software in the Software Project repository not covered under an OSI-approved license must be submitted via a Contribution License Agreement.

• The Software Project may seek to integrate and contribute back to other open source projects (“Upstream Projects”). In such cases, the Software 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 shall comply with the contribution process and license terms for the applicable Upstream Project.

• The OCP Foundation may approve the use of an alternative license or licenses for inbound or outbound contributions on an exception basis.