Jakarta: Lessons Learned
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 | @cl664y@att.com | 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. | @Amy Zwarico | Done for the Kohn release. |
3 | Update documentation tasks to refer to documentation procedure P02 developed by the DOC team | @Thomas Kulik | Done for the Kohn release. |
4 | Adjust license scan review tasks to match new scan cadence | @David McBride | 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). | @David McBride | 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. | @Thomas Kulik | Still thinking about this one |
8 | Spring scheduling for releases should account for Ascension Day and Juneteenth | @David McBride | Will apply to the London release. |
9 | Platform Maturity Matrix - Kohn Release Platform Maturity to be completed at M4 only | @cl664y@att.com | 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 | @cl664y@att.com | Must be applied to the London release. |
11 | Review the Release Planning Template considering the new release cadence. Is there anything we could remove? | @cl664y@att.com | to be discussed with PTLs |
12 | |||
13 | |||
14 |