Attendees & Representation

TAC Members and Project representatives should mark their attendance below 

• Action Item Review (Backlog)

• TAC Quality & Security Goals Meeting @Muddasar Ahmed

• Open Innovation Network (Link ) - Need to add LFN projects to the Linux System Definition - @Ranny Haiby

• Project Induction & Lifecycle Review @Casey Cain

  • Everything is in Draft. Community support is welcome!

  • https://github.com/lfnetworking/governance-automation/blob/main/README.md

  • https://github.com/lfnetworking/governance-automation/issues/4

  • https://github.com/lfnetworking/governance-automation/issues/5

  • https://github.com/lfnetworking/governance-automation/issues/2

TAC Quality & Security Goals

• @Muddasar Ahmed Raised the need to establish contact with security champions/representatives from all LFN projects (specifically mentioned needing contacts for Paraglider, Silva, and others). Beth C. confirmed she is the security rep for Anuket.

  • The goal is to foster collaboration towards consistent security best practices across projects (e.g., bug reporting, code scanning, review processes) without dictating specific tools. Traceability and record-keeping are important.

  • Requested TAC members representing projects to help identify the right security contacts within their projects.

• @Olaf Renner Highlighted the relevance to upcoming European regulations like the Cyber Resilience Act (CRA), which introduces the role of an "open source steward" (potentially LF) with obligations around security policies and vulnerability reporting. Having a reliable contact list is crucial.

  • @Muddasar Ahmed mentioned similar trends with US executive orders and regulations and stressed the importance of demonstrating the quality and security of LFN projects through transparency and standards to counter outdated perceptions that open source isn't "prime time ready," especially given their use in production networks by service providers.

  • @Beth Cohen Noted that industries like Telecom heavily use open source and perform their own rigorous security reviews, generally not perceiving open source as inherently insecure.

• @Fatih Nar Asked about LFN's strategy regarding observability (metrics, logs, traces) as a foundation for security detection and response within deployed solutions. Queried if an observability workgroup exists.

  • @Muddasar Ahmed outlined current observability aspects (LF engineering/software factory, code/contributor tracking) but noted inconsistencies across projects. Referenced efforts like OpenSSF scorecards and dashboards (like ONAP's) to improve visibility but stressed the need for cross-project champions to define common best practices.

  • @Ranny Haiby suggested moving the deep dive on security (especially runtime observability raised by Fatih N.) to the dedicated Monday security meetings or a new workstream. He differentiated between securing the software factory (current focus, related to CRA) and runtime security. Acknowledged the need for an LFN story/recommendation on observability.

Open Innovation Network (Link ) - Need to add LFN projects to the Linux System Definition - @Ranny Haiby

• @Ranny Haiby Explained OIN as a consortium providing mutual defense against patent litigation, centered around a "Linux System Definition." LF Legal strongly recommends LFN projects be added to the OIN Linux System Definition for enhanced patent protection. This is free and low effort, just requiring submission. The definition covers more than the OS kernel (e.g., Kubernetes), and most LFN projects likely qualify due to Linux usage. Submissions are per-release. Ranny H. has started drafting submissions for graduated projects.

• Help Needed: Ranny H. requires assistance identifying the correct repository/download links for all sub-components of ONAP and Fido, as they don't have single download packages.

Project Lifecycle States & Automation Tool

@Casey Cain spoke about the need to improve the onboarding of new LFN projects, as well as the lifecycle health reviews. To accomplish this, we had previously discussed borrowing the workflow from CNCF. Casey mentioned that he had started a proof-of-concept tool (built using AI - Gemini) hosted on GitHub.

• Proposed new lifecycle states: Spark (replaces Candidate), Incubation, Active (replaces Sandbox), Stable (replaces Graduated), Maintenance/LTS (new), and Archived.

• Tool Functionality:

  • Uses configurable data thresholds (classify-config.yaml) to assess project/repo metrics (from GitHub initially; Garrett data via mirror).

  • Classifies repos/projects into the defined lifecycle states.

  • Automatically creates GitHub issues (issues-config.yaml) at the project/org level, providing guidance, tracking tasks (e.g., update security contact, improve OpenSSF score), and suggesting steps to reach the next lifecycle state.

  • Can potentially automate parts of the project induction process and health reviews.

  • Links to the tool repo and configurations were shared (assumed in meeting chat/agenda).

• Discussion & Feedback:

  • General Idea: Generally positive reception to the idea of automation and better lifecycle alignment (Beth C., Olaf R.). Muddasar A. questioned the demonstrated need/time-saving aspect but acknowledged Casey C.'s points about solving health reviews and standardizing induction.

  • Lifecycle States:

    • Support for adding a 'Maintenance/LTS' state (Beth C., Casey C.). Beth noted Anuket is likely in this state.

    • Debate on renaming 'Candidate' to 'Spark' (Ranny H., Beth C. felt 'Candidate' conveyed meaning better; Casey C. liked 'Spark' but wasn't fixed on it).

    • Agreement that the proposed states (Spark/Candidate, Incubation, Active, Stable, Maintenance, Archived) are a good starting point for discussion.

  • Tool Usage: Beth C. asked who would use it. Casey C.: Primarily project communities via generated issues, potentially TAC/Board via reports later. Can track various metrics like security contact activity.

  • Integration: Frank B. asked about LFX Insights overlap. Casey C.: LFX doesn't provide the automated actions/reporting this tool aims for; could potentially complement/replace some reporting aspects (e.g., election eligibility). LJ I. asked about syncing state names with PCC (LF's system); Casey C. confirmed initial talks and George K. escalated, but changes depend on TAC finalizing states/metrics. Scott N./Todd W. from Formation team likely need involvement.

  • Implementation: Muddasar A. noted not all projects use GitHub directly (Garrett mirrors exist); tool needs to account for this. Suggested a roadshow to project TSCs for buy-in. Olaf R. suggested starting simply by implementing current wiki criteria, then expanding.

  • Next Steps: Casey C. requested feedback via the GitHub repo issues, focusing initially on agreeing on the lifecycle states and then defining the data thresholds for each. Encouraged attendees to share with their project communities.