... | @@ -6,24 +6,24 @@ This is the initial draft of Ground rules for engagement for R3 which we hope ca |
... | @@ -6,24 +6,24 @@ This is the initial draft of Ground rules for engagement for R3 which we hope ca |
|
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 done](https://community.opengroup.org/osdu/platform/home/-/wikis/Planning/R3/Done)
|
|
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 done](https://community.opengroup.org/osdu/platform/home/-/wikis/Planning/R3/Done)
|
|
|
|
|
|
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)
|
|
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
|
|
- Engage Enterprise Architecture, Information Security and Data Definition sub-committees as required
|
|
|
|
|
|
1. Transparency in plans, deliverables, risks, changes, decisions, …
|
|
1. Transparency in plans, deliverables, risks, changes, decisions, …
|
|
- Build in an Open Source Environment based on community GitLab
|
|
- Build in an Open Source Environment based on community GitLab
|
|
- Work with program managers to conduct reviews to forum, OMC, PMC teams regularly
|
|
- Work with program managers to conduct reviews to forum, OMC, PMC teams regularly
|
|
|
|
|
|
1. Capture and review risks regularly
|
|
1. Capture and review risks regularly
|
|
- Communicate and escalate – awareness and mitigation is key to avoid stall
|
|
- 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.
|
|
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
|
|
- 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
|
|
1. Avoid waterfall, big-bang release – Embrace agile, incremental releases
|
|
- “Platform release” – loosely tied to core project release version
|
|
- “Platform release” – loosely tied to core project release version
|
|
- Release extensions and domains as and when ready on top of the core
|
|
- Release extensions and domains as and when ready on top of the core
|
|
- R3 = continuously delivered extensions to R2 with incremental value
|
|
- R3 = continuously delivered extensions to R2 with incremental value
|
|
|
|
|
|
1. Establish a regular cadence for project releases
|
|
1. Establish a regular cadence for project releases
|
|
- Avoids expectation of large feature critical mass and potential delays
|
|
- Avoids expectation of large feature critical mass and potential delays
|
|
- Features that don’t make current release candidate makes the next one
|
|
- 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 |
|
- Select a two to three sprint cadence – ala release every 1 to 2 month cycle |