The OSDU Data Platform Core Services is an OSDU PMC Project and complies with the OSDU PMC Charter. The following are guidelines specific to this project.
Project Governance is based on meritocracy and contribution. For Release 3, contribution is largely provided by the following companies (alphabetical) at roughly equal levels of commitment and thus represents the voting block for the project. The following are our voting committers for significant decisions:
- Amazon Web Services, represented by @babeal
- Google, represented by @fargyle
- IBM, represented by @wladmirf
- Microsoft, represented by @dkodeih
- Schlumberger (initial contributor of the core services), represented by @ethiraj
To create scale in the project, we also have Maintainer Committers who are granted authority to submit and approve changes to the master branch.
These Maintainer Committers are recognized as individuals in terms of meritocracy and authority with the following caveat. The OSDU code repositories contain both Common Code and Platform Specific code. The maintainer committers will operate in good faith and respect the areas in which they are most knowledgeable about.
Consensus model and Voting
Ideally Open Source projects operate on a daily basis with very little formality. However, the diversity of deployment environments and associated impact on technical architecture and sustainability will lead to inevitable conflict. When these arise, we will follow a decision process that is driven by trade-off analysis, resolved through voting and documented via decision records.
When consensus is not met we will follow a trade-off analysis in which competing ideas are assessed against project goals on the principle that the health of the entire system and subsequent and sustainable adoption by customers is more valuable than any single technical decision.
- Simple majority (51%) for any decision that does not introduce a breaking change to a commitment or deployed production version of the system
- Super majority (75%) plus escalation to the PMC for any decision that does introduce a breaking change to a commitment or deployed production version of the system
Decisions will be documented using the Issues list for this GitLab repository and labeled as a project decision (impacts scope and timeline) and/or architecture / technology decision (impacts implementation) as shown in this example #8 (closed)
Definition of Done
The OSDU Data Platform Core Services has the ambition of continuous delivery and thus has the ambition of continuous done. Because of this, Done has a stronger contract at a feature level than it does at a service level.
A feature is not done until it is running and validated on multiple cloud platforms and ready for consumption. A feature will be:
- Internal for code maintenance
Given the multi-platform deployment requirements, we will consider feature done from a common code perspective once it is demonstrated on two or more cloud platforms. It will be done from the OSDU Forum perspective once available on all supported platforms. This distinction allows OSDU platform deployments to move a slightly different speeds to allow early feedback in a production environment.
Continuous delivery requires continuous backlog pruning and thus there is no preconceive notion of done. That is a idealized statement that is only true once a system has reached a level of maturity allowing autonomous delivery of services.
For Release 3 we will define a specific scope of work which will be documented both in narrative form as well as issues. See Release 3 Planning.