Info

Process, Project review and recommend sub-committee: Finalize request Templates for Blueprint and feature project, document to allow developers to get started. Develop and evolve the process by which blueprint and feature project proposals are reviewed, and ultimately approved with recommendation required documentation.

Sub-Committee Chair - Biswajit De. EleDec 1, 2020 /Dec 2021

Template 1 - Use case template

Template 2 - Blueprint family template

Template 3 - Blueprint species template

Membership

Please join the Process Sub-Committee mail list by self-adding within the Akraino Mail List Sub-Groups page.

Note: Please ensure that both the name and email address for each member is listed on each sub-committee membership wiki page in order to properly set up CIVS voting when required.

Interested parties sign up:

Process, Project review and recommend, documentation sub-committee members(From Nov 2023~):

We have started the process to elect a new chair for the Process, Project review and recommend, documentation sub-committee.

The process started on 23 Nov and will continue until Noon 15 Dec 2023 (Pacific)

The election process is two steps. The first is for people to self-nominate for the position. To do this, put a Y in the correct column if you wish to run for Chair. The second step is to have an election for the position. If there is only one person who has self nominated, then that person will be chair.

Note: Please ensure that both the name and email address for each member is listed on each sub-committee membership wiki page in order to properly set up CIVS voting when required.

Interested parties sign up:

Name	Affiliation	Email	LF ID	Self nominate as Chair (Y/N)	Self Nominate as Co-Chair (Y/N)

Name	Affiliation	Email	LF ID	Self nominate as Chair (Y/N)	Self Nominate as Co-Chair (Y/N)

Process, Project review and recommend, documentation sub-committee members(From Oct 2020~Nov 2023):

Election - Oct 2020

Chair are supposed to be elected once a year and we are over due for an election. Akraino runs off a self-nomination model, meaning that if you would like to run for Chair, please place a Y in the column. If you do not want to run for the chair position, please put a N in the column.

The self-nomination is now open and will close at noon (Pacific Time) on 28 Oct. If there are two or more nominees, we will proceed to an election. If not, the self-nominated person will become Chair.

Name	Affiliation	Email	LF ID	Chair Self-nomination (Y/N)	Co-chair Self-nomination	Bio

Name	Affiliation	Email	LF ID	Chair Self-nomination (Y/N)	Co-chair Self-nomination
Tina Tsou	Arm	tina.tsou@arm.com	@Tina Tsou (Deactivated)
Tapio Tallgren	Nokia	tapio.tallgren@nokia.com	@Tapio Tallgren (Nokia)
Frank Zdarsky	Red Hat	fzdarsky@redhat.com	@Frank Zdarsky
Jenny Koerv	Intel	jenny.koerv@intel.com	@Jenny Koerv (Deactivated)
Deepak S	Intel	deepak.s@intel.com	@Deepak
Qasim Arham	Juniper	qarham@juniper.net	@Qasim Arham (Deactivated)
Andrew Wilkinson	Ericsson	andrew.wilkinson@ericsson.com	@Andrew Wilkinson
Sukhdev Kapur	Juniper	sukhdev@juniper.net	@Sukhdev Kapur
Wenjing Chu	Huawei	wenjing.chu@huawei.com	@Wenjing Chu
Wenhui Zhang	Penn State	wuz49@ist.psu.edu	@Wenhui Zhang
Gerry Winsor	Nokia	gerald.winsor@nokia.com	@Gerald Winsor (Nokia)
Kandan Kathirvel	AT&T	kk0563@att.com
Adnan Saleem	Radisys	adnan.saleem@radisys.com
Jack Liu	Arm	jack.liu@arm.com
Ryota Ishibashi	NTT	ryota.ishibashi.xy@hco.ntt.co.jp
Hiroshi Yamamoto	NTT	hiroshi.yamamoto.pz@hco.ntt.co.jp
Biswajit De		hibisu2006@gmail.com	@Biswajit De	Y
HaiHui Wang	IBM	haihwang@cn.ibm.com	@haihui wang		Y

Completed Project Graduation Reviews

Graduation reviews

Meeting Content (minutes / recording / slides / other):

Please note minutes of meetings held for graduation reviews are not recorded below but rather in the Graduation reviews section of the sub committee wiki.

July 23rd, 2019

Andrew, Tina, Sukhdev, Tapio, Sharad

Family level PTLs

LF requires a single TSC named maintainer of all repos supported by it. If a Family of BPs utilizes common Family level code and as such Family level repos hierarchically above the individual BP species repos are required, LF requires a named person to be appointed as their maintainer before creation,

To resolve this is the P-SC considered 3 options:

(1) create a new PTL at the Family

(2) create a Akraino Coordination Role to be the authorized maintainer of Family level repos (Akraino Technical Community Document#4.3.3Coordinators)

(3) ask LF to modify their processes to allow any of the BP PTLs to take the role of maintainer

The P-SC recommendation is to, when necessary, appoint a Family level Coordinator Role based on the recommendation of the Family's individual BPs' PTLs. This person could be one of the PTLs or another Akraino community member as proposed by the Family BP PTLs.

When approved the TSC shall then notify the LF once of the identity of appointee of each Family Coordinator Role (if they exist) and at the Family level in the Akraino wiki record the approved Family level (repo) coordinator.

Incase of any need or desire for change the Family BPs' PTLs shall make a new nomination for the coordinator role for the TSC to approve (who shall then update LF and the wiki).

Voter and TSC candidacy eligibility

The P-SC discussed the current contribution based approach to election voter eligibility and TSC candidacy. We noted that the four explicitly identified contribution types in the Technical Community Document ("code, code reviews, Wiki and documentation contributions, Jira activities") are not exclusive and "other artifacts" can be considered by the TSC in determining voter and candidate eligibility.

However the P-SC recommends that

(1) The TSC includes the following as valid criteria for both assessments for the August 2019 election:

The PTLs of BP that have been included in the previous Akraino release (either as self certified or Mature or Core),

Sub Committee Chairs

TSC Chairs

(2) Post the 2019 TSC elections that the Technical Community Document be revisited to explicitly include these as voter and candidacy qualification and also consider any other long term contributions the new TSC may consider likewise.

April 25th, 2019

Andrew, Sukhdev, Thor Chin

P-SC call at 4PM PT to review API GW proposal from Inswinstack

Agreed to introduce as a feature within a blueprint to allow both standalone deployment and wider deployment into other blueprints.

Both members on the process committee had seen and reviewed the material.

Recommendation to TSC is to approve with the note only one committer has currently been identified.

Feb 26, 2019

attendees
- Jim, Tina, Tapio, Andrew, Bill
we reviewed the proposed wording for the use of the name “Akraino” in project titles
- we decided we’ll review this internally…
- “the use of the term Akraino certified BP or FP is restricted to BP or FP that have been verified by the TSC as reaching the minimum level of conformance to the Mature or Core levels”
release 1 milestones
- we’ll add this item to our docket
we started discussing it wrt our Blueprint state table
- how do the two processes fit together?
- RC0, RC1, RC2
  - why 3?
  - Tapio related his experience from OPNFV – need some kind of tracking for sure, but don’t want it too detailed
ideally the milestones would be real tasks, and demonstrable
we brainstormed a list of milestone tasks that we might want to propose
- first deployment in validation lab
- first testing logs shipped up to CI/CD environment
- peer Jenkins is set up & working
- blueprint-specific test plan shared with the Community
- lab is set up for CD
we also discussed that the blueprint should iterate through M3-RC1 as many times as the Blueprint owner thinks makes sense

Feb 19, 2019

Akraino Naming/Badge

Jenny raised the question – is the inclusion/exclusion of the word “Akraino” in the BP/FP name meaningful?
should all names have Akraino in them, or should this only be added when the BP reaches Core?
we agreed to consider the question between now & the next meeting, and to vote on the specific issue of the Akraino name/badge in the next Process sub-committee meeting

Further Review of TCD Section 3.3.4

we picked up the discussion that we started last week - managed to make some progress on finalizing the updates to the first two states

State	Description	Release Quality	Release Numbering	Deliverables / Exit Criteria
Proposal	Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs.	n/a	n/a	3.3.7.1 Incubation Review: - Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters [a checkmark] - Project contact name, company and email are defined and documented [presumably at least one proposer] - Description of the project goal and its purpose are defined [a checkmark – use the templates] - Scope and project plan are well defined [yes to scope, no to project plan] - Resources committed and available - Contributors identified - Initial list of committers identified (elected/proposed by initial contributors) - Meets Akraino TSC Policies [need to define what these are? – Bill to find out what these are – Jenny’s chasing down some language about this] - Proposal has been socialized with potentially interested or affected projects and/or parties (e.g. presented at Community Meeting) - Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects and upstream dependencies, those projects are listed in the proposal, and a sponsoring developer in the project has been identified - Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project passes the review, the tools chain must be created within one week. Tools encompass Configuration Management, CI/CD, Code Review, Testing, Team Wiki, End Users documentation (not exhaustive).
Incubation	Project has resources, but is recognized to be in the early stages of development.	Alpha (MVP)	0.1 to 0.x	3.3.7.2 Maturity Review: On a successful graduation the BP HW/SW package is deemed to be Beta-Quality and the BP moves to the Mature stage. The collective TSC vote as defined in Akraino Technical Community Document#4.4.1TSCDecisionMakingProcess will be based on all the following set of checks being met: Validation lab check: The BP project contributors have deployed and validated the BP in at least 2 community member validation labs or a community member validation lab and LF CD lab with the exact HW and SW configuration for which the maturity review is being requested. All validation labs are required to connect with Akraino LF CI. Logs on the LF CI servers pushed from each validation lab's CD testing would be used to verify this check. The environment should be reviewed and endorsed by the CI/CD Sub-Committee. [Question : Do we really need to have the CI/CD sub-committee review a validation lab's internal CI/CD architecture? If so how would this be practically done since access to the validation lab will not generally be granted to other community members?] Release inclusion check: Successful participation in at least two Akraino release periods in the incubation stage [Note : This implies that nothing will be Mature in Akraino R1 - however a PTL could request a maturity review anytime after R1 i.e. Graduation to Maturity would be possible in R2 from 1st June onwards – TSC should confirm that’s what they want] SW quality/functional check: The SW quality will be assessed as reaching beta according to : Precise HW requirements and descriptions are defined and included in the BP's documentation (as used in both lab validations) Upstream dependencies check: Upstream dependencies must be clearly defined Documentation check: Documentation subcommittee to provide a recommendation on graduation, or if not with items requiring action/remedy. This check includes verification that any supported APIs are clearly documented Community Health and Stability check: PTL should provide a summary of contributors and committers and companies and demonstrate growth - Project is active and contributes to Akraino: The project demonstrates increasing number of commits and/or number of contributions across recent releases. Contributions are commits that have been to an Akraino repository project or related upstream project. Commit examples can be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new additional test cases and so forth. [maybe create a template, or use something like Bitergia to get some consistent metrics coming into this review]. The PTL should demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.
				3.3.7.3 Core Review: On a successful graduation the BP HW/SW package is deemed to be GA-Quality and the BP moves to the Core stage. The collective TSC vote as defined in Akraino Technical Community Document#4.4.1TSCDecisionMakingProcess will be based on all the following set of checks being met: Deployment check: The BP project been deployed in at least 2 production networks/locations with the exact HW and SW configuration for which the core review is being requested. Release inclusion check: Successful participation in at least two Akraino release periods in the mature stage SW quality/functional check: The SW quality will be assessed as reaching GA quality according to : Precise HW requirements and descriptions are defined and included in the BP's documentation (as used in both the lab validations and the production deployments) Upstream dependencies check: Upstream dependencies must be clearly defined Documentation check: Documentation subcommittee to provide a recommendation on graduation, or if not with items requiring action/remedy. This check includes verification that any supported APIs are clearly documented. [It is expected the documentation requirements for a core review be more stringent/extensive than an mature review] Community Health and Stability check: PTL should provide a summary of contributors and committers and companies and demonstrate growth - Project is active and contributes to Akraino: The project demonstrates increasing number of commits and/or number of contributions across recent releases. Contributions are commits that have been to an Akraino repository project or related upstream project. Commit examples can be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new additional test cases and so forth. [maybe create a template, or use something like Bitergia to get some consistent metrics coming into this review]. The PTL should demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.

Feb 12, 2019

Recording

/

Review of TCD Section 3.3.4

We discussed the following table, which expands on what’s already there in section 3.3.4, and adds…

Release Quality

as discussed in previous meeting – just moved it to its own column

Release Number

as discussed in previous meeting – an initial stab at it from last week's discussion

Deliverables / Exit Criteria

pulled in the “review metrics” from section 3.3.7.1 – 4

The intent is to simplify this section, putting everything in one place. We got through the first two states this week...

State

Description

Release Quality

Release Numbering

Deliverables / Exit Criteria

Proposal

Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs.

n/a

From 3.3.7.1 Incubation Review:

- Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters [a checkmark]

- Project contact name, company and email are defined and documented [presumably at least one proposer]

- Description of the project goal and its purpose are defined [a checkmark – use the templates]

- Scope and project plan are well defined [yes to scope, no to project plan]

Process, Project review and recommend, documentation sub-committee

Contents