ASWF TAC Meeting - 28 June, 2023

Video Conference Link

Voting member attendance

Premier member representatives

Project representatives

Carol Payne - OpenColorIO
Cary Phillips - OpenEXR
Chris Kulla - Open Shading Language
Jonathan Stone - MaterialX Representative
Joshua Minor - OpenTimelineIO
Ken Museth - OpenVDB

Industry representatives

Jean-Francois Panisset - Visual Effects Society

Other Attendees

John Mertic, LF
Yarille Kilborn, LF
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Doug Walker, Autodesk
Lee Kerley, Sony Imageworks
Sergio Rojas, Different Dimensions
Stephen Mackenzie, NVIDIA
Nick Porcino, Pixar
Danny Greenstein, Sony Imageworks
Ian Smith, Studiobox
Max Ostrove, Studiobox
Deke Kincaid, Digital Domain
Mitch Prater, Laika

Apologies

Agenda

Close out changes on “what makes a good project” and lifecycle explanations - John Mertic - https://github.com/AcademySoftwareFoundation/tac/pull/417
COCOMO Project Analysis - John Mertic

Notes

Updates
- Kimball: Make sure to fill the Dev Days survey, Carol is taking the lead, Larry is co-chairing
- John: if you haven’t done it already, there’s a project maintainer survey that went out a couple of weeks ago and closes at the end of the month. Please fill it out! https://docs.google.com/forms/d/e/1FAIpQLSc7yGTsFQ1Cd_pBho9i1ARIkm52urR3OiLE1EkRbJcR7Z7qaA/viewform
- Kimball: I have a new job, have left Weta but still working for Weta, back at the studio as CTO. Someone else from Unity will show up as the TAC rep soon.
Close out changes on “what makes a good project” and lifecycle explanations - John Mertic - https://github.com/AcademySoftwareFoundation/tac/pull/417
- To set context: TAC had a good discussion several weeks ago on topic of “what makes a good project”. Takes a lot of different forms, one thread was to try to quantity it, added language to that effect. But a second thread on having the TAC have more clarity about the incoming project, the annual review, how to say no. Typically when foundations get going, they use a “case law” process, but as you mature, encounter new situations, TACs start trying to codify the process.
- A number of people have provided feedback, don’t want to look at the details of the PR / diff, but more what’s the end product:
  - https://deploy-preview-417–aswf-tac.netlify.app/process/start_project.html
  - https://deploy-preview-417–aswf-tac.netlify.app/process/lifecycle.html
- Work on “What makes a good project to host at ASWF”
  - 8 bullet points:
  - Does the project address address a common problem in the motion picture and VFX industries that is not solved by other projects
  - Will the project gain alignment and participation amongst multiple constituents
  - Is the project leadership best positioned and capable of growing the project
  - What resources would the project need to be successful?
  - Will this project divert away resources from existing projects?
  - What existing code is coming into the project
  - Does the project have the feature set, robustness and scalability necessary to solve the problem for film production, or is there a clear roadmap and team?
  - If a project does not meet the above criteria, the TAC can reject the proposal
  - Does this seem to capture what TAC members were thinking?
  - JF: good to have a checklist to structure discussion after a proposal
  - John: anything missing? Don’t want to get too deep in the weeds.
  - Larry: this isn’t really the “first try”, there’s been a lot of input!
  - Gordon: the bottom bullet point (feature set / team / roadmap), doesn’t that be implied by the first (does the project address a common problem)
  - Larry: I don’t think, it may be a two stage thing. The first bullet point says “this is a problem domain that’s interesting / there’s a gap” vs “this project / team is likely to solve it”. Gordon: lots of projects come in and say in theory we could be a solution to the problem. But there’s something around the doctrine, we are here to serve a set of studios and ecosystem funding it, so we need to deliver value back to the people funding ASWF. It’s tricky to have an adoption criteria for anything coming in since hard to get new things getting off the ground? John: we might want to change “alignment” to “adoption”?
  - Gordon: usage / adoption would trump validity. John: if people are using something in multiple studios… Larry: I agree that the word usage should be somewhere. We are trying to write the criteria that doesn’t reject a project like ORI that “doesn’t exist”, but still feels like a safe bet, since backed by several member studios who had built something like that project before, thus minimizing the risk. So it doesn’t have to be adopted yet if we feel it’s a safe bet. Gordon: would love something around that: “does the project have broad adoption today, or the TAC believes it could have broad adoption in the future”. We want to stay away from building multiple different solutions addressing the same problem. Eric: project presenters will feel that the project will be the right solution, in many cases it will be less clear. Cary: we’re not staying these are all hard requirements, more they are points to consider. Eric: but you want to see people who get “rejected” understand why. Gordon: what would be an example of a project we would want to invest in that’s not yet in broad adoption. Suggesting “Does the project have broad adoption across film production studios, software vendors and related organizations, or is there a clear path to that adoption?”
  - John: “If a project does not meet all the above criteria, the TAC can reject the proposal”. Larry: could eliminate the last line after the bullet points, since there’s already a line before.
  - Cary: there’s a vote process anyway. Is this list intended to apply both to projects and WGs? John: didn’t think about it in the WG perspective, but WGs tend to be more time / deliverable bound. Kimball: we have the WGs called out earlier.
  - JF: list of criteria for WGs should be more lenient. John: we have a separate entry for WGs. WG bring a group of people together on a topic, can be exploratory, and is time bound.
  - Gordon: some of these points may not apply to WGs, but they aren’t “bad”. Would be a good question to ask a WG of what IP they bring?
  - John: for instance would the D&I WG be able to answer these bullet points?
  - Eric: more “expertise” than “IP” for working groups so people don’t think they need to bring in their company lawyers
  - John: we may want to make it a separate exercise for WGs. But for the projects, any other changes we want before adding to PR? Eric: maybe the 9th point is redundant?
  - Gordon: have no reservations about overlap, I would suggest making it the second bullet, even if there’s potential for overlap.
  - Saved to PR, if we don’t hit more by next TAC meeting, we’ll commit it to the repo.
- Project Lifecycle
  - Wanted more clarity of what is expected of a sandbox project transitioning to incubation stage. There is language about a quarterly report as to project progress to TAC. Sometimes having a “tighter leash” can be helpful, but also don’t want to “paperwork people to death”. What would a quarterly report look like?
  - Eric: hesitation is that the regular projects are reporting once a year, so would take more TAC bandwidth.
  - John: doesn’t have to be an agenda item, could just be a PR / email.
  - Gordon: we could define reporting schedule at project adoption. Some projects may require different schedules.
  - John: could we do equivalent of an annual review closer than 6 months? Gordon: I wouldn’t say it has to have same coverage of an annual report, would be on a more ad hoc basis. Something is a “sandbox stage” for specific reasons, there is purpose on wanting an update. This seem tied to the fact that a sandbox stage project is there to answer questions. Want to know how far we are in answering the required questions before project can be graduated to incubation.
  - 3 criteria coming out of annual review:
    - Move the project to Incubation Stage
    - Renew Sandbox Stage for a year if it feels it can get to incubation stage by the next Annual Review
    - Move to Archive Stage
  - It’s expected that Sandbox stage is for a year
  - Larry: we shouldn’t be too strict about that, sounds like a short timeline. If you are in experimental phase, going to a real incubation phase, that can easily be more than a year. Gordon: maybe a statement “projects should demonstrate progress towards the next stage”. Eric: this may be quite different for different projects. When we bring something into Sandbox stage, we could also state how long we expect the project to be in Sandbox Stage. Gordon: we need to document why we adopted a project in Sandbox Stage, for how long, and what’s the requested reporting schedule. John: “expected to move or have demonstrable progress on moving to the Incubation Stage”.
  - John: in other foundations, Incubation Stage projects have things worked out well, but they may not yet be broadly used. But it can be different in different foundations.
- There is language about quarterly reports for Incubation Stage projects, we can discuss if that makes sense. Kimball: seems excessive. And we don’t have to wait for a year to have a Incubation Stage project move to Adopted Stage.
  - Gordon: since we’ve defined a similar structure between Sandbox and Incubation, is this duplication? Larry: some of the things in Incubation are foundational / widely used, completely different from Sandbox project. Gordon: so that’s the difference in the framework?
  - Eric: there’s a comment about Sandbox projects don’t have a press release, there’s a notion about “endorsement”
  - John: for sandbox, “it’s a good idea that people agree on, but not all the code / alignment / consensus”, it could change while in the sandbox. The other aspect is that we end up spending a lot of time getting the project structure / governance in place, but you don’t have to worry about a lot of these while in sandbox. Projects in Incubation are “ready to start accelerating”, ready to start getting a lot of users / growth. Larry: MaterialX / OSL / OTIO are still in Incubation stage, yet they are widely used, slowly working through some of the things on checklist, but the solidity of these projects is much higher than what we expect something in sandbox to be.
  - Matthew (Chat): If the expectation is that Sandbox projects move to Incubation stage within a year, getting updates more frequently than once a year seems important to track convergence. But maybe that timeline for Incubation can be loosened.
- Adopted Stage
  - After annual review, the TAC should officially state that “it’s good for another year”? Less of an issue for current projects, but could be useful in the future if you have a project that’s been stuck in Adopted stage. Larry: is that better adopted by having to vote on every project annually, or an “exceptional” process?
  - John: I’ve seen it done both ways. It’s up to the TAC to decide if it wants to have to say an explicit “Yes”? Gordon: I like the idea of having to explicitly vote, will make it OK to say no once in a while. Otherwise a project could end up “grandfathered”, most of the time will just be yes.
  - Gordon: maybe that vote should be at the next meeting? John: this TAC doesn’t always feel that they should vote right away, so that could be done that way. Could be just a practice the vote has. Kimball: it’s good to say we don’t have concerns. Eric: let’s do it and see how we like it. John: don’t need to document it explicitly for now. There are options in the current language.
  - Cary: we haven’t had the experience of a project entering a crisis, but it’s not far fetched for a “vital” project not to meet its goals. But the solution is not necessarily to “vote them out”. John: this is what I tend to see, you don’t want to cast a project out when it can be helped. Maybe there’s just things that need to be fixed. Cary: looking at the expectations statement, there’s some middle ground for an “intervention”.
- We will get this merged by the time of the next meeting.
COMOMO Project Analysis
- Financial impact and value of a project, took MaterialX as a value
- How many dollars of engineering effort are you leveraging, it’s not just free, you are leveraging a lot of effort that led to the project.