AWSF TAC Meeting - November 20, 2019

Voting member attendance

Other Attendees

Andrew Grimberg, Linux Foundation Release Engineering
Emily Olin, Linux Foundation
John Mertic, Linux Foundation
Jeff Bradley, DreamWorks
(Patrick Hodoul, Autodesk / OpenColorIO)
(Bernard Lefebvre, Autodesk / OpenColorIO)
Doug Walker, Autodesk / OpenColorIO
(Dan Bailey, ILM)

Apologies

Michael Dolan (Larry Gritz to represent OCIO)
Bill Ballew (Jeff Bradley to represent)
Gordon Bradley

Agenda

Goals for TAC: Year 2019
- Diversity & Inclusion (Wave, Emily)
  - Look within your organization to see if there’s someone that doesn’t look like you that could be your replacement or tag team member on the TAC. If that person is unavailable, ask them for referrals/suggestions.
  - Please take a look at this google doc and see if you have any personal contacts there (look at the board of advisors or leaders, also consider members). If so, please reach out individually and see if they have any suggestions/connections for us. Could be opportunities to present what ASWF is, what kinds of contributions folks could do (familiarize with our projects, pull requests, associate membership, etc.)
    - https://docs.google.com/spreadsheets/d/1XxH3hIsk1K3GDAZymF8emh8AWF3T_1bLf32_EXKSiE0/edit#gid=1665706912
- VFXPlatform 2020 / Python 3
- GPU support in CI (OCIO)
  - Proof of concept commitment
- Developer Engagement (Emily) - https://docs.google.com/presentation/d/1MMUNxJl6sbpMQmIDAfjZ52lUP08mA16JY6AZwYFtGdM/edit?usp=sharing
  - Putting together 2020 goals, increasing developer engagement and participation, cannot be developed in a silo. Should be led by the TAC, so need to present the slides so we can decide on priorities.
  - Seminars, meetups, developer days (hosted day of sessions, deep dives into projects, in cities with sizable developer community), use cases and case studies, written tutorials and technical blog posts
  - Wave: all looks good, for the ones that are presentations, would be good to have a consistent “one slide” on how to contribute to ASWF projects. Agreed upon messaging. Emily: good idea, have existing “how to contribute” at high level, but need more developer focussed. Wave: may have a mix of technical artists and developers, target towards skills of people who show up (C++, Python, …). Different opportunities for people to engage. Daniel: past discussions have highlighted opportunities for a broad engagement, as well as encouraging skilled developers who are already using our projects to contribute directly to our projects.
  - Daniel: asking projects where our focus should be, “best bang for the buck” to get best return on effort.
  - Wave: similar to “every project should have mission statement”, every project should also have a “how to engage with our project” explicit statement / document. Sean: do we want to make a distinction between internal developers in organizations who may not be able to commit to public repos vs external developers who have no such constraints? Wave: if you have code you have written that is locked up in our organization, having a “how to contribute” document helps to evangelize contributing back. Sean: should try to help non member organizations to contribute back. Larry: if people are having that issue in that organization, “bottom up” approach is unlikely to work. Top down may have better results, apply pressure at the executive level. More appropriate to the governing board.
  - Executive-level testimonials from existing organizations may be more convincing to outside organizations.
  - Larry: rather than outreach, “inreach” may be better, low hanging fruit are people already in organizations participating in projects / member organizations. Wave: simple, specific talking points to share within organization are helpful. Especially in large companies many potential contributors don’t know about ASWF, even when their company is a member.
  - Cary: generic, non-domain specific expertise can be quite useful. CMake for instance is not OpenEXR specific, but uses up a lot of time from OpenEXR contributors. Similarly for website, documentation. Not clear where to go for that expertise / contribution. Need more than just a “casual dalliance”, need specific commitment.
  - Emily: other LF projects have hired someone specifically to do documentation. Should raise this with governing board to hire contractor.
  - Daniel: expertise in non domain specific expertise could be found within our member companies. Wave: reaching out to a DevOps company as an associated member company could be interested. Emily: we could create a working group for some of those topics, provides a path for people to get involved in those activities.
  - Emily: providing a toolkit / format to internally advance and inform within their own organization. Is this something to do in person (“brown bag lunch sessions”?). Larry: people on the governing board, TAC, TSCs are senior in their organizations, as a group we need to go back to our organizations, identify junior developers and get them involved.
  - Daniel: hopefully that provides some points to work with.
  - Emily: priority should be to provide tools for internal evangelism, and provide talking points to demonstrate value of project involvement.
ASWF Annual Report (Emily)
- Project chairs - please take a look at the stats we would like to include for each project.
- Stats due by Nov. 29 if possible.
- Report outline: https://docs.google.com/document/d/1yHB0AggIHwD6P-fhyQh9B5dJ_9QwiuBpP0ESQiVcpA4/edit?usp=sharing”
- Look back at year so far, use CNCF as a template.
- Want to show impact of each project, number of contributors, key contributing companies, number of software releases. Will incorporate into infographics.
- Will also include mission statements.
Follow ups
- ASWF Org and Project permissions and workflows (Andy)
  - Responses sent as a private email thread
  - Should move thread to public list
    - Done: Thread
  - How we can deal with permissions and workflows across GitHub, DockerHub, Azure, SonarCloud…
  - How do we grant rights, who gets what kind of administrator rights, at what level
  - Andy: LF releng can hand over some administrative duties to some projects, but leery of doing it, historically have had issues with shared administration. Not to say LF releng won’t do it, as long as there is clear guidance on who has access to administrative rights, and what they are allowed to do.
  - How do projects get contributors up to have committer rights (approve PRs):
    - LF releng has developed automated method for adding / removing contributors, top level info.yml file in repo controls it. That change requires quorum of current contributors, once it is merged it gets shadowed into a releng repo, gets reviewed, then automatically updates the GitHub repo positions.
    - Or GitHub has a MAINTAINERS file, no quorum based voting, easier to get someone in a committer status, only current mechanism is gatekeeper for adding to the MAINTAINERS.
  - Discussion about how projects go about “protecting” merges. Andy: Recommendation to have “hard” rather than “soft” rules, easier to avoid bypassing rules, easier for maintainer to push back on bending the rules.
  - If a project wants to go with “soft” rules, LF releng won’t object, but that is not the recommendation.
  - On the Azure Pipelines side, have been experimenting with permissions, since billing goes through LF, permissions go through Azure Active Directory. So can invite people into the LF organization without having to have them be actual members of the organization, and grant them specific rights to do what they need to do. Permission model in Azure Pipelines/DevOps is extensive (huge!), so may require some experimentation.
  - Daniel: LF releng has experience across many projects / foundations, should find the model that has worked elsewhere and fits our requirements best.
- Survey for 2020 Goals (Emily, Gordon)
  - Draft: https://docs.google.com/forms/d/e/1FAIpQLSe5MBSTs4SZBABSMQiTu-G_WSnACKGpxVOhPXZgXQUNGnjCSg/viewform
  - Initially targeting board members, but feel it’s important for TAC and TSC members to also respond.
  - Based on feedback from TAC members, turned into a Google form.
  - Please provide feedback, don’t necessarily want to add too much
  - Would like to get this out ahead of next week’s board meeting
  - Daniel: thank you to Gordon for pushing this initiative forward.
- Thread library (Larry)
  - Good example of cross project leveraging, what the ASWF can provide as a forum to enable conversations around industry needs.
  - Daniel: 3 good examples: dependency management / CMake, thread library, OpenEXR math library
  - Larry: should be sending summary, plan is to keep the conversation going. Won’t be a “one size fits all” solution, but will try to “tame the chaos”.
  - Daniel: was at SIGGRAPH Asia with people from USD and SideFX team, one of the main topics was abstraction used by USD / SideFX to address threading. Larry: any collateral available? Daniel: they promised that slides should be shared, will follow up.
  - Sean: reached out to TBB architect, he’s signing up to TAC mailing list, will respond there (Alexei Kukanov).
Technical Project updates
- OpenVDB
- OpenColorIO
- OpenEXR
  - Repo naming conventions / requirements (lowercase only?)
  - Cary: upper case vs lower case? Hoping to move OpenEXR repo into ASWF GitHub organization this afternoon, we had a preference for CamelCase, but hot a strong performance.
  - Is that restriction a sensible thing that makes sense going forward? Is this a time to clean up this legacy?
  - Andy: LF releng position is that CamelCase repo names causes problems with their tooling when cloning repos.
  - Larry: problem isn’t necessarily with the LF tooling, but Windows / Mac that has case preserving but not case sensitive filesystems (mostly on Windows, for repos that started on Linux).
  - Andy: creates a support burden when onboarding projects. Not to say LF releng won’t support CamelCase named projects.
  - Daniel: would it make sense to recognize that our projects already predominantly use CamelCase repo names, that if we decide to go to lowercase repo names we should do that across all our projects at the same time. So go with CamelCase with OpenEXR for now, but we can look at implications of moving all projects to lowercase going forward.
  - Andy: LF releng has run into issue where issues with specific repos generated a lot of support requests.
  - Cary: given broad use of OpenEXR, have steady stream of build related issues, testament to how widely it is used. So would like to remove that as an issue and go with lowercase.
  - Cary: it’s never been an issue because current repo name is lowercase.
  - Cary: this doesn’t apply to organization name? Andy: correct, since that doesn’t end up in your path.
  - What about multiple related repos, “openexr”, “images”, “viewers”. Those will all exist as a flat repo hierarchy under AcademySoftwareFoundation. Larry: OpenColorIO will be like that as well. Cary: each repo needs infrastructure (license file, README, …). Some minimal amount of infrastructure that points back to the main repo.
- OpenCue
  - Update on OpenCue meetup last week at Sony Imageworks, was in context of LA pipeline developers Meetup group.
  - 2 people from Imageworks, 2 people from OpenCue.
  - Around 30-40 people attended, small enough to make it interactive, technical enough to be able to go in depth.
  - Recorded, should be publishing soon.
  - Will try to do more in the future, was quite successful.
  - LA Pipeline meetup would be open to other topic suggestions for future meetings.
  - Sean: is there value in having a suite of presentations “cued up” for our projects, for other events, conferences. Emily: yes, having a “Meetup” toolkit would be useful, have a “standard deck” per project. Relies on each project to put together such a deck. Daniel: there is such a deck for the ASWF and the TAC (presented most recently at SIGGRAPH Asia). Emily will send link. But should have more specific TSC-level decks for each project. Sean: we should take advantage of the high profile of some of our contributors to draw interest into our projects.
- OpenTimelineIO
  - Having regular tech-focused calls with Avid (informal working group)
    - Designated contact for AAF technical details, unlocked some blockers about that technology, had 8 people on call this morning.
  - Legal conversation around modified Apache is making some progress
    - Email thread, currently using modified Apache, Disney wants to keep that modification, project would like to move to unmodified.
    - Legal folks are finding a compromise that will hopefully get this unblocked.
  - Beginning to talk with TSC about mission statement for OTIO
CI updates
- Working group
Update on candidate projects
- Media Player?
Next meeting
- 4 December 2019

Action Items (AIs)

Notes

Chat