Notes from meeting with Krzysztof Opasiakon Dec 16. Purpose of meeting was to get additional details and clarity on new tasks for M1, based on the new release process.
Project Tasks
Create Jira for every Global Requirement
Revise as "Create project Jira task for each Global Requirement" and move to M2
...
- Could this become burdensome over time if we build up many Global Requirements?
- Are all GRs applicable to all projects?
- Krzysztof Opasiak No, but we want them to add a task, anyway, and explain why the GR is not applicable, in order to support traceability
Define rules of patch inclusion for this release
Purpose is to define whether a project is willing to accept new features, and under what conditions.
PTLs to complete table: https://wikilf-onap.onapatlassian.orgnet/wiki/x/5SGLBQLRT7. In particular, PTLs should indicate if they need help with GRs or other backlog tasks. In other words, this enables projects to offer the opportunity to add a new feature, in return for help with GRs or backlog tasks.
Requirement Owner Tasks
Note: combine these 3 into a single task.
Feature
Release Manager to remind community that it’s high time to discuss your
Features with impacted PTLs and arch subcommittee
Spec
Release Manager to remind community that it’s high time to discuss your
Specifications with impacted PTL
Best Practice
Release Manager to remind community that best practices must socialize with PTLs (i.e., present to PTL meeting) and get approval from the TSC. Not approved automatically when listed on wiki page.
Every requirement owner has to update „Impact View per component”
table and get a green light from all impacted PTLs before feature/spec can
be approved
Instead of task, update REQ description template to include a section for documenting API changes, in consultation with affected PTLs.