-
Notifications
You must be signed in to change notification settings - Fork 16
Core Procedures Policy overview
As part of the governance documents and structure, the Board of Directors of the ODPi have adopted a Core Procedures Policy to guide various aspects of ODPi Approved Platform Software Release process. In particular, it defines three key processes.
- Adding, changing, or removing core projects
- Approving a software release
- Approving a new PMC to be added
The RT (Release Team) additional has worked to provide additional clarity and process for ensuring the requirements set forth in the Core Procedures Policy are fulfilled. This document outlines both the governance requirements as well as how the RT operationally manages them.
The RT is tasked with defining a software release. Any ODPi member can provide input in making changes to the core projects that compose the ODPi Approved Platform Software Release through the below process:
-
RT provides notices to the members of an upcoming release
At the beginning of a release cycle, the RT Chairperson will email the odpi-members@ list indicating that the next release planning is beginning. The RT Chairperson will specifically be asking for feedback on any new projects that should be included.
-
Requests for changes to the next specification may be submitted via ODPi JIRA
The RT requests that any new changes be submitted via JIRA using the procedure outlined at https://github.com/odpi/specs/wiki/GiveFeedback#providing-proposed-changes-to-the-spec.
Submission of new requests for the addition of new components are encouraged to include detailed justification for it's inclusion (e.g. challenges that are faced today, how the inclusion into the specification will solve these challenges, etc.)
Members have 10 days from the send date of the email from the RT Chairperson to provide feedback that is ensured to be considered in the planning cycle for the next release.
-
RT consolidates member lists into a single “ODPi Prioritized Backlog List”
This list will be maintained in JIRA. Prioritization will be determined by the number of member requests.
-
RT asks members to vote on the project changes for the release
RT Chairperson will email the membership with a final determination of which projects and versions to add/remove/change in the upcoming ODPi Approved Platform Software Release. Simple majority vote by class, with a quorum defined as 2/3 Platinums, 1/2 Golds, 15% Silvers.
The RT commissions the TSC (Technical Steering Committee) to manage the development of the Approved Platform Software Release. Generally, this will have 4 phases.
The PMC group is tasked with developing the spec incorporating the given projects that the RT has asked by the ODPi membership to include in this Approved Platform Software Release. The PMC should look to socialize and get input from the RT, TSC, and other members of the technical community.
Once the PMC has put together a spec it feels satisfies those requirements set forth by the RT, the RT then approves the spec. The spec now moves to 'Proposal' status.
With the spec in 'Proposal' status, any tests that are needed to be developed to validate the spec, along with upstream project changes needed done should be worked on. As feedback from the development community comes back, the PMC should continue to look at the spec and determine if any changes should be made.
As the development cycle starts to end, assets for members to begin testing the various deliverables should be available in as an RC. Any final feedback should be incorporated.
Before an Approved Platform Software Release, the following must occur.
- Code scanning done to ensure license compliance
- RT sign off on the final assets to be delivered, including the spec
- Board of Directors to approve the release.
- RT manages the final distribution of release.
This work is licensed under a Creative Commons Attribution 4.0 International License