Academy Software Foundation Technical Advisory Council (TAC) Meeting - October 16, 2024

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 - 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

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
Yarille Ortiz - The Linux Foundation
Andrew Grimberg - LF Release Engineering

Other Attendees

Ben Giles - Caligara
JT Nelson - Pasadena Open Source consortium / SoCal Blender group
Lee Kerley - Apple
Josh Bainbridge - Framestore
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
- Security Threat model analysis for ASWF projects #615
- OpenQMC #434
- Project Leads Office Hours #760
- upgrade GPUs of CI runners #863
- Update on Samsung Developer Conference #875
- OpenAPV - defining 6 month milestones #877
Dev Days Recap #873
Evolving our working groups program #798
OpenAPV #803

Meeting Notes

Security Threat model analysis for ASWF projects #615
- Want to fund two projects, working on budget process
Project Leads Office Hours #760
- Next week
- Working on release tags / harderning
- Looking at trying to shift date / time, but all other slots had issues of their own
upgrade GPUs of CI runners #863
- OpenVDB working with LF RelEng for access to A10G GPUs via AWS CodeBuild
- GHA may be offering newer GPUs Q1 2025
OpenAPV - defining 6 month milestones #877
- Who is taking lead? Eric R + Sam Richards. Sam has a document that spells out some of the requirements. I’ll double check with Sam before sharing out, we have talked about this document in previous meeting.
- Have been speaking with some of our video metrics folks to define what kinds of metrics make sense for things we care about in VFX and animation
Update on Samsung Developer Conference - David #875
- David presented at Samsung Dev Conference 10 days ago, in context of APV and ASWF
- Had a small but good crowd
- Keynote showed how much Samsung is committed to open source in a lot of what they do, in Android for their phones, Tizen for their TVs. Samsung uses open source to gather feedback and build their dev community. It’s not a side effort on commercial development, it’s where the work and the feedback on phone and TV is done. Was impressed by that, and wanted to communicate that to the TAC. I feel that Samsung joining as a Premier member is great, but it’s also good that they have a culture of open source. I also think their open source culture we may have things to learn from Samsung.
- JT (Chat) Keynote is available to watch
Dev Days Recap #873
- Slide Deck
- Carol: have had meetings to wrap up and gather feedback, presenting deck to consolidate feedback
- Goals for 2024 Dev Days
  - Increase the engineering contributions to our hosted projects
  - Help our hosted projects be better structured to be able to bring new contributors into their projects
- Dev Days by the Numbers
  - 7 projects participated (was 5)
  - 47 individuals participating
  - 56 total PRs opened to contribute back to the projects
    - 35 of these are merged as of 10/12/2024
    - 18 for MaterialX
    - 1 for ORI
    - 2 for OSL
    - 6 for OCIO
    - …
- 2023 vs 2024
  - Projects participating: 5 - 7
  - Individuals participating: ? - 47
    - Number of unique people who submitted a PR
    - Larry: projects had other people who participated but may not got to the point of submitting a PR
    - Project leads: please provide any additional stats on participation
  - PRs opened : 31 - 58
- Feedback from Projects Leads
  - Collated on Google Doc
- Key takeaways
  - Thumbs up:
    - More engineers participated, more PRs opened
    - We built more templates to reuse
    - We are creating a funnel
  - Could be better
    - Blind to the list: Dev Days management could not see list of participants due to privacy requirements
  - Overall
    - Dev Days will not single handedly resolve our engineering contribution goals, but it will participate in solving it
- Changes for the future
  - For sure
    - Have registrants agree (click a box) to share their Dev Days reg information with Dev Days management
  - In discussion
    - Dev Days moving to a quarterly basis
      - On a more regular cadence, helps with goals of project standards, having docs up to date, good first issues
      - Also helps participants, if they can’t participate, they don’t have to wait to the following year
      - Learn how to do your first contribution on a project
    - If annual event, move Dev Days to the spring
      - In case we get negative feedback about quarterly cadence
  - Larry: Organizers have had post mortem, and also from projects. But would like to hear back from leads at companies who had multiple people participating. Did you get what you expected to get out of the event?
    - Ben: I have an open PR myself on OpenImageIO, spent the days across Pacific and London time helping my team try to understand what this open source contribution thing is, not realizing that not everybody knew what it is. For us a way to show how to participate generally, which we want to do more of. Was spending my time explaining to engineers why would we even do this. Some devs hadn’t contributed to open source before. Feedback is very positive, they could understand why, but were not used to it. Yes yes please quarterly, especially OIIO had great example, a more experienced engineer was able to get at least one PR in. But for some of our juniors may have needed to explain what / why / how earlier. We will use Dev Days as a way to get people participating. Larry: you know nothing stops you any day of the year! But there’s “economy of scale” with these events. Ben: there was a list of issues which was great, with a very large issue broken down into subsections, made it easy to see what could be “bite sized chunks”, that was useful as well. Could be done in other projects.
    - Alexander S / Eric R (chat)
      - Alexander: alternatively extend devdays to two full weeks?
      - Eric: There was some feeling from our AL participants that a longer “Dev Days” might help with the time zone differences.
      - Larry: A longer span in which to embed your day, or projects that take multiple days to complete?
      - Eric: I think a longer span - though I’ll reach out for some clarification
      - Carol: Longer time frames might tend to be a large burden on the project… the level of support and response time we we expect from projects during dev days is higher than “normal”
      - Eric: That’d be my concern as well
      - Alexander: though doing devdays more often might be even more overhead with more context switching?
      - Carol: it’s a trade off for sure. But the theory would be that it would be less setup for the projects, more just being available for support… Eventually. Obviously we would have work to get there
    - John: some disconnect between issues / complexity / where engineers came in (from meeting). Some issues may have looked tractable at first but more complicated later.
    - John: “always prepping for dev days” may sound like a lot of work, but positions project to always be ready for new contributors, build this into the project processs. So makes an argument for quarterly.
    - Eric R: could we try a semi annual, or would that be too long? Larry: we could do a quarterly “welcome new contributors” that’s low key, pick one of those every year to do more publicity. Make sure that build docs are up to date, keep primed all the time. John: you also don’t have to participate, if an event falls during a major release cycle. Larry: lowers the temp on all participants if they feel that missing a day doesn’t mean having to wait a full year
  - John: what’s the general position of the TAC on annual vs quarterly? Or is there a preference
    - Ben: definitely quarterly. Also be able to deal with participants in other timezones. 48h on Pacific time (or any timezone) would be great, but maybe 72h? Next time I will prepare our team better.
    - Larry: we all wish we had done better!
    - Carol: also want to hear from company representatives, if Dev Days fall on a bad date for a company, will limit ability to participate. Conflicts with production projects, conferences, project releases… Can be different for companies to organize around quarterly, hoping that it’s positive on that side.
    - John: any objections on quarterly?
      - Eric R (Chat): I’ll reach out within our org and get a feel for where people are on the quarterly thing
      - Alexander S (chat: not sure about quarterly, do we have similar examples from other organizations?
    - John: will also try to streamline the process
    - Gordon: do we have a measure of what the setup cost is that we expect teams to repeat quarterly? Carol: we don’t have a measure, the hope is that the “startup cost” gets lower over time as we get used to doing it quarterly. A project should always be prepped for new contributors to come in and be well supported, but pick a few days a quarter for higher support / quicker PR review. Also maybe have themes.
    - Larry: nobody is to take all the work that we did annually and do the same amount quarterly. Would do lower overhead / smaller thing more frequently than the one high stakes thing that requires a lot of work. Should be same amount of work total but spread over time and less frantic criticality on a single day.
    - Larry: nothing would compel any project or company to do it every quarter.
    - JT (chat): Timeboxing Code Sprints These are two principles/guides the Pasadena/SCB group follows and has found successful. Also note the “Criticism” section below the Code sprints section
  - John: team will come back with quarterly plan, thank you Carol and Larry for making this possible, project leads also. Good to see charts with growing numbers!
Evolving our working groups program #798
- Initially WGs were supposed to be time limited
  - Assets and Review and Approval transitioned to projects
  - CI and D&I are ongoing
  - Interop in R&D mode
- 3 types of WGs
  - Time / deliverable limited
  - Starts developing IP to eventually become a project
  - Special Interest
- Larry: want to support WGs that have changed over time. But also feeling that TAC reporting, annual review, deliverables on schedule may be too high a threshold for a group that just wants a Zoom meeting and a chat room. We don’t want to feel like giving those resources should require a lot of work. Can use imagination as to where WGs could fit into.
- Larry: not a value judgement, a right sizing of threshold and resourcing. John: and setting expectations.
- Carol: might help to give a couple of examples. What groups would you imagine don’t have to do an annual review?
- Larry: CI WG is a project (in my mind), it’s been acting like a project, has repo, code, people are depending on it. Has no time horizon, no end deliverable. On the low end, people have talked about the Interop WG, maybe some day they will produce an artefact / code repo and need full structure, but for now it’s more like a SIG. D&I is a real working group, it’s not a project since it’s not producing group, but it’s not a SIG. It runs programs for the ASWF, represents us publicly… That’s a “real” WG without a time horizon.
- Carol: so we’re talking about changing our definitions for Working Groups. Larry: there’s room for WGs that are taking on an ongoing task that doesn’t have an end date.
- John: could be a 4th category we call a “program”. A lot of foundations do that for efforts they have invested in, they have called it a “program”.
- Michael M: sounds like considering expanding the WG definition, doesn’t seem mutually exclusive. Expand the definition and create SIGs. Larry: yes, reason for moving things into projects because of the legal structure put in place by LF, legal protection for projects producing artifacts. Feels like a different category. MM: AOUSD has WGs that are essentially Project Groups
- Gordon: drawing a line between the WGs and projects makes a lot of sense, can you help me understand difference between WG and a SIG? Maybe it doesn’t save us a lot, we may still want to review and approve these things, is the lack of an end date the only difference? John: what spurred this conversation is when a WG came to be, was supposed to deliver something and then shut down, but some WGs aren’t like that. So should it be looked at differently. Separate annual reviews as a secondary concept, we want to set expectations.
- JC (chat): Kubernetes SIG vs WG basically?)
- Gordon: could we solve this by just saying “it’s OK if you don’t end”. Larry: WGs and Projects are understood to have an annual review, they are giving a full TAC session to do a formal presentation to the TAC, report on what they’ve done. That limits the number of WGs we can have since we run out of TAC time. Sometimes there’s not a lot for the WG to say in that format about what they have accomplished, if what they are mostly about is providing a forum for interchange. Gordon: maybe separation would be “low overhead / little oversight”, just vote on? Larry: TAC could disband a group if not active anymore. Gordon: update doesn’t have to be full TAC session, could be 5 minutes. We could make it lighter weight. John: don’t think you want to add too much variance to the process. As a group evolves, could make sense to evolve between models. Emily: also think about what the scope is, and where a WG is in their life cycle. Love the idea of making D&I into a program, maybe they could even get a voting seat at the TAC. When I think about SIGs, I think about a sandbox. Lots of people have expressed interest in AI, we could spin up a SIG on that topic, which could turn into something bigger later on.
- John: a good way to think about it. Adoption metrics are one thing, would be good to get alignment on whether we want to bifurcate our definition our WGs. WG CI is clear candidate for moving over. USD could be argued fits in the SIG model, but there’s also some development and assets.
- JT (Chat): Hasn’t the TAC already talked about written/email reports and then TAC meeting time for questions as a time saving approach?
- John: how would the TAC deal with all these? Carol: not a fan of creating more things for the sake of creating more things, decide whether we need them. We can create processes once we decide to do something, but not clear why we are doing this. Gordon: take 4 heads, decide what are the differences, can we handle with simpler structures. There’s mental load on dealing with multiple structures, we don’t want to debate a program vs a WG.
- Eric R: see this as a way to authorize creating a channel in Slack (Stephen Mackenzie: spk). So that’s a way to create a place to collaborate which is in the “realm of stuff we all do”.