| Description | Documented By | Comments / Followup | |
|---|---|---|---|
| 1 | Expand task to color code view per component page to include specific instructions for best practices and global requirements | Task updated in script for the London release. | |
| 2 | On the view per component page, break out global requirements and best practices into separate tables. | Done for the Kohn release. | |
| 3 | Update documentation tasks to refer to documentation procedure P02 developed by the DOC team | Done for the Kohn release. | |
| 4 | Adjust license scan review tasks to match new scan cadence | Done for the Kohn release | |
| 5 | Plan coordinating meeting with ODL following ONAP TSC approval of each release schedule. Goal is to have ODL release available at least 1 mo prior to M3 milestone | Dan Timoney | Done for the Kohn release. |
| 6 | Avoid overlaps between releases (e.g. Jakarta Sign Off and Kohn M1). | Will be observant for this issue for future releases. | |
| 7 | Add tasks for subcommittees as needed. For example, SECCOM should branch repo when projects branch. | Still thinking about this one | |
| 8 | Spring scheduling for releases should account for Ascension Day and Juneteenth | Will apply to the London release. | |
| 9 | Platform Maturity Matrix - Kohn Release Platform Maturity to be completed at M4 only | Will apply to the Kohn release. | |
| 10 | Define enough time between M1 and M2 milestones as M1 usually occurred when previous release is still ongoing. M2 milestone requires significant time as PTLs need to collect commitments from the different companies while having an agreement on functional/non functional requirements | Must be applied to the London release. | |
| 11 | Review the Release Planning Template considering the new release cadence. Is there anything we could remove? | Catherine Lefevre | to be discussed with PTLs |
| 12 | |||
| 13 | |||
| 14 |
Overview
Content Tools