Academy Software Foundation Technical Advisory Council (TAC) Meeting - May 28, 2025

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - Diversity & Inclusion Working Group Representative, OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative
Rachel Rose - Diversity & Inclusion Working Group Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Academy Software Foundation
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Michelle Roth - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Lee Kerley, Apple
Doug Walker, Autodesk / OCIO
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Karen Ruggles, DeSales University
Lorna Dumba, Framestore
Alyssa Alexis, SIGGRAPH
Tommy Burnette, ILM / ML WG
Cory Ormand, Walt Disney Studios
Deke Kincaid, Digital Domain

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

General Updates
- Dev Days - May 15, 2025 #966
- OpenQMC #434
- Rename project lifecycle stage ‘Adopted’ to ‘Graduated’ #999
- DigiPro CFP closes 5/16 #1003
- Open Source Days 2025 #1005
- Propose to remove vote for annual reviews #1016
- Launching Machine Learning WG #1046
- SMPTE 2025 Annual Technical Conference - CFP closes 5/31 #1049
- Add option for Lightning Talks at TAC meetings #1039
Annual Review: OpenCue #495
TAC Overview presentation #1062

Notes

General Updates
- Dev Days - May 15, 2025 #966
  - Carol: will give update once everything is settled. Larry: gathering the numbers, tricky to track every participant / PR, some PRs have landed but not merged yet.
  - John: make sure to take issues / PRs with devdays25
- Open Source Days 2025 #1005
  - Emily: need projects to sign up for Virtual Town Halls and BoFs, for now we only have one day, but we need to know if we need more. If all timeslots are taken write your name at the bottom so I can figure it out.
  - Larry (chat): I just signed up for OIIO & OSL town hall slots minutes ago. Pleased by the coincidence that there were free slots in the day of week and times for our usual TSC meetings so that was an easy choice to exploit our usual habits!
- Launching Machine Learning WG #1046
  - Doodle launched for meeting time
  - Larry: just posted the Doodle poll link, will try to pick the best time. Those reporting companies, this is your chance to point something at the group
- SMPTE 2025 Annual Technical Conference - CFP closes 5/31 #1049
  - John: still trying to attend? Emily: no projects planning to attend right now, but if someone is planning to attend / submit, let me know ASAP.
Annual Review: OpenCue #495
- Slide Deck
- Diego: TSC OpenCue Chair
- TSC: Brian Cipriano, Diego Tavares, Ramon…
- Agenda
  - OpenCue History
  - Last Year Review
  - …
- OpenCue History
  - Developed at Imageworks 22 years ago
  - Has been used on every movie produced, 100s
  - Cue3 starts in 2003 by Matt Chambers
  - Open Source in 2019
  - Graduated to Adopted in 2021
  - Sci-Tech Award in 2023 for Matt Chambers
- Last Year Review
  - Resolve Stale PRs
    - 100s stale resolved / closed, all PRs are active
  - Cueweb
    - A new webpage for interacting with the Cue
    - Not abandoning Qt based tool
  - Containerized Frames
    - Each job runs on its own docker container
    - Helps with OS upgrades, don’t have to upgrade whole farm at once
    - Can upgrade farm to new OS, but run workloads on older OS
  - First Major release (v1)
    - Releases are now frequent, at least 1 every 6 months
    - Was a complaint / feedback from last review
  - Loki - Log aggregator
    - Support for frame logs
    - Doesn’t require a central file system
    - Search logs via Grafana
  - Slack is now our main communication channel
    - Not using mailing lists
- Community Overview
  - 2023/2024: PR took 3 months to be reviewed, would lead to demotivation
  - 2024/2025: PR took 8 days before merging, 2-3 days for review
  - Retention: used to be 12%, now around 100%, avoids users running their own fork, Imageworks now using the main branch
  - PRs
    - 2023/2024 - 88
    - 2024/2025 - 515
    - All PRs submitted were merged, or still being worked on. Changes are being used in production quickly.
- Next Year Forecast
  - Goals
    - Redesign agent (Rqd) on rust (was Python)
    - Migrate the opencue.io webpage and docs to Github pages
    - Make OpenCue Off-the-shelf
      - Release server on Docker-hub (already done)
      - Release pip packages for GUI, API and agent, instead of having to build your own
    - Optimize booking query
      - Improve performance
      - Increase capacity
      - Reduce dependency on Database performance
- Questions
  - JF: we now have a PyPI ASWF org
  - Larry: what can you use help from TAC / Community? You seem to have improved a lot over last year, but areas you could ask for help?
    - Diego: we could use help with exposure, we did it at last SIGGRAPH, had 3-4 companies join, but want to be able to show updates, remind people that OpenCue exists
  - John: we will do the vote on LFX
TAC Overview presentation #1062
- Presentation Slides
- Larry: don’t want to just do a wall of text, should be discussion points, don’t hesitate to ask questions. Org as a whole is 6 years old, we look around the table and have a lot of projects which came in, rotating people, so worth a refresher for everybody.
- Technical Advisory Council (TAC) Overview (May 2025)
- ASWF Structure
  - Governing board: financing, organization
  - TAC
    - Projects
  - Outreach Committee
- Working Groups
  - CI: long running
  - D&I: long running
  - USD: long running
  - Some have deliverables
  - Some have finished: Python3
- TAC Responsibilities
  - Set overall technical vision for the ASWF
  - Approving new projects and WGs
  - Oversee project lifecycle
  - Enable collaboration between projects and WGs
  - Make recommendations to budget committee for resource needs
  - Voting on other decisions that come before the TAC
    - We used to do it live, we now are doing it online, saves time and effort
  - Additional responsibilities in section 7 of ASWF charter
- TAC is not responsible for
  - Does not manage day-to-day activities and operations of hosted projects and WGs, such as committer rights, release schedules, roadmaps
  - TAC is not responsible for day-to-day operations of ASWF. This is responsibility of foundation staff.
  - TAC does not directly manage budget for ASWF. TAC makes resource recommendations to Budget Committee
- TAC Composition
  - TAC voting members
    - One rep from each Premier member
    - One rep appointed by TSC of each project at the Adopted stage
    - Up to 3 annually TAC appointed industry reps
  - See section 8b of ASWF Charter for more info about composition
  - You can change your representative at any time by making a request at members.aswf.io
  - Projects can rely on these people when they need something from ASWF. Also should help evangelize within your company such as Dev Days.
- How to propose an agenda item
  - Agenda for TAC meetings are managed at TAC project page
  - Propose a topic for a TAC meeting at TAC issue page
  - Please submit your proposed agenda item at least 7 days prior to the meeting
  - Please be patient. Tac meeting agendas are often quite full, and the length of the meeting only allows the time for two larger topics per meeting, so if your topic is more than a short topic it may not be scheduled for the next meeting
  - If we cannot accommodate your request in the upcoming meeting
    - Wait until the following meeting to discuss the topic
    - Call a special meeting to discuss your topic or
    - Refer the topic to the appropriate committee or task force of the TAC
  - We may ask you to provide slides 3 days ahead
- TAC Materials
  - Agendas for TAC meetings will be made available the day before the schedule meeting
  - Past meeting notes can be found at tac.aswf.io
- Project Lifecycle
  - TAC review all projects and WGs on annual cadence. Reviews are meant to gauge project progress, address issues, and asse lifecycle stages:
    - Sandbox
    - Incubating
    - Graduated (Adopted)
    - Archived
  - Vote to approve the annual review is require only if the TAC feels the project should move to a different lifecycle stage
- Working Groups
  - Foundation defines two types:
    - Long TErm (has a voting TAC representative - New)
    - Regular
  - Life cycles are simpler
- Discussion Channels
  - Mailing Lists:
    - TAC public: tac@lists.aswf.io
    - TAC private: tac-private@lists.aswf.io (only for sensitive topics)
    - Project and working group leads: technical-project-leads@lists.aswf.io
  - Slack
    - academysoftwarefdn.slack.com
    - TAC channel, make request at members.aswf.io
- Project Guidelines
  - What we have found as best practices for successful projects
- Governance & Contribution
  - Projects are unique, our structure allows for flexibility to accommodate different needs
  - However we have more in common than not, and all projects should strive to ensure common baselines. This ensures:
    - Projects maintain high quality and dependability that the ASWF strives to be known for
    - Ease of onboarding new contributors / projects
    - Smooth interop and collaboration between Foundation projects
- Governance
  - TSC is the leadership of the project. This committee’s primary role is to:
    - Projects should have a GOVERNANCE.md
    - Set overall direction of the project
    - Ensure project community has the needed resources and infrastructure to succeed
    - Resolve any issues with the project community
    - Provide project updates to the TAC and community at large
    - Participate in code review and feature discussions
    - Sometimes no substitute for “liv” meetings
  - The TSC made up primary of primary committers or maintainers. Can also consist of primary stakeholders and dedicated users.
  - TSC structure can vary, but projects should ensure that major contributors and stakeholders have equal opportunity to influence project direction
  - TSC does not have to equal its committer list, but it should be close - and usually, all committers would be expected to be voting TSC members
  - TSCs should audit their TSC members annually, “move to emeritus status”, vs who are the up and comers
    - Carol:Balance your TSC between important stakeholders who may not be active code committers, but can still be a voting TSC member. Keep TSC balanced between stakeholders, balanced opinions. A company may be contributing a large feature in a project, but not all those contributors need to be voting TSC members. What does the project need to be successful?
    - Larry: can be quire different between projects. Meetings are open, few things need a formal vote, most TSC meetings don’t need a vote, but once in a while you do. Best if TSC is not dominated by a single company, committer privs can differ from TSC voting seats. Some projects think they have constituencies that won’t be code committers, but still need to be voting TSC members. Up to TSC / project to decide what these roles are.
    - Larry: the one enshrined position is the chair, supposed to be elected, should ratify annually. That person wears a few hats: they come to TAC meetings, chair and run the TSC meetings, set the project direction. Also technical lead, but not a rule that these need to be the same person. Some projects (OCIO, OIIO) formally split the role into an architect and a chair. Can help split leadership role between multiple companies. OCIO had a large infusion of people from one company, wanted to make it clear that one company didn’t have all the votes.
    - Carol: look at add new people, help to make people better / stronger.
    - Larry: use this reminder to do your annual TSC audit, who needs to be rotated out (not attending meetings), who is doing the work and should become TSC members. Projects should do this periodically, at least annually.
    - Carol: also not “change for the sake of change”: TAC has more formal roles, we don’t expect project leadership to turn over frequently. But asking TSCs to play active role in health of the project.
    - Larry: a “do-ocracy” (from John): the currency of influence is people contributing time / effort / code / making the work happen, want project project leadership to correspond to people doing the work. Also if you are on a TSC, your role is not just to show up at the meetings, counting on TSC members to be helping to review PR backlog, commenting on issues, opinion on design questions, helping users asking for help.
- Contribution
  - Basic requirements
    - Adhere to the project’s IP policy as defined in their charter.
      - Signed Contributor License Agreement (company or individual)
      - Signed GitHub commits (DCO) with valid e-mail address
      - Ken: are CLAs / DSOs optional? Larry: they are decided based on the project policy. John: each project has a technical charter, including an IP policy. Defines what license you use, DCO is bare minimum across LF, plurality of ASWF projects have adopted CLA, but projects are not required to, each project controls its own IP policy. Generally most projects have for the comfort of downstream consumers.
    - Passing CI
      - We know CI can break, project maintainers can decide a broken CI isn’t related to a specific PR
    - Approved Review(s) (more on this next)
- Code Review
  - PRs should be review by at least one senior project developer, not including the original author (OpenSSF Best Practices badge requirement)
  - PRs should remain open for at least 48hrs (work days, and ideally more) to allow time for community feedback - even if it has received the requisite approvals
    - Make review meaningful, everyone is always in a rush to get work merged, but better to take a breath and get all input before merging. If you don’t have an imminent release coming, there isn’t an emergency. Of course lots of exceptions.
  - Original author should make changes requested by reviewers
  - Some projects can make other rules, such as having 2 reviewers, or reviewers from different companies.
  - There are exceptions
    - Time critical patches
    - Very minor changes / typo fixes
    - Lack of reviews
      - Best practice to give some time, post comment about intent to merge, never merge without a comment, state why you need to merge immediately, leaves a paper trail. People don’t want to just see a long history of everything getting merged without any evidence that it was looked over by someone else.
    - Failing CI tests
- Meeting Notes
  - All project meetings should be open to any and all attendees (rare exceptions OK)
  - Meetings should be published and accessible via LFX calendar
  - TSC meetings should have a regular, predictable cadence
  - Notes should be taken and posted to a public space for every TSC meeting
    - Options: manual note taking, transcription, recording, or combo
    - Suggestion: rotate note taking duties per meeting to decrease bias and encourage participation (OCIO used to do this)
    - Can be hard for the chair to take notes
    - Deke (chat) Can you enable the Zoom’s built in AI note taker? I use them for all my meetings these days. Carol (chat): yes we have that feature available now.
    - Larry: don’t just want 30 pages of transcript from AI
    - Carol: success varies, OCIO used to rotate note taking, fell off that, so now I take most notes. Doug and I share running the meeting, I may not be able to participate if I’m taking notes. Transcription helps, but it’s not the whole story. Don’t have to make meeting recordings public.
- Communication
  - Project maintainers are responsible for representing & communicating about the project. This includes:
    - Making roadmaps, feature planning, and release cadence open and accessible
    - Providing updates as needed to project Slack channels / mailing lists
    - Being responsive to issues and questions from the community
- TAC Resources
  - TAC website: tac.aswf.io
    - INcludes much more detailed process descriptions
  - ASWF Overview decks & charters
  - OpenImageIO’s Code Review Guidelines