ASWF TAC Meeting - May 19, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, Linux Foundation Release Engineering
Rachel Rose, ILM, D&I WG
Rachel Romoff, Linux Foundation
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Patrick Hodoul, Autodesk / OCIO
Nick Porcino, Pixar
Ashley Whetter, Python 3 WG
Alex Meddick, Rising Sun Pictures
Michael Zink, WarnerMedia
Carol Payne, Netflix / D&I WG
Jeff Bradley, DreamWorks

Apologies

Joshua Minor (OpenTimelineIO)
Eric Enderton (NVIDIA)

Agenda

Project lifecycle feedback (John)
- Preview last week
- Larry put some comments on the PR, wanted to open back up for conversation
- Broken up into separate smaller PRs
  - Proposed working group changes
  - Project lifecycle update - proposal process, TAC review, annual review changes
  - Project lifecycle update - Add sandbox, adjust incubation
  - Project lifecycle update - Add sandbox, adjust incubation
  - Project lifecycle update - Archive stage
- Kimball: was having issues reading through the changelog format
- Bill Ballew: increases the level of the CII badge, seems like it’s already been a challenge for some of the projects.
- John: in other communities, they have increased the badge level, but not always easy to interpret the requirements.
- Larry: what are the additional requirements for the higher level of badge, and if they mostly don’t apply to our projects, we should differentiate that from higher levels that would be beneficial to our projects.
- Silver level CII criteria
  - Criteria for web site contributions
  - Legal infrastructure (we already use CLA)
  - Governance documented
  - Code of conduct (default one from ASWF)
  - Project oversight (OCIO has that in place)
  - Project roadmap
  - Documentation
    - Quickstart Guides
    - Security
    - Keeping up to date
    - Repository
  - Accessibility and I18N
    - These are “shoulds”, not sure if they are relevant
- So a lot of these requirements are typically already met with our projects
- Larry: a lot of these requirements seem valid / applicable
- Kimball: what’s the difference between Silver and Gold? John: many of the “shoulds” become “musts”. Copyright hygiene, version control hygiene. But also security reviews that may or may not be valuable, could be funded by the ASWF if we decide it is worth it.
- A lot is about how the software is delivered, one of the big pieces of last week’s Executive Order on cybersecurity is a software “bill of materials”.
- Kimball: are we at the point where we are ready to work with this. Bill: would this be retroactive applied? John: typically existing projects would be grand fathered into their current status, but would need to meet additional requirements to transition to a “higher” level. For instance OTIO in incubation stage would need to meet updated “graduated” level requirements to transition to that stage.
- Chris: can a project go for higher CII level than required by its ASWF status? Yes, of course.
- Michael Min: who is “checking the checkmarks” for these badges? What’s the periodic maintenance? John: it’s a voluntary / self certification project, up to the projects to self report. Are there paths to escalate a challenge to a project’s self reporting? Not sure. Larry: these aren’t just checkboxes, when you check “yes” on “do you have a INSTALL.md”, you also have to explain your work, including providing a URL. So still on the honor system, but most answers require explaining / giving URL.
- Cary: ideally would like to hear some guidance from above about the amount of effort that this requires and whether it’s worth it. OpenEXR asked itself “how seriously do we need to take this” (especially for security requirements). Would like guidance from the Board, which might in turn ask the TAC. How do we best allocate scarce resources, and is conforming to these higher level requirements “worth it”. Henry: yes, it has to be for a purpose, since it adds a burden. So we should have a clear rationale for doing this. Kimball: security requirements ended up driving adoption of Google OSS-Fuzz, which did increase the quality of the software. Cary: that decision was made by OpenEXR. Kimball: would this have been done if OpenEXR didn’t have to meet those requirements? Hard to tell. John: other communities will sometimes wrap themselves around these questions, these requirements came from a mixed bag of best practices / ways to ensure sustainability in projects. CII came from Heartbleed vulnerability in OpenSSL, it was found that it was such a crucial piece of project, 60-70% of Internet connected systems, but maintained by only 12 people (4 of the named Larry!). So if those people walked away / couldn’t get investment. Aligning these practices helps to show how excellent projects work and how external parties can gain trust in it. Could look at a third party / external resource for some parts such as security audit, recommendation. Could be raised to the board for funding.
- Kimball: maybe best to not have all the changes in a single commit. For instance the idea of a Sandbox stage could be its own commit. John: that’s a good idea. Larry: if we’re going to split those up, maybe there’s a project that’s interested and voluntarily try to achieve the higher level and report back how much effort it was / whether it was worth it. Kimball: yes, that’s a good idea.
- John: we’re currently at “passing” level as a requirement, so this would be increasing to Silver or Gold. Larry: OSL is still in incubation. John: one of the graduated / active stage projects would be a good candidate, they would be a good judge of how hard it would be to move to Silver / Gold. Kimball / Cary: will discuss this at the next OpenEXR TSC meeting tomorrow. John: David Wheeler is behind that CII badge system and could present to the TAC if required. John to work on splitting up the PR into separate components.
- Also have a similar proposal for Working Groups, that one is much simpler, it’s a much smaller document. Main change is having a structured review process for WGs, and having a charter in place before a WG starts up.
- Rachel: only challenge from WG is that first part of D&I WG was putting together the charter. John: initial activity of a WG is indeed to create the charter. Would be good to have that spelt out. D&I is an interesting example, feedback from board members is what does the longevity of a WG looks like, D&I could last longer, but being able to revise charter on annual basis is a good idea. Rachel: approaching 1 year mark, want to summarize what was done over the year and see if anything needs to be adjusted. So one year evaluation seems like a good time to look at whether current goals still make sense.
- Bill Ballew: are we putting a limit to 2 years, and everything above that would be something else than a WG? John: purposefully vague language, gives flexibility to the TAC as to what it wants to do, maybe we should say explicitly that the TAC could extend indefinitely. Larry: why a bias against long running WGs? Some activities won’t produce code (and are thus not “projects”). Wave: that could be a “committee” which is an ongoing thing, as opposed to a WG which is meant to address a specific issue / topic. Cory: USD WG is an example of an open ended commitment to help with USD adoption.
- John: recognition that ongoing WG would be exception rather than the rule, make sure there’s enough of a rigorous structure around WGs to make sure they mostly have a end point. So the TAC has the ability to support a bounded number of WGs. So the TAC can keep a WG longer if wants to, but that should be the exception rather than the rule.
- Cary: D&I doesn’t seem to quality as a “WG” in that context, more a “committee”. But the Asset WG would seem to fit that. Daniel: does it become a project? Wave: don’t know the answer, but people who have signed up to figure out what the asset repository will look like typically have not signed up to be the ones maintaining it.
- Daniel: so perhaps we need to have a different structure for long running activities.
- Kimball: it’s also about managing the focus, “we can only attend so many meetings”. Larry: 3 canonical examples are “Python 3” which will come to an end, the D&I which we want to do “indefinitely”, and something in the middle like the Rust WG which will likely transition into a project with specific software.
- Henry: At DNEG we differentiate between Steering Committees (ongoing) vs Working Groups (to resolve a question or make a recommendation to a SG). Tends to be more formalization around Steering Groups, a WG meant more to answer a question or make a recommendation back to a SG.
Open Source Days?
- Rachel: at last board meeting it was recommended to chat with DigiPro / The Pipeline Conference, that didn’t work out, but have an opportunity to do a talk at one of those.
- Going with Aug 4-5 for Open Source Days, week between Digipro and SIGGRAPH.
- 3-4h core day, with options for overflow, want to prioritize sessions with the projects. Looking for projects who want to participate.
- Talked with David Morin about 30m-1h, trying to keep it to a condensed day, so limited opportunity for extended talks.
- Kimball: if we try to trim things down too much, do we want Open Source days to be a replacement for BoFs at SIGGRAPH, or will projects need to also do a SIGGRAPH BoF if they don’t have the time to do community engagement. We need to decide this.
- Larry: Bofs used to be the one time when you could collaborate, but now we have TSCs / ASWF, so BoFs may be less important.
- Kimball: BoFs also give an opportunity for people who are lurkers to wander into a room, have a chat and wander out. Sean L: yes, has some outreach value.
- Carol: is the purpose of outreach of internal connection with people already familiar with the project.
- Rachel: is the question around 1h not enough time to do an open source day presentation? Kimball: what is the purpose of the Open Source Days, telling each other “what we already know”, or outreach? 30 min presentation is not necessarily enough, 1h BoFs seemed to be enough.
- Larry: BoFs not necessarily about presentations. Kimball: rarely had AV equipment at BoFs.
- Rachel: getting a sense from David Morin to have a place to showcase the ASWF and the projects, interesting things happening. Not clear if it’s “outreach vs internal communication”. We do want to attract people and have them learn about what we are working on. Position us as an attractive place to land relevant projects.
- John: ASWF has 2 events a year, Open Source Forum in the winter, focussed on speaking to an exec audience, and Open Source Days looking to speak to technical audience. Kimball: so more an outreach event. John: when we are back in person, have more opportunity to do both, but more challenging in an online setting.
- Kimball: We have dates, and will work on the schedule. Rachel: how did that work historically / what works best for us?
- Kimball: in the past we didn’t plan that much, each project got a timeslot.
- “Friends of the ASWF” projects are also in scope for this year.
Summer Learning program: Mentor edition (Carol, Rachel)
- Carol: summer learning program (mentorship) is coming up.
- Documents: https://drive.google.com/drive/folders/16WJoJfw2mBeR2LT_IGlsYGwcdkvdz0R7
- Posted on #general and #diversity Slack channels today
- Looking for mentors and reviewers: sign up sheet https://drive.google.com/drive/folders/16WJoJfw2mBeR2LT_IGlsYGwcdkvdz0R7
- When people think of mentors, people think of an intern to which you are trying to teach a specific skillset, like a “Google Summer of Code” Intern. This is more what “mentor” used to be: networking, career development, someone that you can ask general questions to. 3 months beginning of July. Requesting a minimum bi-weekly meeting with student, can be flexible if want to do more. Would love to fill as many slots for mentors and reviewers from the ASWF community before reaching out to external parties. Looking at 12 applicants, based on conservative numbers based on budgets and resources. Already have 60 applicants. ASWF would like to cross advertise and that hasn’t happened yet. Don’t want to bite off more than we can chew, but accept as many learners as we can. Can theoretically scale this at fairly minimum cost.
- Also looking for reviewers for applications, many of us have done peer review of papers already, so similar process. General questions such as rating student’s interest in getting into the industry, not requiring any baseline experience to get into the program.
- Larry: great to have all those applications, have you looked at enough of them to have an idea of how many of those are software related which we have expertise in vs “scattered through the production pipeline”. Carol: likely to be all over the place, and likely less on the technical side, since it was meant to get people excited about the industry in general. Feel that anyone in this room would be a great mentor.
- Rachel: will also provide a Slack channel to help build a community. Also providing online learning platform, likely Gnomon, so they can take the classes they are interested taking (centered around VFX / Animation, not necessarily just writing software). Have looked at a number of applications, and they are indeed “ all over the map”. If there is a good match between a specific applicant and a specific mentor, we will try to do those matchups. There will be at least 12 people, but looking to grow to 24 or at max 32.
- Carol: if you have questions about mentoring, or if you think you know someone who would be a good fit (should have call for volunteers at TSC meetings). Wave: is there a clear /approved “blurb” that can be shared? Rachel: the blurb is mostly the first paragraph, also the ASWF blog entry: ASWF Diversity and Inclusion Summer Learning Program - ASWF
- Other opportunities for mixing can happen on Slack as well, as well as 3 members of the D&I WG will be “team leads” to help in that Community space.
Project Updates
- What are the pending release plans?
- Should we schedule another VES tech / VFX platform group discussion for platform 2022?
- From Scott / Rust WG: We’re focusing on creating the Rust bindings for OpenEXR, and are making pretty good progress. If anyone wants to help out creating bindings, then we’ll gladly use the support. (Head to the #rust channel and we’ll help set up the dev environment.)