...

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

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: