Just some initial thoughts - We all need to review the ONAP Beijing Lesson Learned and Casablanca Process Improvement to see how many we did/still need to bring forward. -kenny
Kenny Paul - license awareness: Every month when Steve runs his code scans we are constantly revisiting the same problems, often in the same repos:
- Project Clearwater GPL-3.0 code (which is just never, never going to be usable in any ONAP repo)
- New .csar files getting (re)added with "AT&T Proprietary" notices in them
- archive files (.zip, .tar.gz, and the like) being dumped in "just in case they are needed". Between RC0 and RC1 a single .wgn file someone committed contained about 1000 third-party Python files under ~15 different licenses.
Kenny Paul - from Nov 12 PTL meeting
- Add a process/policy around the cut-off dates in the release cycle for addressing vulnerabilities within the required 60 day window
- implement a " three strikes rule " to remove a PTL from a project if they fail to attend X number of TSC and PTL meetings w/o a designated proxy..
Requires a modification to Section 3.1.3 of the Community document
Kenny Paul - On-boarding new projects or usecases
- Improved documentation of who to talk to (which subcommittees) and when to do so. Seems to be more tribal knowledge based versus a clear process.
Gildas Lanilis Gmail - Make description Field mandatory in JIRA (for all type of issues)
- There are too many cases where people neglect to describe the issue they encounter, the expected behavior, the environment they are working one.
Gildas Lanilis Gmail - Obtain formal engagement from committer prior to M1
- By M1 Release Planning, PTLs should obtain formal written commitment from "committers" list on their engagement for Dublin Release. (no response from committer must be interpreted as a disengagement)