Contents

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 - Jim Einarsson.  Elected 11/14/2018

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:

Project Reviews

• Akraino Project Reviews

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

Feb 5, 2019

• Attendees
  • Jim Einarsson, Jenny Koerv, Aaron Byrd, Andrew Wilkinson, Frank Zdarsky, Mike Hunter, Bill Zvonar
• Release Cadence
  • we talked about proposing a cadence to the TSC
  • currently, there’s talk of a second release in 6 months, but not of a cadence, per se
  • we agreed to park this for later 
• Proposed Changes from Last Process Sub-Committee Meeting
  • we agreed to get those to vote at the TSC
  • ACTION: Bill to get those on the agenda for the next TSC meeting
• More Proposed Changes
  • Andrew asked about MVP re: Incubation - MVP as an "outcome" - doesn't seem right 
  • instead, it should say something like During incubation, an MVP-quality product will be demonstrated (Alpha).
  • discussion on Alpha/Beta/GA vs. Incubation/Mature/Core ensued 
  • we agreed on the following revised wording in section 3.3.4 (Project Lifecycle States and Reviews) of the TCD… 
    • Incubation
      • Project has resources, but is recognized to be in the early stages of development.  In the Incubation state, the goal is to progress the project from Alpha (MVP) quality to Beta quality.The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments.
    • Mature
      • Project is fully functioning and stable, has achieved successful releases.  In the Mature state, the goal is to progress the project from Beta quality to GA quality.  
        
    • Core
      • Project provides value to and receives interest from a broad audience.  In the Core state, the project is at GA quality – additional functionality may be added in subsequent releases.
        
    • Archived
      
      • Project can reach Archived state for multiple reasons.  Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.).  Project in any state can be Archived through a Termination Review.  In the Archived state, the project is Deprecated - no further bug fixes, security updates, etc. 
  • ACTION: Bill to get this on the agenda for the next TSC meeting as well 
• Checklists for Graduation 
  • further discussion on clarifying/simplifying the deliverables that should be delivered in each state, and the exit criteria for graduating from one state to another
  • stuff like security checklists, and other things that might be specific to a given BP Family
  • also should add language around release numbering - e.g. is "Mature" always Release 1? or Core? 
  • we agreed to start a table of such details
  • ACTION: Bill to start the table of States, Deliverables, etc.

Jan 29, 2019

Attendees: Jim Einarsson, Tina Tsou, Tapio Tallgren, Andrew Wilkinson, Bill Zvonar

• Trouble Starting the Meeting
  • likely because Zoom bridge wasn’t completely closed at the end of the TSC Working Group meeting – note to selves for our meeting
• Review Feature Project Template (per last TSC)
  • Context
    • Wiki: https://wiki.akraino.org/display/AK/Akraino+Blueprint+Validation+Framework
    • the Process Sub-Committee was asked in the last TSC to review this feature project
    • Jim noted that Jenny had questioned in the last TSC meeting whether we (the Process Sub-Committee) should “approve” this project into Incubation – or rather, should we limit ourselves to saying whether the template is ok or not
    • Jim further noted that we had created some “Blueprint” criteria, but not for a “Feature Project” – so would it be the same?
  • Committers
    • Tapio asked if there should be Committers identified at this point – this led into a discussion about *when* in the project lifecycle the Committers need to be identified
• TCD Changes re: PTL/Committers & Project “Start”
  • would the project just die if there were no Committers? or would it just go On Hold?
  • can you enter Incubation *then* identify Committers?
  • you have to have at least 1 Committer *Company* identified
  • Committers to be named up until the PTL election
  • ACTION: two changes proposed to the TCD – bring to the TSC meeting
    • indicate when Committers are to be added to a Feature Project during PTL elections, after which the project ‘starts’ 
      • section 3.2.2.1
      • Initial Committers for a project will may be specified at project creation and up until PTL election.  The project is not started until after the PTL election.
      • indicate that a Project “starts” at the beginning of the Incubation state
        • section 3.3.4
        • in the “Incubation” row of the table in section 3.3.4
          • Project has resources, but is recognized to be in the early stages of development. The project is considered to have started upon successful PTL election.  The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments.
  • in terms of the content of the Feature Project Template, we questioned what is meant by ‘Akraino ready / validated’?
• didn’t get to these agenda items, will table them for next week’s meeting
  • Discuss/align on bronze/silver/gold
  • Kick off splash page /spreadsheet for “mature” graduation
  • Other topics

Jan 15, 2019

Attendees: Tina Tsou, Jenny Koerv

1. Formal motion at next TSC meeting to vote on action to revise

   1. TCD sections 3.3.7.1 and 3.3.4 discussed in 11/30 Process Sub-Committee and shared/agreed/implemented at TSC F2F 12/6-7 (summary/language recommendation here: 2018-11-30 Meeting notes). 
   2. Clean up/changes to TCD 3.3.8.1 and 3.3.2.3.1 language discussed/presented in TSC Meeting 1/10 (see minutes/slide 4 here Technical Steering Committee (TSC)).
   3. More specific language in Maturity Review 3.3.7.2.
      
      1. Successful participation in at least two releases: The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.
      2. Architecture has been reviewed by the Architecture Committee CI/CD Sub-Committee, TSC and presented to broader Akraino community?
      3. Project Contributors have provided a validation lab with exact configuration required by the project to connect with Akraino CI and demonstrate CD.  The environment should be reviewed and endorsed by the CI/CD Sub-Committee.
         
      4. Project is active and contributes to Akraino: The project demonstrates a stable or an increasing number of commits and/or contributions across recent releases measurable by TSC discretion. Contributions are commits which got that have been merged to a repository of an Akraino project repository or a related upstream project. Commit examples are can for example be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new test cases and so forth.
         
      5. Mature artifacts produced: The project demonstrates that the artifacts produced by the project are deployable (where applicable) and have been successfully deployed, configured and used by at least two independent end users (typically, service providers) who have publicly documented their support on the Akraino wiki and within the accompanying project documentation.
         

2. Ask for TSC to review the following as considerations for Maturity Review criteria:

   1. LF CII best practices: https://bestpractices.coreinfrastructure.org/en
   2. Contributor Code of Conduct: https://www.contributor-covenant.org/version/1/2/0/code-of-conduct.html
3. The advantage and desire to have a simple graduation splash page on the Akraino Wiki (Under Process Sub-Committee or otherwise).  That simply outlines the Project LifeCycle and Graduation criteria (comparable to the CNCF page here: https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc ).  Jenny to take a stab at it…
4. The need for the TSC to agree on detail language of Review votes for graduation (Majority?  2/3?).  The follow up need to document that the TSC vote is to determine whether Criteria have been adequately met for advancement. Note: Jenny afterthought – did not formally get to this in this meeting.
5. Should section 3.3.7.3 Core Review include the Conformance language?  Should Conformance badge warrant the “Akraino” brand and define the “Akraino” value? Jenny afterthought – sent related note to TSC in context of “Akraino Portal Feature Project”

Jan 8, 2019

• • Update Technical Community Document criteria
  • To achieve maturity phase, at least two independent users should demonstrate/document deployment subject to TSC review, must have achieved multiple releases and have a release plan, must be able to demonstrate/document increasing contributions.
  • Minor releases – i.e point releases (in maturity phase) and major release (to achieve core phase) of a blueprint should be delivered
  • Conformance criteria will be defined by the TSC for each blueprint and feature project would be established via the Akraino Conformance Validation feature project and the results of conformance testing for each blueprint / feature project would be used in TSC voting.  Feature project criteria should include validation of upstream community contribution to the feature project to avoid duplication of effort.
  • For feature projects to move into maturity phase, the submitted would be required to identify the blueprint(s) that have benefitted from the feature project
  • Section 3.3.8.1 of the Technical Community Document defines a 'Release Plan' for Maturity.  List is redundant/repeated.  Need to edit TCD. 
  • 3.3.2.3.1 language calls out Feature project testing in Community CI lab, and integration of feature projects into a BP in Community CI lab. Might be problematic if CI lab is not mirror of Flock lab testing.  Need to change the language in the TCD to say that the integration / feature projects need to be deployed to the Akraino Validation (Flock) Lab.
  • For code submission criteria, LF ID (approved project committer – PTL manages the process), Akraino CI/CD process, specifications defined and documented, approvers of specifications.

November 30, 2018  minutes

December 6, 2018 TSC Meeting Blueprint Review:

-          Attendees

o   Jim Einarsson, Jenny Koerv, Aaron Byrd, Andrew Wilkinson, Frank Zdarsky, Mike Hunter, Bill Zvonar

-          Release Cadence

o   we talked about proposing a cadence to the TSC

o   currently, there’s talk of a second release in 6 months, but not of a cadence, per se

o   we agreed to park this for later

-          Proposed Changes from Last Process Sub-Committee Meeting

o   we agreed to get those to vote at the TSC

o   ACTION: Bill to get those on the agenda for the next TSC meeting

-          More Proposed Changes

o   Andrew asked about MVP re: Incubation – MVP as an “outcome” – doesn’t seem right

o   instead, it should say something like During incubation, an MVP-quality product will be demonstrated (Alpha).

o   discussion on Alpha/Beta/GA vs. Incubation/Mature/Core ensued

o   we agreed on the following revised wording in section 3.3.4 (Project Lifecycle States and Reviews) of the TCD…

o   ACTION: Bill to get this on the agenda for the next TSC meeting as well

-          Checklists for Graduation

o   further discussion on clarifying/simplifying the deliverables that should be delivered in each state, and the exit criteria for graduating from one state to another

o   stuff like security checklists, and other things that might be specific to a given BP Family

o   also should add language around release numbering – e.g. is “Mature” always Release 1? or Core?

o   we agreed to start a table of such details

o   ACTION: Bill to start the table of States, Deliverables, etc.