|
|
|
This is the initial draft of Ground rules for engagement for R3 which we hope can be carried forward beyond R3 as well. It is important to balance Agility and Governance to deliver a working model for OSDU platform development.
|
|
|
|
|
|
|
|
1. Review and align on business drivers and relative priority – Force rank if required
|
|
|
|
- Work closely with OMC and the release workstream leads to pick out the ‘essence’ for a release
|
|
|
|
1. Establish a clear definition of done across all contributors – [R2](https://community.opengroup.org/osdu/documentation/-/wikis/OSDU-(C)/Roadmap/OSDU-Release-2-Details/Done) example, R3 proposed
|
|
|
|
1. Review and align on key Architecture Decision Records – [ADR examples](https://community.opengroup.org/groups/osdu/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name%5b%5d=ADR%3A%3AApproved)
|
|
|
|
- Engage Enterprise Architecture, Information Security and Data Definition sub-committees as required
|
|
|
|
1. Transparency in plans, deliverables, risks, changes, decisions, …
|
|
|
|
- Build in an Open Source Environment based on community GitLab
|
|
|
|
- Work with program managers to conduct reviews to forum, OMC, PMC teams regularly
|
|
|
|
1. Capture and review risks regularly
|
|
|
|
- Communicate and escalate – awareness and mitigation is key to avoid stall
|
|
|
|
1. Divide and conquer – Define projects and grouping to facilitate parallel contribution and minimize coupling.
|
|
|
|
- Definition of core, extension and domain projects to allow core to be stable, slow-evolving while allowing feature additions in extensions and domains enabled in domain projects
|
|
|
|
1. Avoid waterfall, big-bang release – Embrace agile, incremental releases
|
|
|
|
- “Platform release” – loosely tied to core project release version
|
|
|
|
- Release extensions and domains as and when ready on top of the core
|
|
|
|
- R3 = continuously delivered extensions to R2 with incremental value
|
|
|
|
1. Establish a regular cadence for project releases
|
|
|
|
- Avoids expectation of large feature critical mass and potential delays
|
|
|
|
- Features that don’t make current release candidate makes the next one
|
|
|
|
- Select a two to three sprint cadence – ala release every 1 to 2 month cycle |