|
|
**1 ACTIVITY: PMC ROLLOUT**
|
|
|
- Establish the PMC for managing the Open Source developments.
|
|
|
|
|
|
**2 RESPONSIBLE PARTIES**
|
|
|
|
|
|
**2.1 THE RESPONSIBLE PARTY**
|
|
|
- Stephen Whitley
|
|
|
|
|
|
**2.2 RELATED RESPONSIBILITIES**
|
|
|
- From RACI (A/R Only)
|
|
|
- Being developed
|
|
|
|
|
|
**3 SUCCESS**
|
|
|
- A functioning PMC structure, modeled after successful Open Source Projects, capable of managing the development and release of OSDU compliant with the standards via a process that embraces innovation and meritocracy.
|
|
|
|
|
|
**4 30-60-90 DAY PLAN**
|
|
|
|
|
|
**4.1 30 DAYS:**
|
|
|
4.1.1 Organization
|
|
|
- Onboard the Vice-PMC
|
|
|
- Define / confirm the Project Structure for the open source developments (see Initial projects)
|
|
|
- Recruit project leads for each of the projects from member companies
|
|
|
|
|
|
4.1.2 Charter
|
|
|
- Write a clear charter for the PMC and how it relates to the rest of the OSDU
|
|
|
|
|
|
4.1.3 Tooling
|
|
|
- Setup the repository of projects with clear set of permissions for reporters (ability to report issues), contributors (ability to contribute content) and committers (ability to push to the main branch).
|
|
|
|
|
|
**4.2 60 DAYS:**
|
|
|
4.2.1 Committer Development
|
|
|
- Hold a committer bootcamp to onboard new developers
|
|
|
|
|
|
4.2.2 Process Development
|
|
|
- Define a development process based on open source best practices
|
|
|
- Modeled after Apache/Linux projects
|
|
|
- Will engage Red Hat and others in the definition of the process so we borrow from experience.
|
|
|
- Define a stakeholder management process for working with the OMC and OSDU Subcommittees
|
|
|
|
|
|
4.2.3 Tooling
|
|
|
- Implement the toolset for managing backlog in a transparent manner
|
|
|
- CI/CD Pipeline
|
|
|
- Issue management
|
|
|
- …
|
|
|
|
|
|
**4.3 90 DAYS:**
|
|
|
4.3.1 Provide a credible (evidence based) plan to complete the R3 release based on a managed backlog and project commitments.
|
|
|
4.3.2 Present to the OSDU F2F meeting
|
|
|
- Current project/technology status
|
|
|
- The project plan for delivering R3
|
|
|
|
|
|
**5 INDICATORS**
|
|
|
- Successful delivery of an OSDU R3 and beyond that complies with the OSDU Standards
|
|
|
- Transparency in process and project status
|
|
|
- Onboarding of new committers and software sourced from companies beyond Schlumberger and the cloud providers.
|
|
|
- …
|
|
|
|
|
|
# **PMC Governance Policy**
|
|
|
|
|
|
**1 INTRODUCTION**
|
|
|
This development governance policy sets forth the general governance processes for OSDU software development. As an overarching goal, development should take place in accordance with meritocracy and Governance by Contribution.
|
|
|
|
|
|
**2 PROJECT MANAGEMENT COMMITTEE**
|
|
|
|
|
|
**2.1 GENERAL**
|
|
|
The PMC is empowered to drive the development of the underlying software. It will manage the implementation of the standard but is not limited to the standard. The PMC’s responsibilities include coordinating high-level goals for Projects, determining programming languages for the PMC Projects, approving Project lifecycles (i.e., Incubation Project to Active Project), controlling Project team headcount and the count for each role, approving new Projects within a PMC, ensuring that Projects within a PMC are operating in accordance with OSDU principles, defining required documentation and testing resources within the PMC, and resolving disputes within a PMC, and keeping the OMC (OSDU Management Committee) informed of Project progress.
|
|
|
|
|
|
**2.2 STRUCTURE**
|
|
|
The PMC will be comprised of the individual Project Leads for Active Projects and a PMC Lead who reports to the OMC. For the first 2 years, the PMC Lead will be provided by Schlumberger and a PMC Vice Lead who will be voted in by the community.
|
|
|
**2.2.1 PMC Chair**
|
|
|
The PMC Chair is responsible for coordinating the activities of the PMC, assisting in resolving differences of opinion within the PMC, and meeting with the PMC members. The initial PMC Chair shall be named by the OSDU Management Committee (OMC) and serve for an initial period of not less than two (2) years, and thereafter will be elected by the PMC Members as described below. The PMC Chair so elected must be a participant of a Member.
|
|
|
**2.2.2 PMC Vice Chair**
|
|
|
There will be a Vice PMC Chair for the first two years to (1) provide balance to Schlumberger’s Lead and (2) accommodate the heavy workload anticipated in establishing a healthy Open Source project.
|
|
|
|
|
|
**2.3 DECISION MAKING**
|
|
|
The PMC shall operate by consensus when possible. If the PMC Chair determines that consensus cannot be reached in any substantive decision within a PMC, a formal vote may be taken from the PMC Members. The PMC Chair shall give weight to the preferences of PMC members according to Governance by Contribution. The PMC Chair may set reasonable and non-discriminatory processes for voting or other means of decision making by the PMC. Any written processes will be communicated to the OMC by the PMC Chair and subject to OMC approval.
|
|
|
**2.3.1 Decisions within a Project**
|
|
|
“Governance by Contribution” within a project is achieved by selecting a voting group made up by committers who have been active in the last six (6) months.
|
|
|
**2.3.2 Decisions across Projects**
|
|
|
Decisions across projects will be based on simple majority within the PMC, with the PMC Lead either voting in the case of a tie or escalating a decision to the OMC.
|
|
|
|
|
|
**2.4 ESCALATION**
|
|
|
Occasionally decisions will need to be taken that exceed the authority of the PMC. In these cases, the PMC will escalate the decision to the OMC
|
|
|
|
|
|
**2.5 SUB-PROJECTS**
|
|
|
The PMC can establish Sub-Projects as logically necessary based on each Project. Each Sub-Project will be led by a Sub-Project Lead responsible for coordinating the activities of the Sub-Project, assisting in resolving differences of opinion within the Sub-Project, and overseeing the activities of the Committers for that Sub-Project. Each Sub-Project Lead is appointed by the PMC Lead, is a member of the PMC, and is the first Committer for that Sub-Project.
|
|
|
|
|
|
**2.6 COMMITTERS AND CONTRIBUTORS**
|
|
|
Contributors include anyone in the technical community that contributes code, documentation, or other technical artifacts to a Project.
|
|
|
Committers are Contributors who have earned the ability to modify (“commit”) source code, documentation, or other technical artifacts in a project’s repository. A Contributor may become a Committer for a Sub-Project by a majority approval of the existing Committers for that Sub-Project. A Committer for a Sub-Project may be removed by a majority approval of the other existing Committers for that Sub-Project
|
|
|
|
|
|
**2.7 PARTICIPATION**
|
|
|
Participation in the Project through becoming a Contributor is open to anyone so long as they abide by the terms herein.
|
|
|
|
|
|
**2.8 TRANSPARENCY**
|
|
|
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.
|
|
|
|
|
|
**3 INITIAL PROJECTS**
|
|
|
There will be multiple projects under the PMC based on scope, governance and velocity.
|
|
|
Projects are subject to change based on PMC proposal and OMC approval.
|
|
|
The initial projects would include:
|
|
|
- Data Platform Services which delivers the data agnostic portion of the system
|
|
|
- Ingestion/Enrichment which focuses on the data specific portions of the code
|
|
|
- Security and Compliance
|
|
|
- Deployment and Operations
|
|
|
- System Administration
|
|
|
- Domain Extensions / Optimizations
|
|
|
There are also be cross cutting concerns which will be managed across Projects:
|
|
|
- API governance
|
|
|
- Reference implementation vs. Vendor specialization.
|
|
|
- Validation and Certification
|
|
|
- Onboarding process – Creating new committers
|
|
|
|
|
|
**4 PROJECT OVERSIGHT**
|
|
|
_Active projects_ are part of the OSDU distribution, participate in the PMC and are subject to all the controls necessary to assure a stable and coherent release.
|
|
|
|
|
|
_Incubation projects_ provide a mechanism for establishing a functioning open-source project in OSDU. These projects are not part of the OSDU distribution; but should be managed under the same development guidelines in preparation for future inclusion.
|
|
|
|
|
|
|Governance|Active Project<br>_Core_|Active Project<br>_Extension_|Incubation Project|
|
|
|
|---|:---:|:---:|:---:|
|
|
|
|Approved by OMC|Yes|Yes|No|
|
|
|
|Member of PMC|Yes|Yes|No|
|
|
|
|Covered by OSDU Standard|Yes|No|No
|
|
|
|Release Management|Yes|Yes|No|
|
|
|
|IP Due Diligence |Yes|Yes |Yes|
|
|
|
|API Support|Yes|Yes|Yes|
|
|
|
|Agile Practices|Yes|Yes|Yes|
|
|
|
|
|
|
**5 DEFINITIONS**
|
|
|
Each capitalized term within this document will have the meaning provided below. Unless otherwise set forth herein, each capitalized term will have the meaning set forth in the Bylaws.
|
|
|
- _“Active Project”_ means a Project that is undergoing active development and is included in the release train process.
|
|
|
- _“Governance by Contribution”_ is the process by which the PMC makes decisions. A Member’s influence within the PMC should be proportional to the investment that Member is making to support OSDU’s mission. Technical influence over the Projects should be proportional to the number and quality of an organization’s Contributions. For OSDU, “Governance of Contribution” is achieved by voting among active (within last 6 months) committers.
|
|
|
- _“Incubation Project”_ means a Project that is proposed for inclusion in the Foundation, undergoing active development, but is not included in the release train process.
|
|
|
|
|
|
|