Prepare the 2.0.3 patch release (#1560 )

Signed-off-by: Patrick Hodoul <Patrick.Hodoul@autodesk.com>
Adsk Contrib - Fix RGB spline curve inversion when the slope is zero (#1539 ) (#1554 )
2021-12-14 12:10:33 -05:00 · 2021-12-12 09:11:47 -05:00 · 2021-12-10 15:37:15 -05:00 · 2021-11-03 16:30:56 -04:00 · 2021-11-03 07:53:49 -04:00 · 2021-09-16 08:46:02 -04:00
1853 changed files with 1940072 additions and 42261 deletions
@@ -0,0 +1,3 @@
+branches:
+  only:
+    - /^RB-1.*$/
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+
+# Control the end-of-line (i.e. eol) type for all the test files.
+
+# Most formats are text formats. Binary formats are excluded below.
+# Favor LF for all text files on all platforms.
+tests/data/files/* text eol=lf
+
+# Use CRLF for this file to validate clf parser also handles it.
+tests/data/files/matrix_windows.clf text eol=crlf
+
+# A binary file with a clf extension that will fail to be parsed.
+tests/data/files/image_png.clf binary
+
+# Exclude binary formats.
+tests/data/files/*.icc binary
+tests/data/files/*.icm binary
+
+# Avoid Windows line breaks in shell scripts (bound to fail)
+*.sh text eol=lf
@@ -0,0 +1,202 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+# GitHub Actions workflow file
+# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
+
+name: Analysis
+
+on:
+  schedule:
+    # Nightly build
+    - cron: "0 0 * * *"
+
+jobs:
+  # ---------------------------------------------------------------------------
+  # Latest ext packages
+  # ---------------------------------------------------------------------------
+
+  linux_latest:
+    name: 'Linux CentOS 7 VFX CY${{ matrix.vfx-cy }} latest 
+      <${{ matrix.compiler-desc }} 
+       cxx=${{ matrix.cxx-standard }}, 
+       docs=${{ matrix.build-docs }}>'
+    # Don't run on OCIO forks
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
+    runs-on: ubuntu-latest
+    container:
+      # DockerHub: https://hub.docker.com/u/aswf
+      # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
+      image: aswf/ci-base:${{ matrix.vfx-cy }}
+    strategy:
+      matrix:
+        build: [1, 2, 3, 4, 5, 6]
+        include:
+          # -------------------------------------------------------------------
+          # GCC, VFX CY2020
+          # -------------------------------------------------------------------
+          # C++11, Python 3.7
+          - build: 1
+            build-docs: 'ON'
+            cxx-standard: 11
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2020
+          # C++14
+          - build: 2
+            build-docs: 'OFF'
+            cxx-standard: 14
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2020
+          # -------------------------------------------------------------------
+          # GCC, VFX CY2019
+          # -------------------------------------------------------------------
+          # Python 2.7
+          - build: 3
+            # Doc build requires Python 3
+            build-docs: 'OFF'
+            cxx-standard: 11
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2019
+          # -------------------------------------------------------------------
+          # Clang, VFX CY2020
+          # -------------------------------------------------------------------
+          # C++11, Python 3.7
+          - build: 4
+            build-docs: 'OFF'
+            cxx-standard: 11
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2020
+          # C++14
+          - build: 5
+            build-docs: 'OFF'
+            cxx-standard: 14
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2020
+          # -------------------------------------------------------------------
+          # Clang, VFX CY2019
+          # -------------------------------------------------------------------
+          # Python 2.7
+          - build: 6
+            # Doc build requires Python 3
+            build-docs: 'OFF'
+            cxx-standard: 11
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2019
+    env:
+      CXX: ${{ matrix.cxx-compiler }}
+      CC: ${{ matrix.cc-compiler }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install docs env
+        run: share/ci/scripts/linux/yum/install_docs_env.sh
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/linux/yum/install_tests_env.sh
+      - name: Install latest ext package versions
+        run: |
+          share/ci/scripts/linux/install_expat.sh latest
+          share/ci/scripts/linux/install_lcms2.sh latest
+          share/ci/scripts/linux/install_yaml-cpp.sh latest
+          share/ci/scripts/linux/install_pystring.sh latest
+          share/ci/scripts/linux/install_pybind11.sh latest
+          share/ci/scripts/linux/install_openexr.sh latest
+          share/ci/scripts/linux/install_oiio.sh latest
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=Release \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=NONE \
+                -DOCIO_WARNING_AS_ERROR=OFF \
+                -DPython_EXECUTABLE=$(which python)
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config Release \
+                -- -j$(nproc)
+        working-directory: _build
+      - name: Test
+        run: ctest -V
+        working-directory: _build
+
+  # ---------------------------------------------------------------------------
+  # SonarCloud static analysis
+  # ---------------------------------------------------------------------------
+
+  linux_sonarcloud:
+    name: 'Linux CentOS 7 VFX CY2020 SonarCloud <GCC 6.3.1>'
+    # Don't run on OCIO forks
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
+    runs-on: ubuntu-latest
+    container:
+      # DockerHub: https://hub.docker.com/u/aswf
+      # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
+      image: aswf/ci-ocio:2020
+    env:
+      CXX: g++
+      CC: gcc
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 50
+      - name: Install docs env
+        run: share/ci/scripts/linux/yum/install_docs_env.sh
+      - name: Install tests env
+        run: share/ci/scripts/linux/yum/install_tests_env.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=Release \
+                -DCMAKE_CXX_STANDARD=11 \
+                -DCMAKE_CXX_FLAGS="-g -O0 -fprofile-arcs -ftest-coverage" \
+                -DCMAKE_CXX_OUTPUT_EXTENSION_REPLACE=ON \
+                -DCMAKE_EXE_LINKER_FLAGS="-lgcov" \
+                -DOCIO_BUILD_DOCS=ON \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DPython_EXECUTABLE=$(which python)
+        working-directory: _build
+      - name: Build OCIO with build-wrapper
+        run: build-wrapper-linux-x86-64 --out-dir bw_output make clean all
+        working-directory: _build
+      - name: Test
+        run: ctest -V
+        working-directory: _build
+      - name: Generate code coverage report
+        run: share/ci/scripts/linux/run_gcov.sh
+      - name: Run sonar-scanner
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
+        run: sonar-scanner -X -Dsonar.login=$SONAR_TOKEN
@@ -0,0 +1,520 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+# GitHub Actions workflow file
+# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
+
+name: CI
+
+on:
+  push:
+    # Versioned branches and tags are ignored for OCIO <= 1.x.x
+    branches-ignore:
+      - RB-0.*
+      - RB-1.*
+      - gh-pages
+    tags-ignore:
+      - v0.*
+      - v1.*
+  pull_request:
+    branches-ignore:
+      - RB-0.*
+      - RB-1.*
+      - gh-pages
+    tags-ignore:
+      - v0.*
+      - v1.*
+
+jobs:
+  # Linux jobs run in Docker containers, so the latest OS version is OK. macOS 
+  # and Windows jobs need to be locked to specific virtual environment 
+  # versions to mitigate issues from OS updates, and will require maintenance 
+  # as OS versions are retired.
+  #
+  # GH Actions (Free plan) supports 20 concurrent jobs, with 5 concurrent macOS 
+  # jobs. This workflow tries to utilize (but not exceed) that budget to 
+  # promote timely CI.
+
+  # ---------------------------------------------------------------------------
+  # Linux
+  # ---------------------------------------------------------------------------
+
+  linux:
+    name: 'Linux CentOS 7 VFX CY${{ matrix.vfx-cy }} 
+      <${{ matrix.compiler-desc }} 
+       config=${{ matrix.build-type }}, 
+       shared=${{ matrix.build-shared }}, 
+       sse=${{ matrix.use-sse }}, 
+       cxx=${{ matrix.cxx-standard }}, 
+       docs=${{ matrix.build-docs }}>'
+    # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
+    runs-on: ubuntu-latest
+    container:
+      # DockerHub: https://hub.docker.com/u/aswf
+      # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
+      image: aswf/ci-ocio:${{ matrix.vfx-cy }}
+    strategy:
+      matrix:
+        build: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
+        include:
+          # -------------------------------------------------------------------
+          # VFX CY2021
+          # -------------------------------------------------------------------
+          - build: 12
+            build-type: Debug
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'OFF'
+            cxx-standard: 17
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 9
+            vfx-cy: 2021
+          - build: 11
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 17
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 9.3.1
+            vfx-cy: 2021
+          # -------------------------------------------------------------------
+          # GCC, VFX CY2020
+          # -------------------------------------------------------------------
+          # C++11, Python 3.7
+          - build: 10
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'ON'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2020
+          # Debug
+          - build: 9
+            build-type: Debug
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2020
+          # C++14
+          - build: 8
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 14
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2020
+          # Static, no SSE
+          - build: 7
+            build-type: Release
+            build-shared: 'OFF'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'OFF'
+            cxx-standard: 11
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2020
+          # -------------------------------------------------------------------
+          # GCC, VFX CY2019
+          # -------------------------------------------------------------------
+          # Python 2.7
+          - build: 6
+            build-type: Release
+            build-shared: 'ON'
+            # Doc build requires Python 3
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 6.3.1
+            vfx-cy: 2019
+          # -------------------------------------------------------------------
+          # Clang, VFX CY2020
+          # -------------------------------------------------------------------
+          # C++11, Python 3.7
+          - build: 5
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'ON'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2020
+          # Debug
+          - build: 4
+            build-type: Debug
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            build-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2020
+          # C++14
+          - build: 3
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 14
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2020
+          # Static, no SSE
+          - build: 2
+            build-type: Release
+            build-shared: 'OFF'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'OFF'
+            cxx-standard: 11
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2020
+          # -------------------------------------------------------------------
+          # Clang, VFX CY2019
+          # -------------------------------------------------------------------
+          # Python 2.7
+          - build: 1
+            build-type: Release
+            build-shared: 'ON'
+            # Doc build requires Python 3
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang 7
+            vfx-cy: 2019
+    env:
+      CXX: ${{ matrix.cxx-compiler }}
+      CC: ${{ matrix.cc-compiler }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install docs env
+        run: share/ci/scripts/linux/yum/install_docs_env.sh
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/linux/yum/install_tests_env.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
+                -DOCIO_BUILD_GPU_TESTS=${{ matrix.build-gpu }} \
+                -DOCIO_USE_HEADLESS=${{ matrix.use-headless }} \
+                -DOCIO_USE_SSE=${{ matrix.use-sse }} \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DPython_EXECUTABLE=$(which python)
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config ${{ matrix.build-type }} \
+                -- -j$(nproc)
+        working-directory: _build
+      - name: Test
+        run: ctest -V
+        working-directory: _build
+
+  # ---------------------------------------------------------------------------
+  # macOS
+  # ---------------------------------------------------------------------------
+
+  macos:
+    name: 'macOS 10.15 
+      <AppleClang 11.0 
+       config=${{ matrix.build-type }}, 
+       shared=${{ matrix.build-shared }}, 
+       sse=${{ matrix.use-sse }}, 
+       cxx=${{ matrix.cxx-standard }}, 
+       python=${{ matrix.python-version }}, 
+       docs=${{ matrix.build-docs }}>'
+    runs-on: macos-10.15
+    strategy:
+      matrix:
+        build: [1, 2, 3, 4, 5, 6]
+        include:
+          # C++17
+          - build: 6
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 17
+            python-version: 3.7
+          # Static, no SSE
+          # C++11, Python 3.7
+          - build: 5
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'ON'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            python-version: 3.7
+          # Debug
+          - build: 4
+            build-type: Debug
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            python-version: 3.7
+          # C++14
+          - build: 3
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 14
+            python-version: 3.7
+          # Static, no SSE
+          - build: 2
+            build-type: Release
+            build-shared: 'OFF'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'OFF'
+            cxx-standard: 11
+            python-version: 3.7
+          # Python 2.7
+          - build: 1
+            build-type: Release
+            build-shared: 'ON'
+            # Doc build requires Python 3
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            python-version: 2.7
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@v1
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install docs env
+        run: share/ci/scripts/macos/install_docs_env.sh
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/macos/install_tests_env.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
+                -DOCIO_BUILD_GPU_TESTS=${{ matrix.build-gpu }} \
+                -DOCIO_USE_HEADLESS=${{ matrix.use-headless }} \
+                -DOCIO_USE_SSE=${{ matrix.use-sse }} \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DPython_EXECUTABLE=$(which python)
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config ${{ matrix.build-type }} \
+                -- -j$(sysctl -n hw.ncpu)
+        working-directory: _build
+      - name: Test
+        run: ctest -V
+        working-directory: _build
+
+  # ---------------------------------------------------------------------------
+  # Windows
+  # ---------------------------------------------------------------------------
+  # TODO: Install pythonXX_d.lib (or work around it being needed) to support 
+  #       Debug build testing with Python bindings and docs enabled.
+
+  windows:
+    name: 'Windows 2019 
+      <MSVC 16.4 
+       config=${{ matrix.build-type }}, 
+       shared=${{ matrix.build-shared }}, 
+       sse=${{ matrix.use-sse }}, 
+       cxx=${{ matrix.cxx-standard }}, 
+       python=${{ matrix.python-version }}, 
+       docs=${{ matrix.build-docs }}>'
+    runs-on: windows-2019
+    strategy:
+      matrix:
+        build: [1, 2, 3, 4, 5, 6]
+        include:
+          # C++17
+          - build: 6
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 17
+            python-version: 3.7
+          # C++11, Python 3.7
+          - build: 5
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'ON'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            python-version: 3.7
+          # Debug
+          - build: 4
+            build-type: Debug
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            python-version: 3.7
+          # C++14
+          - build: 3
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 14
+            python-version: 3.7
+          # Static, no SSE
+          - build: 2
+            build-type: Release
+            build-shared: 'OFF'
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'OFF'
+            cxx-standard: 11
+            python-version: 3.7
+          # Python 2.7
+          - build: 1
+            build-type: Release
+            build-shared: 'ON'
+            # Doc build requires Python 3
+            build-docs: 'OFF'
+            build-gpu: 'OFF'
+            use-headless: 'OFF'
+            use-sse: 'ON'
+            cxx-standard: 11
+            python-version: 2.7
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@v1
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install docs env
+        run: share/ci/scripts/windows/install_docs_env.sh
+        shell: bash
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/windows/install_tests_env.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+        shell: bash
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DCMAKE_GENERATOR_PLATFORM=x64 \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
+                -DOCIO_BUILD_GPU_TESTS=${{ matrix.build-gpu }} \
+                -DOCIO_USE_HEADLESS=${{ matrix.use-headless }} \
+                -DOCIO_USE_SSE=${{ matrix.use-sse }} \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DPython_EXECUTABLE=$(which python)
+        shell: bash
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config ${{ matrix.build-type }}
+        shell: bash
+        working-directory: _build
+      - name: Test
+        run: ctest -V
+        shell: bash
+        working-directory: _build
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+# GitHub Actions workflow file
+# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
+
+name: GPU
+
+on:
+  push:
+    # Versioned branches and tags are ignored for OCIO <= 1.x.x
+    branches-ignore:
+      - RB-0.*
+      - RB-1.*
+      - gh-pages
+    tags-ignore:
+      - v0.*
+      - v1.*
+
+jobs:
+  # ---------------------------------------------------------------------------
+  # Linux GPU (AWS CodeBuild)
+  # ---------------------------------------------------------------------------
+
+  linux_gpu:
+    name: 'Linux CentOS 7 VFX CY2020 GPU <GCC 6.3.1>'
+    # Don't run on OCIO forks
+    if: github.event.push.repository.full_name == 'AcademySoftwareFoundation/OpenColorIO'
+    # GH-hosted VM. The build runs in CentOS 7 'container' hard-coded in 
+    # AWS CodeBuild project.
+    # TODO: Add support for dynamic GH Action defined CodeBuild 
+    #       container choice.
+    runs-on: ubuntu-latest
+    steps:
+      - name: Configure AWS Credentials
+        uses: aws-actions/configure-aws-credentials@v1
+        with:
+          aws-access-key-id: ${{ secrets.CODEBUILD_ID }}
+          aws-secret-access-key: ${{ secrets.CODEBUILD_SECRET }}
+          aws-region: us-west-2
+      - name: Run CodeBuild
+        uses: aws-actions/aws-codebuild-run-project@v1.0.0
+        with:
+          project-name: OpenColorIO
+          buildspec-override: buildspec.yml
@@ -1,5 +1,13 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+
 .DS_Store
 attic
 build*
+_build*
+_install*
 dist*
-mastercopy
+mastercopy
+*.pyc
+!*.yml
+.vscode
@@ -0,0 +1,61 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Corporate Contributor License Agreement ("Agreement")
+
+Thank you for your interest in the OpenColorIO Project a Series of LF
+Projects, LLC (hereinafter "Project"). In order to clarify the
+intellectual property licenses granted with Contributions from any
+corporate entity to the Project, LF Projects, LLC ("LF Projects") is
+required to have a Corporate Contributor License Agreement (CCLA) on
+file that has been signed by each contributing corporation.
+
+Each contributing corporation ("You") must accept and agree that, for
+any Contribution (as defined below), You and all other individuals and
+entities that control You, are controlled by You, or are under common
+control with You, are bound by the licenses granted and
+representations made as though all such individuals and entities are a
+single contributor. For the purposes of this definition, "control"
+means (i) the power, direct or indirect, to cause the direction or
+management of such entity, whether by contract or otherwise, or (ii)
+ownership of fifty percent (50%) or more of the outstanding shares, or
+(iii) beneficial ownership of such entity.
+
+"Contribution" means any code, documentation or other original work of
+authorship that is submitted to LF Projects for inclusion in the
+Project by Your employee or by any individual or entity that controls
+You, or is under common control with You or is controlled by You and
+authorized to make the submission on Your behalf.
+
+You accept and agree that all of Your present and future Contributions
+to the Project shall be:
+
+Submitted under a Developer's Certificate of Origin v. 1.1 (DCO); and
+Licensed under the BSD-3-Clause License.
+
+You agree that You shall be bound by the terms of the BSD-3-Clause License
+for all contributions made by You and Your employees. Your designated
+employees are those listed by Your CLA Manager(s) on the system of record
+for the Project. You agree to identify Your initial CLA Manager below and
+thereafter maintain current CLA Manager records in the Project’s system of record.
+
+
+Initial CLA Manager (Name and Email): ______________________________________
+
+
+Corporate Signature:
+
+
+Company Name: ____________________________________________
+
+
+Signature: _______________________________________________
+
+
+Name: _______________________________________________
+
+
+Title _______________________________________________
+
+
+Date: _______________________________________________
@@ -0,0 +1,38 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Individual Contributor License Agreement ("Agreement")
+
+Thank you for your interest in the OpenColorIO Project a Series of LF
+Projects, LLC (hereinafter "Project"). In order to clarify the
+intellectual property licenses granted with Contributions from any
+corporate entity to the Project, LF Projects, LLC ("LF Projects") is
+required to have an Individual Contributor License Agreement (ICLA) on
+file that has been signed by each contributing individual. (For legal
+entities, please use the Corporate Contributor License Agreement
+(CCLA).)
+
+Each contributing individual ("You") must accept and agree that, for
+any Contribution (as defined below), You are bound by the licenses
+granted and representations made herein.
+
+"Contribution" means any code, documentation or other original work of
+authorship that is submitted to LF Projects for inclusion in the
+Project by You or by another person authorized to make the submission
+on Your behalf.
+
+You accept and agree that all of Your present and future Contributions
+to the Project shall be:
+
+Submitted under a Developer's Certificate of Origin v. 1.1 (DCO); and
+Licensed under the BSD-3-Clause License.
+
+
+
+Signature: __________________________________________
+
+
+Name: _______________________________________________
+
+
+Date: _______________________________________________
@@ -0,0 +1,65 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+# Technical Charter (the &quot;Charter&quot;) for OpenColorIO a Series of LF Projects, LLC
+
+**Adopted \_\_\_\_\_\_\_\_\_\_\_**
+
+This charter (the &quot;Charter&quot;) sets forth the responsibilities and procedures for technical contribution to, and oversight of, the OpenColorIO project, which has been established as OpenColorIO a Series of LF Projects, LLC (the &quot;Project&quot;).  LF Projects, LLC (&quot;LF Projects&quot;) is a Delaware series limited liability company. All Contributors to the Project must comply with the terms of this Charter.
+
+1. Mission and Scope of the Project
+  * **a.** The mission of the Project is to develop an open source project with the goals indicated in the &quot;README&quot; file within the Project&#39;s code repository.
+  * **b.** The scope of the Project includes software development under an OSI-approved open source license supporting the mission, including documentation, testing, integration and the creation of other artifacts that aid the development, deployment, operation or adoption of the open source software project.
+2. Technical Steering Committee
+  * **a.** The Technical Steering Committee (the &quot;TSC&quot;) will be responsible for all technical oversight of the open source Project.
+  * **b.** The TSC voting members are initially the Project&#39;s Committers. At the inception of the project, the Committers of the Project will be as set forth within the &quot;GOVERNANCE&quot; file within the Project&#39;s code repository. The TSC may choose an alternative approach for determining the voting members of the TSC, and any such alternative approach will be documented in the GOVERNANCE file.  Any meetings of the Technical Steering Committee are intended to be open to the public, and can be conducted electronically, via teleconference, or in person.
+  * **c.** TSC projects generally will involve Contributors and Committers. The TSC may adopt or modify roles so long as the roles are documented in the GOVERNANCE file. Unless otherwise documented:
+    * **i.** Contributors include anyone in the technical community that contributes code, documentation, or other technical artifacts to the Project;
+    * **ii.** Committers are Contributors who have earned the ability to modify (&quot;commit&quot;) source code, documentation or other technical artifacts in a project&#39;s repository; and
+    * **iii.** A Contributor may become a Committer by a majority approval of the existing Committers. A Committer may be removed by a majority approval of the other existing Committers.
+  * **d.** Participation in the Project through becoming a Contributor and Committer is open to anyone so long as they abide by the terms of this Charter.
+  * **e.** The TSC may (1) establish work flow procedures for the submission, approval, and closure/archiving of projects, (2) set requirements for the promotion of Contributors to Committer status, as applicable, and (3) amend, adjust, refine and/or eliminate the roles of Contributors, and Committers, and create new roles, and publicly document any TSC roles, as it sees fit.
+  * **f.** The TSC may elect a TSC Chair, who will preside over meetings of the TSC and will serve until their resignation or replacement by the TSC. The TSC Chair, or any other TSC member so designated by the TSC, will serve as the primary communication contact between the Project and the Technical Advisory Council of the Academy Software Foundation of The Linux Foundation.
+  * **g.** Responsibilities: The TSC will be responsible for all aspects of oversight relating to the Project, which may include:
+    * **i.** coordinating the technical direction of the Project;
+    * **ii.** approving project or system proposals (including, but not limited to, incubation, deprecation, and changes to a sub-project&#39;s scope);
+    * **iii.** rganizing sub-projects and removing projects;
+    * **ii.** creating sub-committees or working groups to focus on cross-project technical issues and requirements;
+    * **v.** appointing representatives to work with other open source or open standards communities;
+    * **vi.** establishing community norms, workflows, issuing releases, and security issue reporting policies;
+    * **vii.** approving and implementing policies and processes for contributing (to be published in the CONTRIBUTING file) and coordinating with the Series Manager to resolve matters or concerns that may arise as set forth in Section 7 of this Charter;
+    * **viii.** discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and
+    * **ix.** coordinating any marketing, events, or communications regarding the Project with the LF Projects Manager or their designee.
+3. TSC Voting
+  * **a.** While the Project aims to operate as a consensus based community, if any TSC decision requires a vote to move the Project forward, the voting members of the TSC will vote on a one vote per voting member basis.
+  * **b.** Quorum for TSC meetings requires at least two-thirds of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met, but will be prevented from making any decisions at the meeting.
+  * **c.** Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require a majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting require a majority vote of all voting members of the TSC.
+  * **d.** In the event a vote cannot be resolved by the TSC, any voting member of the TSC may refer the matter to the Series Manager for assistance in reaching a resolution.
+4. Compliance with Policies
+  * **a.** This Charter is subject to the Series Agreement for the Project and the Operating Agreement of LF Projects. Contributors will comply with the policies of LF Projects as may be adopted and amended by LF Projects, including, without limitation the policies listed at https://lfprojects.org/policies/.
+  * **b.** The TSC may adopt a code of conduct (&quot;CoC&quot;) for the Project, which is subject to approval by the Series Manager.  Contributors to the Project will comply with the CoC or, in the event that a Project-specific CoC has not been approved, the LF Projects Code of Conduct listed at https://lfprojects.org/policies/.
+  * **c.** When amending or adopting any policy applicable to the Project, LF Projects will publish such policy, as to be amended or adopted, on its web site at least 30 days prior to such policy taking effect; provided, however, that in the case of any amendment of the Trademark Policy or Terms of Use of LF Projects, any such amendment is effective upon publication on LF Project&#39;s web site.
+  * **d.** All participants must allow open participation from any individual or organization meeting the requirements for contributing under this Charter and any policies adopted for all participants by the TSC, regardless of competitive interests. Put another way, the Project community must not seek to exclude any participant based on any criteria, requirement, or reason other than those that are reasonable and applied on a non-discriminatory basis to all participants in the Project community.
+  * **e.** The Project will operate in a transparent, open, collaborative, and ethical manner at all times. The output of all Project discussions, proposals, timelines, decisions, and status should be made open and easily visible to all. Any potential violations of this requirement should be reported immediately to the LF Projects Manager.
+5. Community Assets
+  * **a.** LF Projects shall hold title to all trade or service marks used by the Project (&quot;Project Trademarks&quot;), whether based on common law or registered rights.  Project Trademarks shall be transferred and assigned to LF Projects to hold on behalf of the Project. Any use of any Project Trademarks by participants in the Project shall be in accordance with the license from LF Projects and inure to the benefit of LF Projects.
+  * **b.** The Project shall, as permitted and in accordance with such license from LF Projects, develop and own all Project GitHub and social media accounts, and domain name registrations created by the Project community.
+  * **c.** Under no circumstances shall LF Projects be expected or required to undertake any action on behalf of the Project that is inconsistent with the tax-exempt status or purpose, as applicable, of LFP, Inc. or LF Projects, LLC.
+6. General Rules and Operations.
+  * **a.** The Project will:
+    * **i.** engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of LF Projects, LFP, Inc. and other partner organizations in the open source software community; and
+    * **ii.** respect the rights of all trademark owners, including any branding and trademark usage guidelines.
+7. Intellectual Property Policy
+  * **a.** Participants acknowledge that the copyright in all new contributions shall be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the Project.
+  * **b.** Except as described in Section 7.c., all code contributions to the Project are subject to the following:
+    * **i.** All new inbound code contributions to the Project must be made using the **BSD 3-Clause License (available here: [https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE))** (the &quot;Project License&quot;).
+    * **ii.** All new inbound code contributions must:
+      1. be made pursuant to a duly executed Project Contribution License Agreement (the &quot;CLA&quot;), available on the Project&#39;s web site; and
+      2. be accompanied by a Developer Certificate of Origin ([http://developercertificate.org](http://developercertificate.org)) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license;
+    * **iii.** All outbound code will be made available under the Project License.
+    * **iv.** Documentation will be received and made available by the Project under the Creative Commons Attribution 4.0 International License (available at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/)).
+    * **V.** The Project may seek to integrate and contribute back to other open source projects (&quot;Upstream Projects&quot;). In such cases, the Project will conform to all license requirements of the Upstream Projects, including dependencies, leveraged by the Project.  Upstream Project code contributions not stored within the Project&#39;s main code repository shall comply with the contribution process and license terms for the applicable Upstream Project.
+  * **c.** If an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project or is otherwise required to achieve the Project&#39;s mission, the Governing Board of the Academy Software Foundation of The Linux Foundation (&quot;Governing Board&quot;) or the Governing Board&#39;s designated committee may approve the use of an alternative license for specific inbound or outbound contributions on an exception basis. Any exceptions must be approved by a vote of the Governing Board and must be limited in scope to what is required for such purpose. To request an exception, please describe the contribution, the alternative open source license(s), and the justification for using an alternative open source license for the Project.
+  * **d.** Contributed files should contain license information, such as SPDX short form identifiers, indicating the open source license or licenses pertaining to the file.
+8. Amendments
+  * **a.** This charter may be amended by a two-thirds vote of the entire TSC and is subject to approval by LF Projects.
@@ -0,0 +1,4 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+https://developercertificate.org/
@@ -0,0 +1,52 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+
+Feb. 4, 2019
+
+Host: John Mertic
+
+Secretary: Kevin Wheatley
+
+Attendees:
+  * Sean Cooper (_TSC_) - DNEG
+  * Michael Dolan (_TSC_) - Sony Pictures Imageworks
+  * Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * Thanh Ha - Academy Software Foundation / Linux Foundation
+  * Patrick Hodoul (_TSC_) - Autodesk
+  * Bernard Lefebvre - Autodesk
+  * John Mertic - Academy Software Foundation / Linux Foundation
+  * Carl Rand (_TSC_) - Foundry
+  * Doug Walker (_TSC_) - Autodesk 
+  * Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* Opening explanation of form and function of TSC by John Mertic.
+* Election of officials/Nominations for roles
+* Doug Walker, explained the prior discussion from the Slack #tsc channel
+  * Michael Dolan - Chairperson
+  * Doug Walker for Chief Architect
+* Additional nominations
+  * Sean Cooper - Chairperson
+* Discussion around the concept of Chair + Vice chair and the distinction of only the chair having voting rights on the TAC.
+* Larry Gritz suggested we may benefit from a singular chair as an efficiency point, rather than the potential of delays by trying to maintain something similar to the current consensus model.
+* John Mertic requested candidates provide their background for inclusion in the voting process with the aim of opening voting on the 5th February.
+* Secretary - in view of no volunteers, suggested we might consider rotating role.
+* Infrastructure
+  * GitHub repo needs migrating to the ASWF organisation
+  * **TODO** - John Mertic to coordinate with Steve Winslow at the LF to complete.
+  * https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md
+* Require that any existing copyright notices are reviewed and amended by the current stated owners if their respective legal agrees.
+  * Once migrated will enable DCO sign off checking and CLA checks.
+* Sub-discussion on the option of separate sign off for committer vs developer sign off.
+* **TODO** - John Mertic to determine if sign off lines need to be in the contribution license agreement list
+* CLAs from corporations and individuals would preferentially be in place prior to migration, John Mertic to action the set-up.
+* Need to transfer DNS and website registration 
+* **TODO** - Larry Gritz to action transfer
+* Discussion around transfer of mailing lists/slack channel
+* **TODO** - John Mertic to confirm if Google Groups and message history can be migrated to groups.io, and pricing/options for Slack to Rocket.chat or Mattermost migration
+* Build infrastructure
+  * Note about the use of current infrastructure for builds in parallel until we have parity of features with the build system.
+* TSC meeting suggested weekly during initial roll out until we have settled down.
+  * Settling on Monday 5pm GMT-0 for now
@@ -0,0 +1,57 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Feb 11, 2019
+
+Host: John Mertic
+
+Rotating Secretary: Larry Gritz
+
+Attendees:
+  * Sean Cooper (_TSC_) - DNEG
+  * Michael Dolan (_TSC_) - Sony Pictures Imageworks
+  * Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * Thanh Ha - Academy Software Foundation / Linux Foundation
+  * Patrick Hodoul (_TSC_) - Autodesk
+  * John Mertic - Academy Software Foundation / Linux Foundation
+  * Carl Rand (_TSC_) - Foundry
+  * Doug Walker (_TSC_) - Autodesk
+  * Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* Election Results
+    * Chair:  Michael Dolan, by offline vote over the last week.
+    * Chief architect: Doug Walker, confirmed by unanimous voice vote.
+* Infrastructure updates:
+    * Domain transfer: LG reports he has identified the office at Sony Pictures that holds domains and working on the logistics of the transfer.
+    * Repo transfer: Should be straightforward to transfer from GitHub imageworks to AcademySoftwareFoundation accounts. (Note: also must transfer ocio-config repo.)
+    * Code scan:
+        * Competed initial code scan to check for licenses, etc.
+        * Overall pretty good
+        * "ext/" directory containing upstream dependencies should perhaps be pulled in at build time rather than embedded? But there were reasons (convenience, lcms no longer maintained, patches for custom namespacing for us). We could download at build time and apply the patches, so still build just for us, but not have those packages' source embedded in our repo.
+        * **TODO**: Patrick & Thanh to look offline at the initial CI builds and consider the ext packages to assess what can be pulled, what can be upstreamed, what must be embedded.
+    * Communication tools:
+        * If we want to move mail list communications to aswf.io, there is a migration path from google groups -> ASWF.io mail lists that will preserve the archives.
+        * Nobody objected to moving to aswf.io, so JM to work on this.
+        * JM can provision a dedicated Zoom line for meetings, if we want.
+    * CLA system
+        * New CLA system should be operational on Friday.
+        * At that point, JM will send us links to get new CLAs signed.
+        * **TODO**: JM to look into how to do retroactive DCOs. Investigate how necessary that is, considering we have CLAs from all prior contributors.
+
+* Releases:
+    * Do a patch against 1.1 that fixes a few minor things?
+        * Consensus is that we should make 1.1.1 with some important non-breaking patches and release that fix right away.
+        * **TODO**: Patrick will send Slack the list of candidate commits for a 1.1.1.
+    * Do we make an intermediate release from master before v2.0? People want a "developer preview" to be able to use the new GPU path.
+        * Patrick reluctant to make a full release.
+        * Proposal: just make a "developer preview" tag in master to designate a point we think is stable and has some helpful new features, but we don't promise any support or compatibility with the eventual v2.
+            * Down side: people will use it and expect us to support it.
+            * No consensus that this is a good idea. Mark especially doesn't like unsupported dev preview tag.
+            * But v2 will NOT be ready by SIGGRAPH 2019. In light of this, Mark thinks maybe we should have a real intermediate release.
+            * Sean: Considering how long it takes us to review things and the long v2 schedule, maybe we should reconsider what is v2 and what gets pushed to v3? (Patrick points out: it's the same ADSK people supporting the release as building "v2", only so much bandwidth available, so an intermediate release will make the full release take even longer.
+        * **Tabled** for further thought and discussion. Patrick made a GH issue for further discussion: #665
+
+* Agenda for next time:
+    * Talk about Python
@@ -0,0 +1,62 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Feb 25, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Thanh Ha - Academy Software Foundation / Linux Foundation
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* CI
+    - Thinking is that because ASWF already has Linux CI support, we could start using it.
+    - The ASWF solution is Jenkins at the moment, but due to the young age of the project, no-one is really using it yet.
+    - Circle CI has been proposed as a potential candidate as well.
+    - There is a proof of concept of OCIO on the travis CI, though it is only a simple CMake build (no tests).
+    - Additionally it would be good to get away from Travis CI as its future seems uncertain.
+    - Potentially wait for results of ASWF TAC discussion on future CI decision before actioning any changes.
+    - Thoughts are that migration of repo to ASWF is more important. We can keep our existing CI, and just move the repo.
+        - **TODO**: Might need someone from Sony to do the ASWF move.
+        - There will be a day or so crossover to set up the existing CI on the new ASWF setup.
+        - Decided to move to ASWF first, then sort CI later.
+    - **TODO**: Candidate for championing CI? Mark Boorer and Sean Cooper.
+
+* Embedded libraries
+    - Decision to remove all embedded dependencies at the same time as CI update.
+    - Concerns over Windows developer experience (as building of dependencies would now be required prior to building OCIO.
+    - Potentially solvable via vcpkg or Chocolatey.
+    - Patrick made a GH issue for further discussion: #690
+
+* 1.1 patch release
+    - Updates to OCIO to allow optional OIIO 2.0 compatability (which requires C++11)
+    - **TODO**: Larry / Michael will look into removal of auto keyword from OIIO headers.
+
+* Feature preview tag / Early 2.0 release
+    - Proponents want to the benefits of the improved GPU features for internal use.
+    - Fear is that it will achieve semi-release status and start being used in other DCC's where inconsistencies might arise, leading to all the same effort as an actual release.
+    - Suggestion for a limited release of some 2.0 features (3d lut inversion, gpu improvements).
+    - Autodesk have two main reasons to oppose both a tag or early release:
+        1. They don't feel the current state of the features represent a good, stable product to support.
+        2. As the primary integrators of Autodesk's DCC's are also the developers working on 2.0, the developers times would be split between adding the new integrations, and completing 2.0.
+    - Discussion tabled for next week.
+    - Further discussion, and status of continued TSC discussion in GH issue #665
+
+* Items for next TSC meeting agenda:
+    - Discuss ASWF TAC proposal of future CI direction
+    - Consensus on feature preview tag / early 2.0 release discussion
+    - Other tabled items (due to time)
+        - Python binding update (pybind11 proposed by Sony)
+        - Apple deprecation of OpenGL. Explore Metal or another alternative?
@@ -0,0 +1,96 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Mar 4, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Thanh Ha - Academy Software Foundation / Linux Foundation
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* Feature preview tag / Early 2.0 release
+    - Decision to NOT do either a preview tag or early 2.0 release
+        - Doug: As established in the initial 2.0 proposal, this is not feasible.
+        - The plan remains to release a complete feature set when the full v2 roadmap is completed.
+    - Community concern is that the v2 release schedule is unknown, and time between OCIO releases is long.
+        - This can make planning for software vendors challenging, but preliminary implementation of the v2 interface is possible now from master for testing.
+        - Autodesk discussing an official roadmap and insight on a potential release window. Stay tuned.
+        - Long PR review cycles contribute to development slowdowns:
+            - Most PRs are merged with the 2 week single reviewer clause.
+            - Larry: If current merge policies are a roadblock to AD, can they be revised?
+                - Proposed rotating review duty for a TSC member to do initial PR reviews as they are submitted for their assigned week
+            - This needs to be improved if it's blocking.
+            - Doug: Feature interdependency part of the challenge:
+                - PRs are becoming smaller, more focused, which should help with review accessability
+            - **TODO**: Doug/Patrick to review and report back on what project management changes could help them
+    - Larry: Should we have a known commit for testing a given feature (i.e. GPU renderer) for internal testing purposes.
+        - Doug: Testing off of master at any given time is stable, and ideal.
+
+* ASWF/LF CI update from TAC meeting
+    - Thanh presented comparison of Circle CI and current Jenkins infrastructure:
+        - Overall, TAC impression is that Circle seems like a better choice, but pricing and logistics needs further investigation.
+        - Circle supports local CI, allowing contributors to test CI *before* submitting a PR.
+        - Supports GPUs when hosted on our servers, but pricing may be a concern.
+        - Proposed AppVeyor for Windows support for now.
+    - OpenVDB reports that Circle significantly faster than Travis
+    - Larry: Circle has better, faster CPUs than Travis
+    - **TODO**: Once ASWF/LF commit to CI choice, Mark/Sean to investigate transition to new CI infastructure
+        - If OpenVDB adopts new system first, we can reference their setup.
+
+* Moving OCIO to ASWF Git organization
+    - Legal approvals for OCIO domain tranfer are complete!
+    - The GitHub account move should be fairly straightforward, but may bring down CI builds for a day or two during the transition.
+    - **TODO**: LF needs Travis and AppVeyor accounts created before we can move repo, to host CI builds.
+    - **TODO**: Larry/Michael to work with John/Thanh to facilitate the account move.
+    - There may be a requirement to fix some of the embedded external dependencies *before* the repo move to satisfy detected license issues (from the license scan).
+        - Patrick made a GH issue for further discussion on 3rd-party dependencies: #690
+
+* OCIO v2 Python bindings
+    - SPI proposes contributing new bindings via pybind11:
+        - Mark: Current OCIO bindings have no external dependency. Are we sure we want to introduce one, vs. using Python's C API?
+            - Larry: Supporting both Python 2 and 3 would make use of C API more complicated. pybind11 is simple to implement, and header only.
+    - Sean: Good opportunity to improve consistency in Python interface:
+        - Currently there are inconsistencies with argument and return types.
+        - Implementors are not always sure what types they'll get back from the API.
+    - Larry: proposes a design PR be created first (using new GH feature), which outlines the new interface, prior to actually doing the work.
+    - **TODO**: Michael to create new Python API design and submit PR for feedback/discussion/approval.
+
+* Apple has deprecated OpenGL
+    - Mark: One option could be to build a bridget between Vulcan and Metal. Proposes use of MoltenVK.
+    - Sean: SPIRV-Cross also worth investigation.
+    - Doug: We're not sure yet when OpenGL support will actually be removed by Apple.
+        - From my point of view, OCIO will definitely need to support low-level graphics APIs such as Vulkan and Metal, so the question is more when than if.
+        - Agreed MoltenVK is one option to investigate.
+    - Carl: Different parties within Apple have different opinions of timeline for dropping support.
+    - Mark: Nothing in OCIO's design is preventing Metal support from being added now.
+        - Doug: Investigation is needed not only on the shader language but also on how textures will be managed under a low-level graphics API.
+
+* 2019 SIGGRAPH BoF
+    - ASWF BoFs will be back to back.
+    - Mark: a smaller fishbowl room is preferred for the OCIO BoF, instead of a large hall (like what ACES had in 2018).
+        - This is an important meeting for the community. Need to make sure the format is not impacted.
+    - Effort should be taken (as much as possible) to avoid the OCIO BoF intersecting with other color talks.
+    - Valid points to raise to LF/ASWF as the overall event is organized.
+    - All that being said, having LF/ASWF help is getting these sessions organized is much appreciated.
+
+* OCIO-Configs ACES 1.1
+    - Carl raised question of an official ACES 1.1 OCIO config availability. Nuke team is asking.
+    - Doug: 1.1 has some key differences from 1.0.3, which will need to be taken into account (i.e., new outputTransform)
+    - Contributors who have been supporting these configs are busy with other projects, so timeline is uncertain.
+    - **TODO**: Foundry to follow up in ocio-user mail list and/or Slack, to see if anyone can offer a status update.
+
+* Items for next TSC meeting agenda:
+    - Status update on GH project move to ASWF account, and any impact this has on other TODOs.
@@ -0,0 +1,84 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Mar 11, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Carl Rand
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Thanh Ha - Academy Software Foundation / Linux Foundation
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* Prerequisites to moving the repository to ASWF
+    - Resolve "ext/" dependencies prior to the move.
+    - What are we going to do with the "ext/" directory?
+    - Do we maintain or replace?
+    - How will this affect CI?
+    - Platform specifics
+        - Linux isn't so much a problem, however Windows and MacOS are another story.
+        - Some of the major DCCs using OCIO are on Windows and MacOS which could prove problematic.
+        - Do we need to build all the dependencies first, and then build OCIO against them.
+    - It should be of the style
+        - Pull the dependencies, rather than using the archive files found in the "ext/" directory.
+        - Maybe also have a flag to say use my local build of the library.
+        - Run CMake and build.
+    - What is the motivation behind doing this?
+        - This maybe a good opportunity to address the technical debt.
+        - John: Happy to help connecting with the other project coordinators.
+        - Mark: Uncertain that it is actually technical debt and more of a purest point of view in that we don’t want code from other sources checked into the OCIO repository?
+    - It would be good to at least gain a better understanding of the dependencies.
+    - Some of the current dependencies have raised red flags.
+    - The LCMS color management repository has been abandoned. Is currently only used for baking ICC profiles.
+    - Mark: Happy to go away and fix up what he can.
+    - Larry: Raised that it may lead to security issues if we don’t do this. Old versions can cause problems. OpenEXR had this problem in the past.
+    - John: Mavin solved the dependency fetch for Java a while ago. We should look to solutions like this.
+    - Concerns we raised in that CMake is not the best at pulling in dependencies from the internet.
+    - Patrick: We are not just able to download binaries, but we will also need to download the source of specific versions and build locally on the machine building OCIO. We will also have to be careful about static libraries and symbols. We will have to look at name-spacing things carefully.
+    - We will need to make the TAC aware of any external code that is needed when we ship with the library.
+
+* CLA/DCO requirements
+    - Needs them signed before doing merges into the new repository.
+    - John: Resolving issues with the initial setup. Team is currently backlogged on other projects but hoping to get something done in the next couple of days.
+    - DCO when we are ready to DCO sign off with commits.
+    - Every commit will have DCO sign off.
+    - John: Some info can be pulled or referenced from the TAC guidelines.
+    - Larry: Who needs to sign off the work?
+        - John: We can refer to https://developercertificate.org/
+    - Michael: This isn’t required until we move to the new account. Not to worry about it for now.
+    - Want to have the Linux foundation CLA system up and running first, pre-sign all the CLAs, and do one commit to flick the switch.
+    - Larry: Have agreed on the CLA but not on all the surrounding areas e.g. signature blocks etc.
+    - **TODO**: Document DCO sign off practices in CONTRIBUTING.md.
+
+* Googlegroup archiving & updated gh-pages deployment
+    - Announced we will pull down the group in a week.
+    - A script will be run to get old content and re-import it into the new lists.
+    - John: Test run will done first to see how it works.
+    - The OCIO website will be updated accordingly.
+    - The new website has been updated but is yet to be deployed.
+
+* Fixed functions in the repository
+    - Sean asked if there has been any more follow up conversations about this.
+    - Kevin thought that this wasn't a show stopper for him.
+    - Kevin raised the camera log transform and whether or not the goal is being set from the ACES requirements.
+    - May require to change the camera op to support ARRI.
+    - **TODO**: Post a review as it's been up for a couple of weeks now.
+
+* Next 1.1.x release
+    - There are a small number of commits that will need to be signed off before the release is made.
+    - Agreed to call it the 1.1.1 release.
+    - It will be the first release of the year.
+    - **TODO**: Michael to finalize things to push it forward.
+    - **TODO**: Will need to update the change log for the new version.
@@ -0,0 +1,81 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 18, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Thanh Ha - Academy Software Foundation / Linux Foundation
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Jim Houston - consultant
+
+# **OCIO TSC Meeting Notes**
+
+* Copyright for OCIO Configs repo
+    - Repo currently does not have copyright notices, should address before aswf move.
+    - Group believes all contributions were made under the same terms as the main repo.
+    - John will provide notice, Michael volunteered to add.
+
+* CII Badge -- Security
+    - Chair asked if anyone had expertise and could help.  No volunteers.
+        - John: This is a common problem with many projects.
+    - We will add this to the list of items we are looking for contributors to help with.
+    - John suggested to move our checklist to the official CII site rather than having it in our own repo.
+    - Volunteers to help with that are welcome.  ;)
+    - What tools are available to help detect security issues?  Suggested areas to check?
+        - Larry: Fuzz test configs
+        - Kevin: Using problematic lib calls, unsafe path handling (e.g. ../..), fuzz test env vars.
+    - Carl: Some users need to protect LUTs as trade-secret.
+        - Larry: Should have a private means for users to report bugs.
+        - Michael: Need that for reporting security issues too.
+    - Any recommendations from LF regarding what to add to CI?
+        - Thanh: Some options are Nexus IQ, WhiteSource for security, Sonar Qube for static.
+        - Thanh is doing some investigation for TAC, we will follow closely for recommendations.
+    - John provide the following link: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md
+    - Chair asked John if we were moving too slowly, John: no.
+
+* 1.1.1 Release
+    - Michael: There are two PRs waiting, please review and approve.  Anything else to add?
+        - Patrick: Update version in cmake?
+    - Michael will create a draft for people to check.
+    - Side-benefit is this will update website with new email reflector addresses.
+
+* Pixel Format PR #699
+    - Doug and Patrick provided overview.
+    - Micheal: Are we deprecating 14 and 32-bit integer support?
+        - Doug: No, there were enums but no support in OCIO v1.
+        - Once the foundation is in place, others will be able to add additional formats, if desired.
+    - Will be more detailed discussion at next v2 working group meeting (probably next week).
+
+* Labeling GitHub issues for people to contribute
+    - Michael: "Good first issue" is often used but doesn't seem most appropriate for some.
+        - Some issues require serious dev work but don't require OCIO-specific knowledge.
+        - Larry, Patrick concur.
+    - John: Advised adopting common practices to make it easier for new contributors.
+    - John: Check out new LF "Community Bridge" initiative.
+    - People are asked to suggest label name to use for issues we'd like help with.
+
+* Pruning GitHub issue list
+    - Chair: We have 170 open issues, many old ones, let's try to see if any should be closed.
+
+* Email list migration
+    - Original Google Group lists shut down date is today.
+    - John will migrate existing archives as mbox file today (may take some time to show up).
+    - Chair will ask Sean/Mark to shut down the old groups.
+        - WBN if anyone that tries to post will get email with new list coordinates.
+
+* Other items
+    - Patrick: Some small PRs will merge this week #693, #694, #696, last call for reviews.
+    - Doug: Will schedule next v2 working group meeting for next week sometime.
@@ -0,0 +1,60 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 25, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Thanh Ha - Academy Software Foundation / Linux Foundation
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Jim Houston - consultant
+
+# **OCIO TSC Meeting Notes**
+
+* OCIO 1.1.1 Release
+    - There is one PR left (#705) to merge.  Please review.  
+
+* OCIO-Configs license/copyright update
+    - Michael prepared a PR (#17) to add the requested copyright notices.
+        - Uses the new short-form LF license text.
+    - Thomas pinged the contributers to the ACES config and we are awaiting their approval.
+    - Question: Could we remove the local copies of the ACES CTL code?
+
+* /ext refactor update
+    - No progress this week.
+
+* Google groups archive in GH repo?
+    - We agreed that we didn't want to store these in the OCIO repo.
+    - Decision was to store the mbox archives as groups.io files.
+    - John has now done this.
+
+* Google groups set to read-only, w/ auto-response
+    - Sean: "Updated the google groups. Posting via website and email should be disabled and updated the welcome page note to point to the new lists."
+
+* Rotating PR reviewer
+    - Looking for ways to encourage people to spend more time helping with code reviews.
+    - No objections to trying this to check if it's worthwhile.
+    - Michael will put together a rotating list of names.
+
+* ACES config
+    - Carl: Thomas Mansencal and Alex Forsythe will be looking at making a 1.1 config.
+    - Michael: The shapers used in the Output Transforms are causing clipping.
+        - Michael/Mark: The ACEScct shaper works better.
+        - Sean: The built-in log2/allocation transform might be better than a LUT.
+    - Kevin: The inverse Output Transforms have problems (aside from the known issues with the CTL).
+    - Chair: Please log issues on GitHub for problems/suggestions based on the 1.0.3 usage.
+
+* Other items
+    - Doug: Next v2 working group meeting is March 28 at 3 pm New York time.
@@ -0,0 +1,68 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+April 01, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [ ] Thanh Ha - Academy Software Foundation / Linux Foundation
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* PR review, secretary rotations
+    - We agreed on the principle and on the list published to ocio-tsc-private@lists.aswf.io
+      Here is the message link: https://lists.aswf.io/g/ocio-tsc-private/message/20
+
+* OCIO 1.1.1 Release
+    - We agreed to officially 'publish' the release.
+    - Larry G. mentioned to add collaboration notice.
+    - John M.: Emily Olin (LF PR person) will do a press release for the 1.1.1 release and post to social media.
+    - John M.: Would be great to have someone from OCIO sit in on the ASWF Outreach committee.
+    - Michael D. is currently discussing with 'VFX Reference Platform'.
+    - Michael volunteered to do the follow-up.
+
+* ACES config license/repo
+    - Michael prepared a PR (#17 from https://github.com/imageworks/OpenColorIO-Configs) to add the requested copyright notices.
+    - Thomas Mansencal will be working on updating the ACES config to support ACES 1.1.
+    - License:
+       - Academy owns these configs and code (i.e. Python scripts).
+       - Clarify with the Academy if they would be willing to use a standard OSS license.
+    - Mark B.: Do not know any studio using as-is these configurations.
+       - Carl R.: Nuke is using them.
+       - Doug W.: Small shops use them as-is.
+    - Comments: The Academy considers the CTL implementation as the reference i.e. not the OCIO configs.
+    - Mark B. / Doug W.: 
+       - Anyway, these configs could be generated (using Python code) so generated files 
+         should be considered as binaries.
+       - It's important for less sophisticated users to be able to download pre-built configs 
+         from somewhere (e.g. Academy website?) but the LUTs themselves do not need to be 
+         in the repo as GitHub does not handle these well.
+
+* Updates on current action items
+    - Mark B.: We're still working on the ext update.
+    - Doug W.: We held a v2 working group meeting last week on Zoom.
+       - Patrick H.: Discussion around the PR #699 (i.e. pixel format support) went well
+                     so I will now move forward if no objections.
+
+* TSC meeting cadence
+    - Michael D.: Is the meeting cadence fine?
+       - Larry G.: As long as the transition to the ASWF isn't completed, the cadence is good.
+    - No objections to continue with a TSC meeting per week.
+
+* Misc:
+    - John M.: Still working on the CLA, facing some challenges but it's moving.
+    - Larry G.: What happen with old branches (i.e. release ones) once the transition is completed?
+       - John M.: Do what has to be done for old branches.
@@ -0,0 +1,80 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+April 8, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker (Carl will do next week)
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF Intake checklist open items -- License scan
+    - No update on ext/ reorg project.
+    - Michael: Wrote Alex to see if we can change the license for the ACES config.
+    - Was agreement that we could avoid migrating the older configs to avoid the CTL issue.
+        - Michael: CTL was not just a copy of AMPAS repo, was edited.
+
+* ASWF Intake checklist open items -- CII badge -- Documentation
+    - Items for badge:
+        - SHOULD add/link coding standards to CONTRIBUTING.md
+        - MUST publish process for reporting vulnerabilities on project site
+        - MUST provide method for reporting private vulnerabilities
+        - SUGGESTS documenting policy on adding tests
+    - Larry: I've been super happy using clang format on OIIO.
+        - It's set up to break the build for format violations.
+        - Turned it off on a few files to handle special cases.
+    - Discussion of adopting it for OCIO.
+    - Patrick: Need to wait for a period where we don't have lots of PRs waiting to merge.
+        - Larry: Could do it as we get close to the v2 release, during stabilization.
+    - One issue is that it messes up Git blame/history.
+        - Carl: Perhaps create a tag just before the reformat.
+    - OCIO is not entirely consistent in following its own style guidelines.
+    - Could experiment with using clang format on new code.
+
+* ASWF Intake checklist open items -- CII badge -- Discussion items
+    - Items for badge:
+        - MUST include interim version for review between releases
+        - Test suite SHOULD cover all code, branches, functionality
+        - MUST enable warning flags, safe mode, or linter tool for quality checks
+        - MUST address most warnings 
+        - SUGGESTED to be maximally strict with warnings
+    - We agreed that the interpretation of the first item is that development must happen in the public repo.
+    - We agreed to require unit tests on new PRs going forward.
+        - However won't insist on 100% coverage, just the main functionality.
+    - Larry: badge requirements on testing are "should" rather than "must".
+    - Autodesk has put a lot of focus on testing and all the v2 PRs have tests.
+        - In some cases even more tests exist but depend on forthcoming PRs (TODOs in code).
+    - However, there are parts of the v1 code base which have either no or minimal coverage.
+    - Patrick has been working on enabling warnings, Linux almost working, Windows needs work.
+    - Autodesk has been trying to address new warnings reported on Slack, etc.
+
+* ASWF Intake checklist open items -- CII badge -- Security
+    - For security, we don't have experts among the regular contributors, need a champion.
+        - Would like to engage help from new contributers (was some discussion at LA ASWF meeting).
+        - It's unclear how high the bar is for the CII badge.
+        - Very interested to hear more from the TAC's working group.
+    - Larry: On OIIO I try compiling with the latest compilers, sometimes flags security issues.
+
+* ASWF Intake checklist open items -- CII badge -- Analysis
+    - Michael started looking at some of the analysis tools, SonarCloud (ASWF account).
+
+* 1.1.1 release
+    - Agreed we don't need to do a press release for 1.1.1.
+    - Michael: Got an LGTM from Sean on the site updates, will push that today.
+
+* Misc items
+    - Michael working on Python udpates.
+    - Thanh has left the LF.
@@ -0,0 +1,62 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Apr 11, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Carl Rand
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Vulnerability reporting
+    - Currently going through the CII badge discussions this week.
+    - Mainly focusing on documentation.
+    - Looking at offline private reporting mail of security vulnerabilities.
+    - Mail address will be security.ocio.org
+    - Larry: Is a private mail address private enough?
+    - Michael: The private aspect is only suggested. Other sites don't tend to go beyond a private mail. And doing so would be quite a bit more work and far more complicated.
+    - Michael has tested the mail system by emailing into it.
+    - Larry: We just need to make sure it's a mail that isn't publicly visible. It's very unlikely that someone is going to need it to be more private than that.
+    - Michael: The system states that it's private.
+    - John is currently setting up the email side of things.
+
+* Updates on ongoing tasks - Python bindings
+    - Michael is actively working on the bindings.
+    - Michael: The current API is not very Pythonic.
+    - Michael: Do we need backwards compatibility? Or can we split it?
+    - Kevin: It will depend on when we need to support Python 3 and whether we need to do something sooner rather than later.
+    - Kevin: If this is going to be in version 1.x then we would need to keep backwards compatibility.
+    - Michael: In 2.x we will have to remove some things regardless.
+    - Michael: Pushing the API changes back to 1.x is something we could do.
+    - Patrick: In 1.x the C API shouldn't change. Should this then not be the case for Python API?
+    - Michael: The option is there to backport the work done in 2.x to 1.x.
+    - Doug: For the near term we need to maintain backwards compatibility. Could we decide later and see what the new API will be like?
+    - Michael is starting off now by writing the documentation.
+        - Trying to balance out the types to reduce the inconsistences.
+        - Currently maintaining backwards compatibility.
+    - Larry: Switching the bindings to PyBind 11 might be a good time.
+    - Carl: Could we mark parts of the API as deprecated and remove them later to give people warning?
+        - Michael: The problem with this is trying to figure out the deprecation mechanism to use.
+    - Michael: OCIO 2.x will support both Python 2 and 3
+    - Kevin: We should make the C and Python API change at the same time. This will make it easier for users.
+    - Larry: The C/C++ and Python API should only deviate in places where it's natural for the specific language.
+
+* Other items discussed:
+    - Larry: Raised pushing the meeting forward by 30 minutes as the meetings are only lasting 20 - 30 minutes. It would help people in certain time zones due to rush hour.
+    - Next weeks meeting will be cancelled due to Easter holiday.
+    - Kevin will be on PR duty next week but wont be available on Monday.
+    
+
@@ -0,0 +1,102 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+April 29, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+
+Apologies:
+  * Sean Cooper (_TSC_) - DNEG
+  * Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* CLA/DSO System
+    - Doug: Wiki and website need more explanation of what to do (i.e. clear
+      steps to follow).
+    - John: There are two links:
+        - Wiki with info about what to do
+        - CLA console where signature and contributors are managed
+    - Doug: No problem with having two separate websites.
+        - Wiki has a lot of detailed info for someone already in the system, as
+          reference.
+        - Confused about what to send to executives/lawyers about what to do.
+          Having more concrete steps would be helpful.
+    - John: Multiple roles may be needed:
+        - Signatory: Name on CLA, who does sign off.
+        - CLA Manager: Person in organization that manages individual
+          contributors who are covered by the CLA.
+        - The manager is the one who enters names and maintains the system.
+        - Agrees the process is less than intuitive.
+    - John: Suggests a demo of the system from the LF product team.
+    - All: Agree a demo would be good.
+    - The demo could make sense to do at a TAC meeting, or just have a video,
+      but John suggests we do something in-person for now to unblock OCIO.
+    - Doug: On the create account website, it says only one account can be
+      created for an organization; not one per project. A CLA manager would
+      need to be someone at a corporate level, or of a parent organization.
+    - John: There can be a different manager and signatory for flexibility. The
+      manager can designate who can manage contributors. No need to get
+      corporate council involved to add someone.
+    - **TODO**: Schedule CLA system demo from LF product team.
+
+* SonarCloud Static Analysis
+    - Michael: Working on SonarCloud integration for Travis.
+        - Can't test from an external (forked) PR, so need a better way to test.
+        - Larry: You can create a dedicated testing branch and push changes to
+          that directly. That avoids PRs for testing and is internal to GH.
+        - Michael: Good idea. I'll do that for initial testing.
+    - Patrick: Does analysis break the build? Where do we see results?
+        - We need to know when something critical breaks, without having to
+          remember to check SonarCloud site.
+    - Michael: Results are on Imageworks SonarCloud account for now. PR #740
+      has a link.
+        - sonar-scanner returns non-0 exit if quality gate is not met, so will
+          break the build.
+        - There is a SonarCloud badge, which will tell you if the last analysis
+          is passing or failing. That will also link to full results.
+        - Needs testing once it is up and running to see how we should
+          configure it.
+
+* OSX CI Configurations
+    - Michael: Noticed that our OSX GCC build is actually a duplicate of the
+      Clang build. To use GCC, we have to set it up differently, since macOS
+      treats gcc as an alias to clang.
+    - Larry: Do we need a Mac GCC build? We have Linux GCC builds which should
+      catch he same errors and warnings.
+    - Michael: Perhaps instead we can have multiple OSX Clang builds with
+      different OS versions: older and newer?
+    - Patrick/Doug: Agree that is reasonable.
+    - Larry: Good to test with variety of OS versions to catch more issues.
+    - **TODO**: Michael will reconfigure the OSX test matrix.
+
+* LF CommunityBridge
+    - Michael: Since this is an official LF tool, and has security vulnerability
+      reporting, should we consider it instead of our current email approach?
+    - John: We should stay where we are for now. We need more data on
+      CommunityBridge, since it is new.
+
+* OCIO V2 Working Group
+    - Doug: V2 working group is tomorrow (April 30), 3pm EST.
+    - Michael: Will you be opening new PRs today or tomorrow for discussion?
+    - Doug: Will be opening PRs this week, and a GH issue today on one topic.
+        - Issue (for discussion) will be regarding new OCIO display transforms.
+    - Doug/Patrick: New PRs coming involve CPU renderer with bit-depth support
+      and API, etc.
+
+* Items for next TSC meeting agenda:
+    - Kevin mentioned in his apology that he had a topic, but will bring it up
+      at the next meeting.
@@ -0,0 +1,59 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+May 6, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* TSC Meeting:
+    - What is the quorum magic number and limitations?
+        - Charter requires 2/3 of members for quorum 
+          and says attendees "will be prevented from making any decisions at the meeting".
+    - Ask at the next TAC meeting if changes to quorum rules should be made.
+
+* Azure Pipeline:
+    - Last ASWF CI meeting, it seems to move in the Azure direction.
+        - May: CI build (i.e. Azure pipeline)
+        - June: Static analysis (Sonar Cloud) and security
+        - July: Dependency management
+        - Michael D.: Currently exploring Azure pipeline.
+            - Patrick H.: Will have a look to understand build breaks.
+
+    - Michael D.: OCIO still has the 'ext' dependencies.
+
+* Platforms / Compilers for CI builds:
+    - What are the expectations?
+    - Are VFX platform recommendations enough?
+        - Patrick H.: OCIO needs more.
+    - Michael D.: Will do a matrix, and send to all TSC members for review.
+
+* Package Manager:
+    - Michael D.: Conda seems nice and multiplatform.
+
+* Meeting cadence:
+    - Doug W.: Questioning about the meeting cadence and attendances.
+    - Michael D.: Will poke on the TSC Slack channel to have feedback.
+    - Doug W.: Time could change to better accomodate UK members.
+    - Patrick H.: Past experiences with UK the meeting was later to let folks be home.
+
+* Code transition to ASWF:
+    - Larry G.: CLA finalization is waiting for the OCIO code move to ASWF repo
+                and the code transition waits for the 'ext' third-party library changes.
+    - Larry G.: What is the status of the 'ext' third-party library transition?
+    - Michael D.: Will poke on the TSC Slack channel to have status.
@@ -0,0 +1,36 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+May 13, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+
+# **OCIO TSC Meeting Notes**
+
+* TSC meeting timing / cadence
+    - London folk are happy to keep the meetings at the current time.
+    - We will discuss cadence after ASWF migration is complete.
+
+* ext / refactor update and plan
+    - Is almost a blocker now (other than CLA changes).
+    - Provide a script to download the dependencies into an ext directory
+    - Then update the cmake code to still build the deps if they are
+      found in the ext dir, else look in the usual install locations
+    - Try to keep Windows use-case as simple as it is now.
+
+
@@ -0,0 +1,53 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+May 27, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Pull Requests:
+    - PR #750 nearing the 2 week mark, needs review.
+        - Michael: Will review today
+        - Bernard: Adds FixedFunction, Gamma, and Log transform support to CTF parsing.
+        - Michael: Does that complete the CTF integration?
+            - Doug: No, there is more coming, after this PR is merged.
+        - Doug: Participating in the ACES CLF working group:
+            - New transforms being added to support Log, ExponentWithLinear, etc.
+            - Next version will allow transforms like ACEScct to ACES2065-1 without LUT
+            - ACES 1.2 release later this year
+    - Patrick: PR #735 should be finalized, merged.
+        - Michael: will reach out to Carl
+
+* ACES OCIO-Configs license inquiry
+    - Michael: Havn't yet heard back from Alex about how to proceed with license; is 
+               there someone else we should contact?
+        - **TODO**: Ask Sean to raise this question at ACES TAC
+
+* Azure-pipelines Update
+    - Michael: Integrated Docker images into CI this weekend; was really simple to 
+               setup and will make it simpler to add or change build matrix.
+        - ASWF DockerHub can be used, and doesn't require link with GitHub, so not
+          bound by license scan issues.
+        - Building images based on VFX Ref Platform versions, as much as possible.
+        - Docker is supported for Linux and Windows only.
+        - Michael: Asks Patrick if he has a Windows Docker image as a starting point?
+            - Patrick: Is working on Windows, so only has Linux images, but has bat
+                       scripts that could be a starting point for setting up Windows
+                       env. Will send them to Michael.
+    
@@ -0,0 +1,42 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 3, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Sean Cooper
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [ ] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+* Azure CI
+   - Pull request coming soon ( PR #757 ), working on gcov integration to SonarCloud
+     - Larry: OIIO uses gcov if a reference is needed.
+   - Patrick: Any specific work needed in the future to complete it?
+     - Michael: Have yet to hook up gh-pages deployment, Docker images need to be moved to ASWF
+     - Everything is working, but there will be room for refinement and improvements.
+   - Patrick: Took a look at initial SonarCloud analysis. Making a first pass at resolving some of the detected bugs.
+
+* Ext Directory
+  - John Mertic and ASWF have no defined timeline for repo adoption
+    - ASWF would like to have some projects achieve adopted status by SIGGRAPH
+  - Giving Mark another 2 weeks to take a look, otherwise will look at re-assigning that work
+
+* OCIO Configs Repo
+  - Missing licenses and relies on external Academy ACES code with incompatible license
+  - Alex Forsyth or Scott Dyer will need to give us an update on how they anticipate handling it
+  
+* OCIO Domain https
+  - There is a domain level issue preventing GitHub Pages from enabling https
+  - **TODO**: John Mertic to submit a HelpDesk ticket about the issue
@@ -0,0 +1,69 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 10, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [ ] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+Apologies:
+  * Doug Walker (_TSC_) - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Pull Request #762:
+    - Larry G.: Added a missing paragraph in the CLA corporate document, nothing new.
+        - Waiting approval
+
+* Azure CI Build:
+    - Larry G.: Needs to build OCIO with some dependency master branch to trap coming issues?
+        - Larry G. Only some libraries:
+            As OpenEXR is an indirect dependency, perhaps not needed.
+            But OIIO could be a good candidate.
+        - Patrick H.: Supports the idea and the restriction.
+            - One platform / one compiler could be enough.
+
+    - Larry G.: OIIO has a vcpkg description usable, he suggests that OCIO team maintains one.
+        - Patrick H.: Would also be useful for devs as Windows platform is always problematic.
+
+    - VFX Reference Platform:
+        - Michael D.: Problem to follow the recommandations:
+            - CentOS package for the exact gcc version but Azure Linux is ubuntu.
+        - General discussion about important missing pieces causing trouble when willing to compile something:
+            - Larry G.: The CMake version is mssing, 
+            - Carl R.: The Visual Studio version is missing,
+            - Patrick H.: Nothing on Windows & OSX.
+
+    - Michael D: What about moving OIIO in ASWF?
+        - Larry G.: ASWF libraries are problematic ones :) - No plan for OIIO.
+
+    - Patrick H.: Add static analysis by default to the CI builds as the full build is only 30 mins.
+        - Larry G.: Support the idea.
+        - Carl R.: Build break on problems?
+            - Patrick H.: Yes and see if it becomes too restrictive.
+
+    - Michael D.: Must pause his work on Azure CI build for a while.
+
+* Pull Requests:
+    - PR #753 is waiting your feedback.
+        - Patrick H.: As mentioned next week, ready to merge.
+
+    - Other Autodesk PRs are not blocking.
+
+* Summer Vacation:
+    - Bernard Lefebvre from June 14 to July  7, 2019
+    - Patrick Hodoul   from June 27 to July 17, 2019
+
@@ -0,0 +1,68 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+
+
+TSC meeting 2019-06-17
+
+Host: Michael Dolan
+
+Rotating Secretary: Larry Gritz
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [x] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carl Rand (_TSC_) - Foundry
+  * [ ] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+
+
+# **OCIO TSC Meeting Notes**
+
+
+* ext dependencies
+    - Mike Dolan: if Mark doesn't have time to complete it soon, Mike can.
+    - Mark: that might be best
+    - **Action item**: they will coordinate
+
+
+* Switch to Docker images for CI builds
+    - Take Truelight out because it's a commercial product
+    - Will anybody in the community be inconvenienced?
+    - Patrick: still a concern because we don't have a good way to test it, can't access it.
+    - Mike: we can download it and build against it...
+    - Sean: ...but you can't use he library functionality without a license.
+    - Patrick: That's why we have almost no unit tests for it.
+    - **Action item**: Mike: Ask ocio-dev one more time for objections before pulling it.
+    - Other Linux builds will continue to use our own rather than ASWF docker images
+
+
+* Color math library:
+    - Mark: Almost ready to show color math library. Maybe demo next week?
+    - **Action item**: demo at next TSC meeting? Also describe on ocio-dev.
+
+* TSC meeting schedule:
+    - Next week is holiday in Quebec and Mike is coincidentally on vacation
+    - Two weeks from now July 1 is Canada Day, holiday in Canada.
+    - **Action item**: skip next two weeks. Next TSC meeting will therefore be on **July 8**.
+
+
+* BOF at SIGGRAPH:
+    - Back to back open source BOFs of ASWF groups on Tuesday.
+    - Also "leader's meeting" at lunchtime on that day, same place.
+    - Content of BOF: 
+        * General update
+        * Update from Autodesk on v2 progress
+        * Have story straight about release schedule
+        * Maybe Mark will talk about open color math library
+        * Sean won't be there, but might be able to supply slides for somebody else to talk about LUT inversion.
+    - Mark: Can we get swag? (ASWF might have shirts, etc.)
+    - Can we record BOF? More nicely than Sean's cell phone? Maybe ASWF will arrange it?
+
+* Items for next TSC meeting agenda:
+    - Mark will give demo/overview of color math library proposal.
+
@@ -0,0 +1,55 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 08, 2019
+
+Host: NAME (Michael Dolan)
+
+Rotating Secretary: Kevin Wheatley
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [x] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [x] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carl Rand (_TSC_) - Foundry
+  * [ ] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * Bernard Lefebvre - Autodesk
+  * Emily Olin - Linux Foundation
+
+Apologies:
+  Patrick, Doug
+
+# **OCIO TSC Meeting Notes**
+
+* Suggestions for SIGGRAPH BOF and WG meeting agenda
+    - ACES 1.1 config update
+    - Not clear on the exact features to show from the Autodesk Team, but likely
+    - Impact and changes of becoming ASWF project
+    - Mark offered to present Open Colour Math ideas
+    - Need to put out some messaging to the mailing lists to announce the BOf and working group meetings.
+    - **Action: Mark and Emily to discuss sizzle real content for SIGGRAPH**
+    - **Action: Michael to start with some blank ASWF slides to promt discussion**
+
+* ASFW Adoption progress
+    - CII badge needed - currently 97% done, still todo:
+      * Security experts; Larry suggests a pragmatic approach to say we will have experts on the code base who reasonably aware of security principals, but not specific security experts 
+	  * Security Policy documentation; Suggestion to adopt the OpenVDB style approach
+
+* "ext" refactoring update
+    - Implemented as a cmake script to download and build external dependencies
+    - patching is something we are trying to avoid in the new implementation for simplicity
+    - Being developed on Linux and using Azure to do cross platform checks
+    - SampleICC is trickier to implement as it is a hand-crafted subset of the full code base. **Action: Discuss with Doug when he is back from vacation**
+    - Unit test discussion, current choice to adopt a renamed OIIO unit test macros header,
+      possibly looking at alternate implementation in the future
+ 
+* Items for next TSC meeting agenda:
+    - Open Colour Math
+    - SampleICC dependency
+
+    
+
@@ -0,0 +1,83 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 22, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Open Source Maintainers Meeting
+    - Michael: We want to invite ACES leads to the meeting at SIGGRAPH. I don't
+      have all their contact info. Asks if Doug can provide it?
+    - **TODO**: Doug does, and is willing to reach out to Annie and JZ. Later
+      (offline) asks Sean if he would like to, since he is our ACES TAC rep.
+    - Meeting is Wednesday at 4pm.
+    - Larry clarifies that the purpose of the meeting isn't to advertise ASWF
+      or even attract new projects, but to discuss the ASWFs role in the wider
+      ecosystem, and how it can better work with and help other projects.
+
+* SIGGRAPH Working Group Meeting
+    - Michael proposes this be more of a working group meeting than a TSC
+      meeting
+    - Doug: We have two hours, so the TSC portion could be 30 minutes, and use
+      the rest for working group.
+    - Doug: Those not at SIGGRAPH can connect via Zoom.
+    - **TODO**: Doug will send invite to both ocio-dev and OCIO v2 working group
+      (google group).
+    - Doug: We should discuss release/pre-release branch and/or tag naming
+        - Other topics are CLF write support and recent CPU renderer performance
+          work (PR #769).
+        - Will show OCIO v2 roadmap
+
+* SIGGRAPH OCIO BoF
+    - Patrick: We really don't have a full hour; more like 45-50 minutes.
+    - Doug: Timing will be important to allow for discussion. Let's add target
+      durations to the slide deck notes to help keep us on track.
+    - Patrick: Someone should monitor time during meeting to keep things moving
+    - Doug: in interest of time, AD will not do live demo. Demos can be done
+      following meeting on Doug's laptop if there's interest.
+    - Michael: I will keep general project updates brief.
+    - Mark: Can keep OpenColorMath talk under 10 minutes.
+    - Michael: Thomas won't be there, but will provide statement to talk about
+      ACES 1.1 config.
+        - His work is mostly done, but not checked in anywhere yet, so we'll
+          likely be pointing people at his fork. Probably Ok since it's still
+          being tested.
+        - Michael: We're still trying to talk to Alex about what to do with
+          OCIO-Configs repo.
+        - Work will be included in Nuke 12 beta.
+        - Doug: Will have a slide to talk about improved ACES Output Transform 
+          support we added. Will have results vs. ACES 1.0.3 and Thomas' fork 
+          available on laptop for anyone interested.
+            - New shaper does improve performance on bright colors and is worth 
+              doing. However performance in some areas does get worse, so it is 
+              moving the error around more than eliminating it.
+            - ACES 1.2 is due out in the fall. Includes new ACESclip and revised 
+              CLF spec.
+            - ACES v2 (including Output Transform improvements, etc.) is still in 
+              planning phase.
+            - Michael: The version of the ACES config following Thomas' 1.1 
+              version will hopefully be able to use the new built-in OCIO transforms 
+              (next year sometime).
+
+* PR Update
+    - Michael: Let's review #769 this week. It's been open 26 days.
+    - Michael: ext/ work is ready for review. Do want to add shared lib support
+      for LCMS2 and pystring in the CI scripts, but not high priority.
+    - Patrick: That can be a TODO for later.
+    - Patrick: UnitTest changes need to be merged into #769, but not a big deal.
@@ -0,0 +1,60 @@
+July 31, 2019
+
+Hosts: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [x] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carl Rand (_TSC_) - Foundry
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * Chris Bankoff - Method
+  * Stephen Mackenzie - Method
+  * Matthias Scharfenberg - ILM
+
+Apologies:
+  Sean, Larry
+
+# **OCIO TSC Meeting Notes**
+
+* Next steps on ASWF transition
+    - Michael: Did a lot of license cleanup and need one more license scan.
+        - Main license file changed from "All code by Sony Pictures Imageworks" to 
+          "All code by Contributors to the OpenColorIO Project"
+        - OIIO license is in twice, once for unit-test/string-util, and again for arg-parse.
+    - John: The CLAs don't have license assignment/grant, everyone still owns their copyright.
+    - Michael: OCIOConfigs problem with ACES license also has not been resolved.
+        - Mark: Let's start a new repo rather than move the existing one.
+    - Michael: Everything else is done.  Will probably have vote at next TAC meeting!
+    - Not sure we have the authentication to fix the CI/Azure once the repo moves over.
+
+* Planning a 1.1.2 release
+    - VFX Reference Platform is currently "1.1.x".
+    - Doug: Could we roll Joseph's Iridas cube writer into a release? (No API change needed.)
+    - Patrick listed several bug fixes that would be nice to get out.
+        - Mark: Sounds good.
+    - Michael: Let's target a 1.1.2 for this fall.
+
+* Are Java bindings used?
+    - Mark: I did update them during the repo refactor.
+        - We got some bug reports from someone using them on Android.
+        - Not aware of specific apps though.
+    - Michael: We're not testing them.  They may not work with the v2 changes.
+    - Group: Should ask on ocoi-dev if anyone is using them.
+
+* Vendor directory clean-up
+    - Michael: Many of these are out of date.  Remove or keep as examples?
+    - Michael: Mari now has a solid integration that doesn't use what's in the repo.
+        - The ones in the repo are obsolete and perhaps should be removed.
+    - The RV example may also be obsolete.
+        - Michael: Would be great for community to contribute back to this.
+        - Mark: We have a custom one but need to support clients using the ocio one.
+    - Photoshop and AfterEffects are still valid and maintained.
+    - Doug: For vendors that have official OCIO support, maybe this isn't useful anymore?
+    - Mark: I would prefer the vendors provide up-to-date source for their implementations.
@@ -0,0 +1,85 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 5, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+Apologies:
+  Mark Boorer
+
+# **OCIO TSC Meeting Notes**
+
+* License Scan Status
+    - Michael: Test LUT files were called out as not having license notices. Can 
+      we have an exception with these?
+    - John: The ASWF governing board can approve exceptions. They will need to 
+      approve the sampleicc exception.
+    - Doug: Could put a license file in the test data directory which applies 
+      to all files.
+    - John: Agrees that would be a good approach. BSD-3-Clause is the most 
+      appropriate license for these files.
+    - **TODO**: Michael will add LICENSE.md file to test/data dir in PR #783
+    - **TODO**: Larry will discuss the flagged “Cloudy with a Chance of 
+      Meatballs” images with Sony.
+    - Kevin: We also need to update the LICENSE on the OCIO website
+    - Michael: That is pulled from GitHub, but currently from the RB-1.1 
+      branch. Since the license cleanup work is being done in master, is it Ok 
+      to wait for a 2.0 release next year to update the site?
+    - John: That should be Ok.
+    - Kevin: Let’s make a note to not forget it.
+    - Michael: Sean is looking into updated website and docs, so can take that 
+      into account.
+    - **TODO**: Sean will update website LICENSE as part of redesign.
+
+* Committers Policy
+    - PR #785 lists current committers, and is a requirement for graduation. 
+      Should we establish a policy for removing names from this list when they 
+      are inactive?
+    - Patrick: The goal is not to push people out, but to encourage 
+      participation. One option would be to have a duration of inactivity, 2-3 
+      years, at which point the TSC discusses pruning up the list.
+    - John: The GOVERNANCE file already gives the TSC discretion to give 
+      inactive committers emeritus status, or to remove them.
+    - Doug: That’s the list of people whose approval counts toward merge. If 
+      there were someone who we thought was active and qualified, they could be 
+      added to the list, to help with reviews. Removing inactive people is not 
+      a critical need.
+    - John: There’s often a good reason why people have not been around.
+    - Patrick: We could commit the current COMMITTERS file as-is, and contact 
+      inactive committers to inquire of interest in continued participation.
+    - **TODO**: Michael will reach out to those with admin/write status to ask 
+      if they would like to remain involved in OCIO.
+
+* SIGGRAPH Recap
+    - Doug: Good turnout to BoF, in spite of it happening at the same time as 
+      USD BoF.
+        - Side-conversations and feedback on the event were positive.
+        - There was an email discussion prior to SIGGRAPH about a joint 
+          ACES/OCIO meeting, but it didn't work out.
+    - Michael: Mark's OpenColorMath preview was well received. Questions at BoF 
+      were all about that work.
+    - Michael: We were approached by an engineer from Method interested in 
+      helping with Python docs, and by Netflix post production about interest in 
+      contributing.
+    - Sean: Asks about work on the new Python bindings, since pybind11 has 
+      interface for docstrings, which will affect doc contributions.
+        - Michael: I'll continue work on the bindings soon. I have SPI's blessing 
+          to do the work, since we're in need of the Python 3 support.
+        - Michael: I noticed OpenTimelineIO's C++ branch is using pybind11. That 
+          and OpenImageIO will be great reference.
+        - Larry: MaterialX is also using pybind11.
@@ -0,0 +1,44 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 12, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+Apologies:
+
+# **OCIO TSC Meeting Notes**
+
+* Moving repo to ASWF
+  - CLA needs finalizing from Sony
+  - ASWF needs all things to be under same license for final approval
+  - Doug will look at unit test licenses
+  - Unsure if [CI/Slack] will continue working / authenticating after move, so might need to be fixed soon after.
+
+* Mingw on windows patches
+ - Does this correspond to a new platform?
+   - How should we respond to requests of this nature?
+
+   - Mark thinks as long as the community is responding / submitting patches
+     we should consider it “supported”
+   - Remember that adding CI for every platform might be expensive (in terms of build time or other resources)
+
+   - Larry says that we should accept all reasonable patches, though perhaps only “supported platforms” would be listed in any documentation. Supported platforms might include only those we have CI for.
+
+  - TODO: Michael will check that the CI works on the Release branch as well
+
+  - For now we won’t add MinGW to the CI Matrix
@@ -0,0 +1,45 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 19, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+
+# **OCIO TSC Meeting Notes**
+
+* License
+    - Larry: SPI legal is ok having SPI copyright removed from files.
+    - Larry: Add one line in README.md to indicate that files originated from SPI.
+    - Doug: Still discussing with Autodesk legal about deleting our copyright.
+
+* RB-1.1
+    - Michael: Following the approval for another minor release (*TSC meeting 2019-08-12*),
+      Travis & AppVeyor (i.e. the former CI build) are back for the RB-1.1 branch only.
+        - AppVeyor uses RB-1.1 & master branch
+            - **TODO**: Sean will help to disable master.
+        - Travis triggers new warnings/errors.
+          Check [PR 798](https://github.com/imageworks/OpenColorIO/pull/798) for details.
+            - Agreed to fix them.
+            - **TODO**: Let others have a look to help.
+
+* Python Bindings
+    - Michael: Currently working on the Python bindings using pybind11.
+        - Facing some complexity to correctly support class without public destructor
+        i.e. all public classes.
+        - **TODO**: Michael will create a 'draft' pull request to present his proposal.
+        - **TODO**: Let others have a look to help.
@@ -0,0 +1,54 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 9, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Kevin Wheatley
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [ ] Bernard Lefebvre - Autodesk
+
+
+# **OCIO TSC Meeting Notes**
+
+* Granting Kevin Wheatley rights to act as an approver for pull requests (write access). Approved **Michael to action in github**
+
+* GPU host for CI infrastructure, funding is approved. We really only need lower end GPU capabilities, but does need to be real hardware.
+
+  Need to call out to TAC? John queried Andy@LF on progress, challenge with creating dynamic builders with GPU resources.
+
+  Carl noted that it may be worth having some variety of hardware vendors as they have different compliance levels with OpenGL.
+
+  **Invite Andy to next weeks TSC Meeting**
+
+* John reported that the governing board approved the license waivers. This should be the last hurdle to migrating the repository to the ASWF.
+
+  Contributers will thus need to have their CLA signed.
+
+  Query over the status of the Autodesk CLA, it should have been done.
+
+  **Michael to drop the TAC an email, requesting migration**
+
+  **Doug to approve license pull request #799**
+
+* Issue with Azure builds not passing status check to github, help request is in with Microsoft.
+
+* Python bindings discussion around trying to improve automatic generation of bindings. Autodesk to take a look at what could be done to smooth out this.
+
+  Michael noted that we need a way to handle read only objects in python.
+
+  Explanation around the use of shared_ptr<> with private destructors.
+
+  **Michael to submit example pull request** showing how it could be if we did not have private destructors so the team can better understand the issue and offer suggestions.
+
@@ -0,0 +1,45 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 16, 2019
+
+Host: Doug Walker
+
+Rotating Secretary: Carl Rand
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [ ] Bernard Lefebvre - Autodesk
+
+Apologies:
+   Michael Dolan
+
+# **OCIO TSC Meeting Notes**
+
+* Do we need to support GCC 4 and 5 anymore?
+    - Doug raised that pull request #831 removes macros specific to these versions of GCC.
+    - Patrick raised that as we add more C+11 features the more we will be restricted.
+    - Kevin thinks we should definitely drop support for GCC 3.
+    - Patrick thought dropping GCC 3 would be fine and should be done in the master branch.
+
+* Azure CI build
+    - Patrick raised that the communication between Azure and Github is broken.
+    - Even when a pull request passes it still remains highlighted as red.
+    - Because of this an administrator has to sign off each individual pull request which is slowing the whole process down.
+    - It looks like a bug in the Azure side.
+    - We are currently waiting on the Azure team to fix the issue.
+
+* Python bindings
+    - Doug asked if there was a way to use pybind11 in an automatic way due to the destructor being private?
+    - Patrick hasn't been able to find a nicer way to do it without making a major change to the API.
+    - The only way seems to be to change the destructor from private to public.
+    - Making the destructor public might be the best and simplest solution.
+    - Doug thought if we went the public route we would need to document it in the API and explain that no one should really call this themselves.
@@ -0,0 +1,47 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Sept. 23, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Sean Cooper
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [x] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [x] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carl Rand (_TSC_) - Foundry
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+
+# **OCIO TSC Meeting Notes**
+
+* Repo Ready to Move!
+    - Just submit a helpdesk ticket to move it over to ASWF
+    - TravisCI & Appveyor - need to be setup again most likely (to look into)
+    - Patrick and Doug want to wait for 4 critical/major PRs to be merged before moving
+
+* CLA
+    - Existing PRs would need to be amended with DCO
+    - Would be great to part of the PR check system (easily visible)
+
+* Config Repo
+    - Need to sort out how to proceed...
+    - Need to reach out to AMPAS to sort out ownership/license
+    - Ideally the configs would run a CI system and produce the LUTs as artifacts to download
+    - Would be good to have modern-day example configs from studios
+    - Need to have a config that utilizes all of the features of OCIO (Looks!) for application developers to reference
+    
+* Docs
+    - Sean presented a draft look for a new website / API docs
+    - Patrick noted that it should be clang-format friendly
+    - Most of the group seems comfortable moving away from Sphinx
+
+* Items for next TSC meeting agenda:
+    - Loop back on OpenColorIO-Config repo
+    - Further discussion of documentation
+    - Status update on Repo move
@@ -0,0 +1,99 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+DATE
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * Bernard Lefebvre - Autodesk
+  * Carol Payne - Netflix
+  * Andrew Grimberg - Linux Foundation
+
+Apologies:
+  NONE
+
+# **OCIO TSC Meeting Notes**
+
+* OpenColorIO repo move:
+    - Michael: Will we have admin access to the ASWF Azure and SonarCloud
+      accounts? So we can update private keys and trigger builds, etc.
+    - Andrew: You will have rights to SonarCloud. We're still working on 
+      rights for Azure.
+        - Will need to go through helpdesk ticket for now for pipeline 
+          updates.
+        - ASWF has a single Azure account with a pipeline per project, so 
+          permissions are complicated. Want to have a single landing page
+          for projects to keep them discoverable.
+    - Larry: Everyone OK with me requestign the repo move after the meeting?
+        - All: Yes.
+    - Mark: Should we let the community know?
+        - Michael: Yes. I sent a notice last week to ocio-dev, and will
+          update the thread.
+    - Andrew: Purged the previous ASWF OCIO fork already.
+
+* OpenColorIO-Configs:
+    - Sean: We might want to start from scratch with a new config repo, and
+      find better solution using CI and lists.aswf.io to store build artifacts.
+    - Doug: Many issues with aces config, particularly versioning.
+        - Nuke 12 just shipped with forked version.
+        - We need to add new spaces, but not sure if that will wait for 1.2,
+          or have revision of 1.1.
+        - How do people know which release they are using?
+        - Carl: We struggled to get 1.1 ready for nuke 12. Needs clearer
+          ownership.
+        - Sean: There's complexity with taking ownership of it. Also hard to 
+          distribute non-ACES camera transforms.
+    - Michael: Need to resolve ACES config licensing first.
+    - Doug: Need a joint meeting with stakeholders.
+        - Carol: I'm in LA and can reach out to the Academy if needed.
+        - Sean: Should we raise this in an OCIO or ACES forum? How public?
+        - Public is OK, and we can offline discussion as needed.
+        - **TODO**: Sean will reach out to ACES for how to proceed.
+    
+* Docs discussion:
+    - Michael: Should we use RTD? Sphinx? Or soemthing else? Is the concern
+      with RTD just the style? Or something lower level?
+    - Andrew: Can use any style we want with RTD. We also have beta access to
+      API v3.
+    - Sean: Any reason for ASWF not providing similar standalone service?
+        - Andrew: RTD is easy to use, works with GH tags automatically, will
+          warn if you're reading an old version.
+        - RTD can bring people back to source. LF can also create a top-level
+          site, so ASWF projects can be interlinked via Sphinx.
+        - Sean: Any examples for reference?
+        - Andrew: LF Release Engineering, OpenDaylight, etc.
+    - Larry: OIIO converted to RTD, from a 450 pg book.
+    - Michael: Does RTD support custom designed landing page?
+    - Andrew: RTD is limited to rst.
+    - Michael: Could have a custom site linked to RTD, like colour-science.
+      The OCIO website and logo could use refresh in general.
+        - Sean: gh-pages can continue to host website and link to RST.
+        - John: Can kick ideas to LF creative services to create logo if needed.
+    - Sean: Would like to have good user story, with flexibility to demonstrate 
+      working with DCCs, etc.
+    - **TODO**: Sean will continue investigating website and RTD docs.
+    
+  GPU CI:
+    - Doug: Anything to discuss with Andrew regarding GPU CI support?
+    - Andrew: TAC voted to decomission jenkins, so budget is available for GPUs.
+        - ASWF can now bring up instances in Azure and attach to our pool.
+        - Need to know how to configure static instances, no dynamic launching.
+    - Michael: Sean Looper (AWS) offered free GPU instances. Can we use those.
+        - Andrew: Yes, that would work too.
+        - Michael: Let's make this our focus following the repo move and continue 
+          discussion.
+
+* Items for next TSC meeting agenda:
+    - GPU CI direction. Invite Andrew and Sean Looper to TSC meeting?
@@ -0,0 +1,42 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 7, 2019
+
+Host: Doug Walker
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Michael Min - Netflix
+  * [X] Carol Payne - Netflix
+  * [X] Bernard Lefebvre - Autodesk
+
+Apologies:
+   Michael Dolan
+
+# **OCIO TSC Meeting Notes**
+
+* Question for John re: DCO sign-off process
+  Doug - What happens if the email that people are signing-off with is not the email of their employer (eg @autodesk.com).
+  Lary - The CLA manager can log on and list all the emails that are associated with their employees.
+
+  Only email addresses OK'd by the CLA manager (or domain, github user, etc) will be approved.
+  
+  DCO doesn't tell us /why/ a certain pull request was approved. So potentially a new feature request.
+  John will confirm with the team as to how the DCO sign off will behave when a user has not completed the CLA process correctly, or is a new user.
+
+* No updates on documentation refresh
+
+* Hacktober fest tag work done by Patrick, looking for other volunteers to improve visibility
+
+* No meeting next week (14/10/2019) due to thanksgiving in Canada
@@ -0,0 +1,38 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 21, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* GPU CI Enablement
+    - Michael logged a ticket with LF to take advantage of AWS GPU instances offered by Sean Looper.
+    - Michael Johnson from Apple is also investigating getting us GPU CI support for MacOS.
+
+* 1.1.2 Release
+    - As discussed earlier, there are several small fixes that could be rolled into a 1.1.2 release.
+    - Discussed what the time frame might be for this in order to best help client apps.
+        - Nuke 12 has already shipped with 1.1.1.
+    - We are still thinking of doing a 1.1.2 later in the year, but are not targeting a specific date yet.
+
+* Active Display/View Error Handling
+    - Doug/Patrick: We are looking to fix some long-standing issues with active displays/views.
+    - Is anyone opposed to throwing an exception if a supplied active display/view doesn't exist?
+    - The logic around default display/view is a bit confusing (e.g. alphabetical vs. config order).
+    - The group agreed that there are issues that should be cleaned up.
@@ -0,0 +1,40 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 28, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Carol Payne - Netflix
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Repo. admin. rights
+    - To document the policy concerning repository rights vs. roles.
+
+* Branch protected
+    - Agreement to only protect `master`, `RB-**` and `gh-pages`.
+
+* Stalled pull requests
+    - Agreement to not have any automatic removal of stalled pull requests.
+    - Agreement to check from time to time the pull request validity (i.e. contact the owner).
+
+* Yaml concerns
+    - Proposal to move to a recent version.
+    - Michael remembers some issue(s) around newer Yaml versions.
+    - Comment on security concerns using very old library version.
+    - Larry: At some point, need to implement security checks on third-party libraries 
+             such as Yaml, eXpat etc.
@@ -0,0 +1,85 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 04, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Yaml 0.6.2 support
+    - Patrick investigated and implemented latest yaml-cpp version. Functioning 
+      properly on all platforms, and no boost dependency.
+    - Investigated floating point precision issue. Was able to increase 
+      precision to 15 digits.
+    - Display order problem is not resolved, since it's a limitation of 
+      std::map used by yaml-cpp.
+        - Kevin: If numerical ids are used instead of names, that would preserve 
+          order.
+        - **TODO**: Patrick will investigate numerical ids.
+    - Could OLDYAML support be definitively removed?
+        - All agree, yes. Remove support for old yaml-cpp version.
+
+* PR #875, active_views filtering and ordering
+    - PR submitted by Patrick, and has been approved for merge.
+    - Displays and views are now filtered and ordered similarly, but there's 
+      still no validation that an active display or view is actually defined.
+    - Patrick: View behavior was modified to exactly match display behavior.
+    - Doug: Needs second pass at some point to improve error handling, but 
+      nervous to change long standing behavior.
+        - If an active display doesnt exist, should we throw exception? It 
+          currently doesn't.
+        - Patrick: active_views applies to all displays, though views can 
+          differ between displays.
+        - Michael: Could we add checks to Config validation? That would warn 
+          users when an error can be detected, but not change functionality.
+        - Doug: Also must consider active display and view environment 
+          variables, which wouldn't always be validated.
+
+* color_picking role usage
+    - Michael: Intended for a color picker view transform, a picking space 
+      (i.e. assumed screen buffer color space), or both?
+    - Mark: Both. It's application specific behavior, but most DCCs dont put 
+      view transform on color palette.
+        - Doug: Why not apply view transform to palette?
+        - Mark: Could be issues with a client LUT clamping colors, and many 3D 
+          LTUs aren't cleanly reversable.
+    - All agree that picking colors for textures is different. View transform
+      can make less sense in this case, especially where users don't want RGB 
+      values greater than 1.
+    - Doug: What to do when you have a rendering space that differs from 
+      viewing space?
+        - Mark: Could understand having color picker with choice of scene and 
+          display space.
+    - Kevin: Wondering if we have the right set of roles these days. Different 
+      apps have different needs. Could it be unified around what an application 
+      is trying to do?
+        - Doug: More specific roles would be good.
+    - **TODO**: Improve documentation around standard roles and how they are 
+      intended to be used.
+
+- Patrick: Question about macOS CI with LFRE
+    - Highlights our lack of control of our build machines
+    - It would be good to know what we are compiling on, especially if we 
+      someday distribute build artifact binaries. Need to know machine, 
+      compiler, etc.
+    - Michael: Put in an LFRE helpdesk ticket for insight around this. Might
+      be possible to move away from Microsoft hosted agents at some point, 
+      particularly with discussions happening with Wave.
+
+* Items for next TSC meeting agenda:
+    - Holiday next week for Vancouver.
@@ -0,0 +1,61 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 18, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [x] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Problems with the CI queue
+    - Patrick: The CI system has been having problems with jobs not running properly.
+      We need a manual way to restart the CI builds/checks.
+    - Michael: We lost the feature when the repo moved from Imageworks over to LF.
+
+* Admin access
+    - Michael: There is a discussion going on at the TAC member level about admin 
+      access to the GitHub repo.  Other projects also want more access.  Need to 
+      balance this against LFRE policies.  Stay tuned ...
+
+* GPU CI
+    - Doug: This was discussed at last week's TAC CI working group.  It was identified
+      as a goal to have this working for OCIO by year's end.  JF Panisset proposed a 
+      list of suitable hardware instances on Azure, AWS, Google.  AZP does not support
+      dynamic instancing yet but it was agreed to move forward anyway.
+    - Michael: I updated our ticket with LFRE to ask them to move forward with the
+      AWS option.  Hopefully dynamic instancing will be available in a few months.
+    - Michael: I'm working with John Mertic to try and get access for more people to
+      be able to see our OCIO LFRE tickets.
+
+* PR #884 Optimization
+    - Doug: This is a big piece of work from the Autodesk team to upgrade the transform
+      chain optimization process, building on the foundation that was in OCIO and
+      adding a lot of new capabilities and unit tests.  The starting point for doing
+      your review should be OpOptimizers.cpp.  We will go into more detail at the
+      OCIO v2 working group meeting on Wednesday.
+
+* ACES Implementation TAC
+    - Sean: The first ACES Implementation TAC meeting is tomorrow.  Sean and Kevin are
+      on the TAC and Doug is chairing the CLF Implementation VWG.  Everyone is welcome
+      to attend via GoToMeeting, details are on ACESCentral.
+    - Michael: Perhaps it would be useful to bring up the topic of how to transition
+      the OCIO-Configs repo.
+
+* Misc. Items
+    - Patrick: Is anyone else having problems with git pull not returning the latest commit?
+        - Kevin: I just tried it and seem to be getting the latest commit.
+    - Doug: Please join us for the OCIO v2 working group meeting on Wednesday.
@@ -0,0 +1,53 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Nov 25, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mei Chu - Sony Pictures Imageworks
+
+Apologies:
+  * Sean Cooper
+  * Larry Gritz
+
+# **OCIO TSC Meeting Notes**
+
+* License for OpenColorIO-Configs
+  - Annoying that official ACES config is in someone's personal fork, rather than the official repo
+
+* Mission statement in repo
+  - Michael has made a pull request as a starting point
+
+* Automated GPU unit tests
+  - There is an implementation on the ASWF lists, shouldn't be too hard to implement.
+  - How are these funded? Free trial?
+
+* v2 Working group meeting minutes
+  - Should these be added to the OCIO repo? Yes!
+
+* Use of environment variables in roles
+  - should we be able to assign roles to environment variables?
+ 
+* Colorspace aliases?
+  - Is equality group the only way to define these?
+  - Could YAML references work?
+  - Might be nice to have an OCIO API way to define an alias
+  - Can use roles :S
+
+* get_colorspace_from_filename
+  - Doug will post some issues to get feedback on how application authors should respond to 
+    strict_parsing or errors finding colourspaces
@@ -0,0 +1,98 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 9, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Foundry
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+Apologies:
+  Kevin Wheatley
+  Larry Gritz
+
+# **OCIO TSC Meeting Notes**
+
+* TSC membership changes
+    - Carl: Peter Crossley will be the new Foundry TSC representative 
+      starting next week.
+    
+* OCIO-Configs AMPAS license update
+    - Michael wrote ACES chairs and staff. Annie responded that they will 
+      discuss and get back to us.
+        - Patrick: What is the plan if we can’t resolve the licenses?
+        - Michael: The code can stay on Imageworks GH for now.
+    - Michael: When OCIO v2 is complete, a new ACES config will be needed to 
+      make use of the new features.
+        - Doug: The existing ACES config will still be valid and supported as 
+          well.
+        - Sean: The new config will need a Python re-write. Someone should 
+          clearly contribute that work under AMPAS/ACES for a fresh start.
+        - Will need note indicating which config should be used to avoid 
+          confusion.
+    - Doug: Need general example code for developers in repo showing how devs 
+      would take advantage of new features, with configs for users and config 
+      authors.
+        - Patrick: Commandline apps provide good code examples. Will need to 
+          be correctly upgraded to OCIO v2 to demonstrate new API.
+        - Sean: Should also demonstrate how to implement color management in 
+          applications. Need high-level guidelines on proper OCIO usage.
+
+* Docs update
+    - Sean: Working on cleaning up docs, with the goal of parity between Python 
+      and C++, without having to rewrite docstrings and examples.
+    - Michael: Larry did the same for OIIO last year, consolidating all docs to 
+      one RTD setup. It would be worth seeing what he did.
+
+* GPU CI update
+    - Michael: Waiting on AZP setup from LFRE. JF Panisset has working 
+      implementation in his OCIO fork and personal AZP acocunt. He is talking 
+      offline with Micrsosoft TAC rep about when dynamic instances might be 
+      supported.
+    - Patrick: What JF did works well. Just CI pipeline configuration needed 
+      for the most part.
+    - **TODO**: Michael to follow up with LFRE on state us AZP/AWS setup.
+
+* Mission Statement
+    - Michael: Take a look when you have a chance. TAC is asking projects to 
+      create these statements to help communicate project goals.
+    - Doug is it a vision statement or mission statement? Mission statement is 
+      more tactical.
+    - Michael: Tactical sounds right. It should outline our goals and 
+      commitment to advancing and maintaining a healthy project and continuing 
+      to serve the industry.
+    - Doug: Most of the things currently outlined are being met now.
+    - Michael: Yes, that’s great. The mission statement will help keep that 
+      focus long term.
+
+* Holiday schedule
+    - No meeting Dec 23 or 30; resume in January. We will meet on the 16th for 
+      anyone who is available.
+    - Michael: Also I wanted to mention that February marks the end of our first 
+      TSC leadership term, if anybody has an interest in serving in a leadership 
+      role.
+
+* Python bindings update
+    - Sean: What’s the status of the bindings?
+    - Michael: I’ve bound all the transforms; working on the config currently.
+    - Patrick/Doug: Anything you need help with in the library?
+    - Michael: We will need to make the Transform destructor public, and decide 
+      if it makes sense to unify array arguments to API. I already changed the 
+      destructor, and we can address the array arguments later if needed.
+        - Still need to write lots of unit tests, but can share the WIP code if 
+          there's interest, for review or collaboration.
+        - Patrick: You could push it in a partially completed state to avoid one 
+          massive PR if needed.
+        - WIP link: https://github.com/michdolan/OpenColorIO/tree/ocio_pybind/src/bindings/python
@@ -0,0 +1,39 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 16, 2019
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carl Rand (_TSC_) - Foundry
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [x] Bernard Lefebvre - Autodesk
+  * [x] Mei Chu - Imageworks
+
+Apologies: Mark Boorer, Larry Gritz, Kevin Wheatley
+
+# **OCIO TSC Meeting Notes**
+
+* GPU CI
+    - Michael: For now, let's get a permanent instance running with help from LF.
+      Need to get billing/credit side sorted with AWS also.
+
+* Spark conference in Vancouver
+    - Michael: Matthias and Mario have agreed to run an OCIO BoF at this conference in
+      February.  We should all discuss/plan details.
+    - Perhaps invite them to attend a TSC meeting.
+    - Audience questions may be interesting to share, will it be recorded?  Join remotely?
+
+* Misc. Items
+    - Carl: Joining Weta but would like to stay involved in OCIO.
+    - Need to follow up on Foundry representation.
@@ -0,0 +1,69 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+January 6, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Sony Pictures Imageworks
+  * [x] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [x] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Foundry
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * [x] Bernard Lefebvre - Autodesk
+  * [x] Dennis Adams - Sony
+  * [x] Michael Min - Netflix
+
+# **OCIO TSC Meeting Notes**
+
+* PR #904 File Rules
+    - Michael: Wondering if it would help to use sub-classes for the rule types.
+    - Bernard: We considered it but it is simple enough right now not to need that.
+    - Michael: Are rules required for v2 configs?
+    - Bernard/Doug: No, the new rules are optional.
+    - Michael: Strict parsing (ability to have app ask for color space when a rule is not
+      found) is important, how will that work?
+    - Bernard: The existing v1 API for that continues to work and we added a helper 
+      function to detect if the default rule was the one that matched.
+    - Michael: Good documentation will be key.
+
+* GPU CI
+    - Michael: John what is the status on our GPU CI ticket with LF?
+      https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-17952
+    - John: Andy ran into some issues with Azure, he hopes to address them in the next week.
+    - Doug: JF did a lot of work and prototyped a solution in his sandbox, we would like
+      help from LF setting up something similar using Azure and an AWS instance.
+    - Michael: We don't have permission to tinker with the Azure settings (also want to be
+      careful to use cloud resources efficiently) so we are waiting on LF.
+
+* Spark conference in Vancouver
+    - Michael: Should start pulling a presentation together for this.  ACTION: Send link
+      to a draft GoogleDoc.
+    - Doug: I will add a slide for OCIO v2 feature progress.
+
+* V2 update
+    - Larry: Any update on OCIO v2 progress?
+    - Doug: We feel we are still on track for the roadmap we shared last SIGGRAPH, namely
+      that we plan to be feature-complete at the coming SIGGRAPH.
+
+* CUDA
+    - Larry: As GPU rendering becomes more widespread I expect it will be important to be
+      able to have an OCIO CUDA rendering path.  Is that on anyone's radar?
+    - Patrick: Agree that it is important at some point but it is not in the v2 plan.
+      Would be great to get some help from other ASWF members on projects like that.
+    - John: Suggest adding issues on GitHub for these projects.
+
+* Google Summer of Code
+    - Larry: I'm trying to get ASWF into GSoC this year.  Please start thinking about
+      projects that an undergrad could take on as a summer project.
+
+* Misc. Items
+    - Doug: Academy Common LUT Format implementation VWG first meeting is Friday, 
+      January 10, 1-2pm Los Angeles time.  https://global.gotomeeting.com/join/241798885
@@ -0,0 +1,60 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+January 13, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Carol Payne - Netflix
+  * [X] Dennis Adams - Sony
+
+Apologies:
+  Larry Gritz
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF Plenary Meeting topics
+    - Michael: Meeting on Jan 30th in LA. We have been invited to give bigger 
+      update due to OCIO v2 release coming later in the year.
+    - Doug: We presented 4 slides last year. There are more projects this 
+      year, which could mean less time to present.
+    - Michael: Since OCIO v2 has been widely anticipated, it is a notable event
+      for the foundation this year. We could recap some of what was presented at 
+      SIGGRAPH.
+    - Doug: People may not care about features much, since there won't be a lot 
+      of color management people. We could talk about logistics of the v2 rollout, 
+      testing, and deployment, etc.
+    - Michael: There could be interest in ACES features since it's two Academy 
+      projects converging; and  the recent performance improvements.
+    - Doug: We can use the bar graph progress slide for a quick summary, and show 
+      roadmap.
+    - Michael: We don't have to cover every point, but could highlight it.
+    - **TODO**: Michael will put a prospective outline in Slack for discussion.
+    - **TODO**: Doug will share slides from last year.
+
+* Spark BOF updates
+    - This BOF will be 30 minutes and have less technical audience. We can trim 
+      back the presentation to focus it.
+    - **TODO** Sean to work with Mario on topics to present. Maybe Mark can 
+      similarly work with Matthias.
+    - Doug: There's nothing about an intro to OCIO in deck. Need to add that.
+    - Sean: Can use readme from website and GH as a start.
+    - Michael: Might be good slides for Mario and Matthias to put together, since 
+      they are presenting.
+    - Patrick: Would be good to have OCIO intro document in general, since it's 
+      something that doesn't currently exist.
+    - Carol: Some docs being made at Netflix about OCIO which could be shared.
+    - **TODO**: Carol will try to share some of the OCIO docs she makes. Thanks!
@@ -0,0 +1,43 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Jan 20, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Weta
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mario Rokicki - DNEG
+
+# **OCIO TSC Meeting Notes**
+
+* String utilities (PR #909)
+  - also have src/apps/apputils
+
+* python bindings (pybind)
+  - what are the default values?
+
+* Mission Statement (PR #890)
+  - Just waiting for CLA stuff from EPIC
+
+* PR #898
+  - Content merged via another commit. Going to close but will investigate CLA issues
+
+* Spark BOF
+  - Mostly students, so will treat more as intro to OCIO / color management
+
+* New Nuke behaviour
+  - Now OCIO colour management is the default, lots more colourspaces in menus
+  - Hopefully aleiviated by future hiding colourspaces feature
+  - No Foundry rep as of yet (now that Carl is at Weta). Carl will reach out to Foundry
@@ -0,0 +1,62 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Jan. 27, 2020
+
+Host: Michael Dolan
+
+Secretary: Patrick Hodoul
+
+TSC members:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Weta
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+
+Attendees:
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mei Chu - Sony Pictures Imageworks
+
+
+Apologies:
+  * Larry Gritz
+  * Mark Boorer
+
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF Planetary Meeting
+    - Michael: Doug & me are working on the OCIO slides.
+    - John: Would like to have them today if possible.
+       - Audience is mostly people investing in ASWF i.e. more business folks than devs.
+       - The content:
+          1. High-level presentation of OCIO.
+          2. What was done during the last 12 months.
+          2. What is planned for the next 12 months.
+    - Michael: Doug & me will do the presentation.
+
+* Still old license notices
+    - Patrick: We noticed some source files are not updated with the new copyright notice.
+    - Michael: In some src/apps files the license remains unchanged on purpose.
+
+* Pending PRs
+    - Michael: Will perform reviews.
+
+* Election
+    - Michael: Wait a full week before contacting John with the agreement. 
+    - John: Need to codify general rules for renewal and add them to the governance document.
+    - Michael: **TODO** I will have a look.
+
+* Foundry Representative(s)
+    - Carl: Foundry thinks about having 2 representatives.
+    - Michael: How to handle it?
+    - John: It could be done via one official Foundry representative and one personal registration
+            (i.e. TSC meetings are open to anyone) or by extending TSC to add more members.
+    - Doug: Highlights the constraint to have 'active' TSC members to avoid potential quorum blockage.
+    - John: How to best represent the community in the TSC membership?
+    - Michael: **TODO** Will answer to Foundry.
@@ -0,0 +1,75 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+February 03, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Carol Payne - Netflix
+  * [X] Mei Chu - Sony Pictures Imageworks
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF Plenary Meeting recap
+    - Michael and Doug gave brief (~5 minute) update to ASWF governing board, 
+      TAC, and stakeholders on Jan 30th.
+    - Overview of the project, the last year, and the coming year of development.
+    - Interesting discussion around how ASWF can support USD.
+
+* ASWF GSoC discussion
+    - Polled Slack for project ideas for ASWF's application to Google Summer of 
+      Code, and submitted PR to: 
+      `https://github.com/AcademySoftwareFoundation/tac/blob/master/gsoc/README.md`_
+    - In summary, four projects initially proposed:
+          - Add Metal, Vulkan, or CUDA language support to GPU renderer
+          - Restore Java bindings
+          - Add OCIO support to FFmpeg or another FOSS project
+          - Develop GUI for interactive OCIO config authoring and visualization
+    - The initial projects and mentors are for the application, but can be ammended 
+      anytime. Larry is submitting application on Wednesday.
+    - Larry: Mentorship involves guiding students, checking in, grading their 
+      contributions, etc.
+          - If we're admitted to GSoC, students will submit proposals for projects,
+            which could be something we've proposed, or something else.
+          - It's good to set a minimum threshhold of requirements for who to accept. 
+            For example, having students submit a trivial PR. Sorting through 
+            applications can take too long otherwise.
+          - Also good opportunity to find rough edges around building the library, 
+            having students submit fixes or issues for issues they encounter.
+    
+* Python bindings
+    - Michael: Resumed work on pybind11 bindings. Got everything up to date with 
+      master.
+    - Mei Chu (Imageworks) is interested in helping with this work, potentially 
+      designing unit tests to start.
+          - Mei: Looking forward to getting more involved in OCIO
+    - Patrick: Is any work needed to support binding work? RGB array class for example?
+          - Michael: For now I am planning to wrap everything as-is, but we can change
+            that later if it makes sense.
+          - The only issue in the API is the private destructor, which I'm making 
+            public.
+          - Mark: Not opposed to making the destructor public, but we might also want
+            to consider changing how the API managaes memory. It currently only 
+            supports shared_ptr. Most libraries don't impose this design like OCIO does.
+          - Patrick: Memory management is especially critical on Windows with dynamic 
+            libraries. We could consider other approaches.
+          - Mark: ColorSpace objects shouldn't always need to be managed by shared_ptr, 
+            for example. OCIO can control how to manage memory internally, but the API
+            could allow users to decide how to manage objects they create.
+          - The previous Python bindings were complicated by this too. Had to tie 
+            the lifecycle of Python objects to the config to prevent deletion.
+          - Michael: With the current pybind11 approach, changing memory management 
+            later wouldn't require a lot of reworking in the binding code.
@@ -0,0 +1,50 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+February 10, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mei Chu - Sony Pictures Imageworks
+
+# **OCIO TSC Meeting Notes**
+
+* ACES Config
+    - Michael will follow up with Sean about pinging the Academy again about our email.
+    - Doug: Do we need to keep the non-OCIO LUTs (they are huge)?
+        - Mark: Think we should keep them.
+    - Mark: Artifacts should not go in the repo.  Volunteered to look into a solution.
+
+* Python bindings
+    - Michael: Making progress on the bindings.  Pybind will copy arguments, is it an issue?
+        - Mark: Think it's ok for now.
+        - Doug: LutTransform getters/setters may be slow, but probably ok for now.
+    - Bernard: Would like to move from double* to RGB object/struct for arguments.
+        - Michael: Sounds good, perhaps leverage Imath types.
+        - Patrick: Is it header only?  Michael: No.
+    - Patrick: We want to avoid copies on the apply call.  
+        - Michael: Using numpy, like OIIO.  It avoids a copy.
+    - Michael: There are some list-related things we might want to drop, is it ok?
+        - Mark: Remove them.  There are other breaking changes, constants/enums.
+            Should investigate Python generators.
+    - Mei: Need someone to help with unit tests for Python?
+        - Michael, Doug: YES!
+    - Michael: There are so many PRs coming in, it's tough to keep the Python in sync.
+        - Patrick, Bernard, Doug: Sorry!  ;-)
+    - Patrick, Doug: Please merge what you have and then we will update the Python with our PRs.
+        - We will stick with double* API for now and switch to structs after the merge.
+    - Michael: OK to merge without unit tests, as a first pass?
+        - Group: Yes, those could be added in a separate PR.
@@ -0,0 +1,54 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+February 24, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+TSC members:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+
+Attendees:
+  * [X] Mei Chu - Sony Pictures Imageworks
+  * [X] Bernard Lefebvre - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+
+# **OCIO TSC Meeting Notes**
+
+* Google Summer of Code (GSoC)
+    - ASWF accepted.
+    - New faces already appear.
+    - Larry: Reiterate the need to request a pull request from students.
+    - Michael: Will post on ocio-dev to increase visibility.
+
+* Hollywood Professional Association (HPA):
+    - Link is https://hpaonline.com/hpa-tech-retreat-2020-main-program-lineup-announced/
+    - Doug: Audience mostly composed of managers & CTO's.
+    - Doug: Made a presentation about CLF during the ACES session.
+    - Doug: Made a presentation about OCIO during the open source session chaired by David Morin 
+            who talked about the ASWF.
+    - Discussion diverged to the topic of moving the OCIO Configs repo.
+        - Doug: Need to setup a meeting with ACES.
+        - Michael: Agreed.
+
+* SPARK FX Conference (Vancouver)
+    - Program http://sparkfx.ca/festivals/information.php?SPARKFX2020-C
+    - 'DIFFERENT STROKES & STRATEGIES FOR COLOUR' session:
+        - Link is http://sparkfx.ca/festivals/information.php?SPARKFX2020-C#20200216-C33
+        - Larry: Good presentation.
+
+* OCIOv2 Working Group:
+    - Doug: Planned this thursday.
+
+* Python Bindings:
+    - Doug: Thanks Mei & Michael to work on this topic.
+    - All: Agreed.
@@ -0,0 +1,57 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 2, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Carol Payne - Netflix
+
+# **OCIO TSC Meeting Notes**
+
+* Python binding update
+    - Currently working on ImageDesc classes, which interface with NumPy and 
+      any type with buffer protocol interface.
+    - Encountered issue with multiple PackedImageDesc objects initialized with 
+      different NumPy arrays overwriting each other's memory when their dtype
+      and shape matches. Could be a hashing issue on Python side. Copying array
+      on C++ side fixes it, but will continue to investigate.
+    - **TODO**: Michael to share link to source in branch for input.
+
+* Autodesk PRs ready for review
+    - Doug: Discussed work at last week's v2 working group meeting. If there's 
+      any questions, or more explanation needed, please let us know.
+
+* ocio-user question
+    - Patrick: A new user had question in ocio-user about how to get started. If 
+      someone has cycles, a response would be appreciated, even if just to point 
+      toward existing docs.
+    - [ocio-user thread](https://lists.aswf.io/g/ocio-user/topic/getting_started_with_ocio/71538664?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,71538664)
+
+* GitHub activity:
+    - Patrick: Responded to a new compilation issue #940
+    
+* GSoC:
+    - There continues to be GSoC activity. Need to make sure that prospective 
+      participants demonstrate the ability to troubleshoot and communicate 
+      problems they encounter while building, contributing, etc., rather than 
+      just wanting a quick solution.
+    - Michael: As far as interested students submitting a PR, do they need to
+      do that by the application timeframe, which is the later half of March?
+    - Larry: No, as long as they demonstrate the ability to contribute before
+      applications are reviewed by us, that is fine.
+    - Michael: OCIO, OpenCue, and aswf-docker have all had students express 
+      interest for GSoC, per last TAC meeting.
+    - Larry: OpenEXR has had activity now too.
@@ -0,0 +1,76 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 9, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mei Chu - Sony Pictures Imageworks
+  * [X] Carol Payne - Netflix
+  * [X] Robin Rowe
+
+Apologies:
+  * Kevin Wheatley
+
+# **OCIO TSC Meeting Notes**
+
+* Documentation
+    - Need to determine future doc goals and implementation.
+    - Doug: Autodesk team has looked at docs, finds reST and Sphinx to be 
+      cumbersome to edit, particularly when trying to predict how embedded
+      header docs will render.
+    - Many header changes have been needed to get docs to generate cleanly.
+    - Patrick: The doc build process is fragile, and not intuitive to setup
+      on Windows, because of Sphinx' dependence on Python.
+    - Doug: The PDF generation is problematic.
+    - Larry: OIIO dropped PDF "book" after moving to RTD. RTD itself can 
+      generate a PDF. It isn't as pretty, but works well enough, and the
+      RTD online docs are most useful.
+    - OIIO uses breathe to connect C++ doxygen docs to Sphinx, which works 
+      well. Doxygen has made some improvements, and is worth considering.
+      It may be compatible with reST now. Overall the ease of doc generation
+      outweighs any inconvenience.
+    - Doug: We should have some action steps to guide contributors. Rashil 
+      stood up RTD quickly and could continue the work.
+    - Patrick: We should set some guidelines based on our discussion to make
+      the work more concrete.
+    - Michael: Decoupling the doc build from the library build would be good
+      first steps, and an opportunity to improve the system. 
+    - **TODO**: Michael will discuss options with Rashil to see if he has 
+      interest in furthering his work.
+    - Doug: All of the docs need a bit of overhaul. For general docs, it 
+      would be great to crowd source within the community. Perhaps a wiki?
+    - Carol: Wiki is a great idea. There is a lot of knowledge in the 
+      community to contribute. Talking to ACES about similar work and would 
+      be happy to help investigate options.
+    - **TODO**: Carol will report back on Wiki investigation.
+    - Patrick: Thomas has a Wiki for colour-science. We could ask about his
+      approach.
+    - Doug: Is there any opinions about whether continuing to put docs in the 
+      header files is the right approach?
+    - Patrick: The downside is that the headers get a bit bloated, which could
+      make it harder to read.
+    - Michael: I like the docs in the header. It's a great overview of the 
+      interface, and iterates with the code. I wouldn't mind seeing more docs 
+      in OpenColorTypes.h, since some of the enum docs can be hard to find
+      in the source.
+
+* GSoC
+    - Patrick: Students are actively investigating potential projects. Now is
+      the time to help them and answer questions.
+    - They must propose projects in the later half of March, with two weeks to 
+      submit. We then have about a month to review applicants. Any guidance we
+      can give should be a priority.
@@ -0,0 +1,48 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 16, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Mark Boorer
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mei Chu - Sony Pictures Imageworks
+  * [X] Carol Payne - Netflix
+  * [X] Mitch Prater - Laika
+
+# **OCIO TSC Meeting Notes**
+
+* Pull requests that need review.
+	- Anyone with experience with UI/UX there is a pull request for the DCC helper library
+	- GSOC applicant feedback
+	- Proposed display referrence space feedback PR #957
+
+* Python bindings are pretty much done, just need to find a good time to rebase on top of interface changes
+
+* GSOC
+	- Lots of applicants, they need feedback, but they should also be doing some of the investigation work themselves
+
+* Supported architectures?
+	- OpenColorMath has a JIT that is hand tuned for x64.
+	- Do we have a minimum requirement for platform architecture? x64? ARM?
+	- The USE_SSE flag could help, as it already imposes a requirement for SSE2
+
+* Documentation
+	- What are we looking to do to improve?
+	- Introduction of a OCIO Wiki. There are some solutions out there, eg MediaWiki / DokuWiki, that could be added to the OCIO website.
+	- The built in github tools also add a user friendly layer (which translate wiki edits to pull requests).
+	- Docs that are part of the repo (vs a detatched wiki) can also be versioned with the code, so users never see outdated or incorrect documentation.
+	- Linux Foundation? ocio_dev and ocio_user have wiki's as well (but require registration).
+	- We should try to consolidate all of these wikis too
@@ -0,0 +1,80 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 23, 2020
+
+Host: Doug Walker
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Mei Chu - Sony Pictures Imageworks
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Michael Min - Netflix
+  * [X] Carol Payne - Netflix
+  * [X] Rashil Gandhi - student
+
+Apologies: Michael Dolan
+
+# **OCIO TSC Meeting Notes**
+
+* Google Summer of Code Proposal about Ffmpeg
+    - Doug: Michael, Patrick, and I are working with Rashil Gandhi on his GSoC proposal
+        which is to add OCIO support to Ffmpeg.  Do people think that is enough work
+        for a 3 month, 40 hour/week summer project?
+    - Mark, Kevin:  Probably.  Adding it as a video filter should be very do-able although
+        trying to add it to the core may be a big task.  Also, keep in mind it is C, not C++,
+        and the dev process is via patches to the email forum rather than GitHub PRs.
+        Also, their community expects strict adherence to their communication style.
+        It may take awhile to get the code approved, especially if it is to the core lib.
+        They have their own fork of OpenEXR to allow access from straight C.
+    - Larry: There is some inherent uncertainty in the amount of work but it should not 
+        prevent moving forward with a proposal, we can suggest other tasks if it turns
+        out to go faster than expected.
+    - Rashil: (Via chat) For some reason my microphone isn't working. 
+    - Rashil: I can probably work on making the versioned documentation too, if the FFmpeg 
+        project is too small :)
+    - Larry: We should reach out to the ffmpeg community to line up someone to advise.
+    - Doug: Is there another OSS project that people would suggest Rashil work on that
+        would be even better than Ffmpeg?  
+        - Group: Ffmpeg is widely used at our studios today and we still think it would be
+          a great project.
+    - Carol: What other tools in Ffmpeg are needed, could EXR images be scaled and cropped?
+    - Larry: We should solicit input from those at our studios that work with Ffmpeg to
+        get input on the workflow and any gotchas.  (Mei, Mark, and Kevin all raised their
+        hands as being active users.)
+    - Doug: The GSoC proposal needs to have a proposed schedule broken down into milestones
+        and we need to give pass/fail marks at the end of each milestone.  How should we
+        approach this given the uncertainty in how much time it will take.
+    - Larry: We can use our best judgement.  As long as the student is making good progress
+        we are able to pass them even if it is not exactly what the milestone proposed.
+    - Mark: The core library does not support float pixel types.  Also it is very limited
+        in what types of EXR images may be read (e.g. looking for a specific channel layout,
+        no multi-part support).
+    - Kevin: A quick scan of the EXR codec shows it only really outputs 16 bit RGB, RGBA, YCbCr.
+         https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/exr.c#L1691 
+        - Mark: Is that integer 16 bit? 
+        - Kevin: Yes, integers.
+    - Mark: One approach would be to make video filters for OCIO ColorSpaceTransform and
+        OCIO DisplayTransform, similar to the tools in Nuke, etc.
+
+* Documentation
+    - Doug: Any updates/thoughts from anyone on efforts to improve the documentation?
+    - Carol: I will try to find time to look into wiki options some more.
+    - Doug: Should I enable GitHub Wikis on our OCIO site to enable experimentation?
+        - Group: Yes.
+
+* GSoC Mentoring
+    - Larry: If you are interested in being a GSoC mentor, make sure you sign up.
+        - Doug: I may have missed the email.  Note: I found it and signed up.  Thanks Larry!
+        - Patrick: I'm already signed up.
+    - Doug/Group: Thank you Rashil for joining the meeting today!
@@ -0,0 +1,68 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+March 30, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Carol Payne - Netflix
+  * [X] Mei Chu - Sony Pictures Imageworks
+
+# **OCIO TSC Meeting Notes**
+
+* Python bindings
+    - PR #976 ready for review. The API has changed from previous bindings, so 
+      any feedback is appreciated.
+    - Michael: Wondering about best approach for Python docs. Use previous 
+      mechanism or embed docs in pybind11 bindings?
+    - Patrick: The Python API differs from C++ enough that having separate 
+      documentation will be important to address differences. Keeping it in the 
+      code seems like a good solution.
+    - **TODO**: Michael will add docs to binding code in a future PR.
+
+* GSoC update:
+    - Tomorrow is the proposal deadline. There are quite a few proposals to review.
+      How many projects should we expect to accept?
+    - Larry: It depends on the applications. We will pair applications with mentors
+      and submit them to Google in a ranked order. Google will then tell us which we 
+      get. Since ASWF is applying together, the project leaders will need to discuss
+      between all applications and decide together. In the past I have usually gotten
+      all the applicants requested; 3-4.
+    - Doug: There is a propsal to update the Java bindings which could use a review
+      from someone who knows Java.
+    - Larry: We can also enlist someone from outside the project to help. That person
+      doesn't need to be the mentor.
+    - Michael: Someone from OpenCue may be able to assist with guidance for Java CI.
+    
+* Documentation / wiki:
+    - Doug: I enabled the GH wiki feature last week. Any thoughts on adding some 
+      project docs via the wiki?
+    - John: It depends what you are documenting (internal or external processes, 
+      policy, etc.), and also on who is maintaing it. More and more projects are
+      using GH for everything, all in markdown. If the topic is how to use OCIO; 
+      that's different from documenting how the TSC works.
+    - Doug: We want a way for end users who are maintaining configs to share their 
+      experience without having ot make a PR. Tips, tricks, etc.
+    - John: A GH wiki is version controllable, but may require higher-level 
+      permissions changes. Just consider the level of curating that will be needed
+      to keep a wiki from getting unwieldy. We can also talk about other tools 
+      which sit on top of GH to make editing rich text simpler.
+    - Carol: What does ASWF use for a wiki, if anything?
+    - John: We don't have a wiki currently; just a designed website and GH repo 
+      with lots of process documentation. We see a lot more projects moving away
+      from wikis since they can become hard to curate and maintain over time, 
+      and technical docs are easier to derive from code. It's important to look at 
+      what the process and tools are for maintaining the chosen solution.
@@ -0,0 +1,72 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+April 6, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Mei Chu - Sony Pictures Imageworks
+  * [X] Carol Payne - Netflix
+  * [X] Mitch Prater - Laika
+
+# **OCIO TSC Meeting Notes**
+
+* Google Summer of Code
+    - Larry: Need to discuss the OCIO proposals and rank them.  Proposals from all the ASWF
+    projects will get merged into an overall list that we will use once we find out from
+    Google how many slots we will get.
+
+* Moving CI to GitHub Actions
+    - Michael: At the ASWF CI meeting last week there was a good discussion on getting the
+    GPU CI going.  JF and Andy are going to help with that.  For various reasons, we first 
+    need to move our CI from Azure to GH Actions.  I volunteered to do that over the coming
+    weeks.  Do we want to make any platform/compiler changes to our matrix while doing that?
+    - Patrick: Let's start by just moving the current configuration over.
+    - Patrick: As Python support is important for OCIOv2, let first complete/merge the Python 
+      Bindings PR if agreement so others could jump to add unit tests, documentations, etc.
+    - Michael: There was also a question at the meeting about whether Sonar Cloud is valuable.
+    - Patrick: It did find bugs, so it has value, but there is also a lot of noise.
+
+* Python bindings
+    - Michael: The PR on GitHub now has full coverage of the API.  Needs help with documentation
+    and unit tests.  I will be working with Mei on the latter.  Please provide feedback on the PR.
+    Thanks for the comments so far from Patrick and others, it has been helpful.
+    - Doug: I still need to review.  Let's try to merge at the end of the week.
+
+* Contributing to OCIO v2
+    - Michael: The target for feature complete is approaching (SIGGRAPH), what areas would 
+    be most helpful for people to help with?
+    - Doug: The Python bindings were a huge help!  Documentation would be the next item on
+    our list, and updating the website.  Getting a few volunteers to help write documentation
+    would help ensure that it is understandable outside the people who wrote the code and
+    would also allow us to share detailed knowledge about what's in v2 with a few more people.
+
+* Documentation Infrastructure
+    - Michael: Sean, you were looking at this awhile back, is it something you could help with?
+    - Sean: Yes, I could contribute.
+    - Michael: Also, Carol has been looking at this more recently.
+    - Carol: Yes, I started looking at the Wiki on GitHub.  It is very simple to edit but we
+    may want to put some access control in place.
+    - Kevin: Yes, there is a way to do that.
+    - Mitch: I've used the GitHub Wiki.  One drawback is that it is separate from the code
+    so a workaround is needed to have separate content for different versions.
+    - The group discussed and there was some agreement that it might be nicer to have all
+    the documentation together in a single site.
+    - ACTION ITEM: Carol and Sean will work on ideas for upgrading the documentation system.
+
+* No meeting next week
+    - No meeting next week (April 13) since it is a holiday in some areas.  Also, we really
+    need a break to stay home and watch more Netflix!  ;)
@@ -0,0 +1,108 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+April 20, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Larry Gritz (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Carol Payne - Netflix
+  * [X] Mei Chu - Sony Pictures Imageworks
+  * [X] Shakeel Muhammad
+
+# **OCIO TSC Meeting Notes**
+
+* PRs for review
+    - Michael: There are two Autodesk PRs waiting for review.
+    - Doug: One is related to op finalization (#986). We looked at how ops 
+      are finalized prior to evaluation, including optimization steps, 
+      converting inverse LUTs into forward LUTs, etc. There was some 
+      unnecessary cloning of ops.
+    - Patrick: We discovered cloning and slow downs in optimization and 
+      finalization and fixed them. Lots of changes, but only fixes. Some ops 
+      can have a processing cost at finalization, and we tried to avoid that. 
+      There are no high level changes; only internal processing improvements.
+    - Doug: For example, if you need a CPU and GPU processor, this reduces the 
+      necessary work  to support that.
+    - Patrick: Very important for integrating OCIO into DCCs, to limit 
+      performance impact.
+    - Doug: The PR feels big since it impacts all ops, but the changes are 
+      similar for each.
+    - Doug: The other PR refactors GPU usage in apps (#985). We wanted to allow 
+      CPU and GPU evaluation in apps and utilities without copying/pasting a 
+      lot of code, so this PR improves reuse between tools.
+    - Patrick: It also improves commandline tools to offer good usage examples 
+      for the library, which is important for DCC integration. It's part of 
+      ongoing improvements in this area.
+    - Bernard: It helps avoid copying and pasting code.
+    - Michael: PR #991 is ready with GH Actions support. GH Actions is fairly 
+      similar to AZP, but doesn't have all the same capability. It doesn't offer
+      template capability yet for example. GH Actions does work in OCIO forks 
+      though, which expands usage quite a bit. To use in your fork, you'll have 
+      to temporarily add your feature branch to the included push branch list.
+    - Michael: PR #890, which adds our missions statement to README.md is out of 
+      draft now and ready for further review.
+
+* Documentation updates
+    - Sean: I've looked at static site generators, but don't think they serve our 
+      needs well. I recommend continuing forward with Sphinx. It's widely used and 
+      works well.
+    - I noticed there are no docstrings in the Python bindings yet. An interesting 
+      solution to consider is what was done for Matsuba, another project from the 
+      pybind11 author. It rips docstrings from cpp headers and injects them in the 
+      bindings, so documentation exists in only one place. It's a good source of 
+      inspiration, but could be good to have dosctrings in bindings still, for 
+      dicoverability.
+    - Our doc needs are varried; there's the website, docstring extraction, etc. 
+      Nothing out of the box works with multiple languages. Overall, our docs don't 
+      fit anymore, and need work. I will work with Carol on a plan, and to come up 
+      with user stories.
+    - Much later down the road, it would be nice to collate collective studio 
+      experience for reference. It's nice to see what studios are doing, and what 
+      systems they have built around it. Case studies would be great, including from 
+      other industries like Netflix.
+    - Carol: I agree, and will work with Sean on this.
+    - Sean: I will make GH issues to break down tasks further.
+    
+* String locale handling
+    - Doug: PR #984 is about fixing string case handling for Turkish locale. This 
+      raises bigger case sensitivty issues. File extensions should be case 
+      insensitive for example.
+    - The proposal is to convert case as if it were english case, so that locale wouldnt 
+      matter. Two questions we need to answer. Do we want case sensitivety to depend on 
+      locale? Secondly, what areas of the library should use case-insensitive comparison?
+    - We do case insensitive compares in places that might be unncessary. Color space 
+      names, role names, etc. Anywhere Lower() function is used.
+    - Mark: Roles should be case insensitive. Traditionally color space names too. File 
+      names should be dependent on filesystem and OS behavior. it's a tough question 
+      though. Unicode can complicate matters.
+    - Doug: Do people use non-english chars in configs?
+    - Mark: Not in my experience, but they could.
+    - Doug: The bug the PR is fixing is related to the .spi1d extension, due to the 
+      Turkish local using "I" instead of "i".
+    - Patrick: There are no round trip ways to do this. Extensions are only US letters, and 
+      we know what extensions we support.
+    - Mark: Filenames should never need a conversion. We dont want to abstract away from 
+      filesystem behavior. Use whatever it supports. Only FileTransform and CDLTransform take 
+      file names, and shouldn't depend on text lookup.
+    - Doug: When looking for color space name in filepath, it gets complicated.
+    - Mark. Can we remove the extension from a filename before a color space check? Unless 
+      there's a file extension specific color space name.
+    - Doug: The PR is proposing comparisons ignore locale, and instead have 
+      them behave as if always english. Not a bad thing to remove locale, as it removes a 
+      variable of complexity, but it needs discussion to agree on a solution.
+    - Michael: Let's continue that dsicssuion offline in the PR for now, since there is a 
+      good conversation happening there.
+    - Doug: We are happy to discuss it further later if anyone wants as well.
@@ -0,0 +1,36 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+April 27, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Larry Gritz - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Carol Payne - Netflix
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+
+# **OCIO TSC Meeting Notes**
+
+* Build System:
+    - Michael: Works on the CI build using GitHub Actions.
+               Will submit a PR with the AWSF 2020 docker.
+               Rework the worflow to have one build for the library and one for the static anlysis,
+               latest builds, etc.
+
+* Various topics:
+    - Carol: Waiting feedback on the Wide Gamut proposal from the community including OCIO.
+    - Doug: PR is coming to organize all the CLF test files from OCIO to share with others.
+    - Doug: ACES webinar this week explaining the new realese of ACES 1.2.
+
@@ -0,0 +1,131 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+May 4, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Joseph Goldstone - ARRI
+  * [X] Troy Sobotka
+
+# **OCIO TSC Meeting Notes**
+
+* GPU CI update
+    - GH Actions is now in place, and LF release engineering is working on 
+      setting up needed AWS infrastructure to provision GPU instances. Once 
+      this is completed (within ~1-2 weeks) we will work with JF to implement
+      into CI. A CI working group goal is for OCIO to have GPU CI up and running
+      by the May CI working group meeting in a month.
+
+* OpenColorIO-configs update
+    - There was a joint ACES-OCIO meeting last Friday to discuss the way 
+      forward for the ACES OCIO config. We will be starting a new ASWF repo to
+      house a new config, and further discuss the design within that repo's 
+      issues.
+    - Doug: Rod Bogart has some action items around licensing of existing code 
+      and HP's python scripts. TBD how to move forward with these.
+    - Joseph: Did anyone from Canon come to this group? The current IDTs dont 
+      match Canon's white paper. It contains a note saying the formula has been 
+      revised.
+    - Doug: That's more on the ACES side to get that updated. It should be 
+      mentioned to Alex and Scott. We're just going to follow what is in their 
+      repo.
+    - Joseph: I will reach out to them via email.
+    - Sean: The tricky part will be what to do with old stuff. Also the 
+      particulars of the config. But path forward is clear. It would be 
+      worthwhile to investigate a chair to oversee config maintenance and to 
+      have a clear owner - whoever has the time and detail.
+    - Mark: That person could also own the numbers in the config, which 
+      sometimes are debated.
+    - Doug: Thomas Mansencal and Michael Parsons are the people that are 
+      currently tasked by the Academy as the maintainers of the config, and 
+      Thomas has done a great job on the ACES 1.2 config. My impression is 
+      that ACES would like OCIO to take a bigger role in the management of the 
+      config, similar to a product partner, but hopefully the same people will 
+      stay involved.
+    - Sean: The owner can ensure the config is up to date, and handle opinions 
+      about community configs.
+    
+* Docs
+    - Sean: I've been exploring the docs and have a rough working copy. Able to 
+      populate docstrings from C++ headers automatically. pybind11 provides 
+      tooling to extract doxygen style comments from headers and exposes a 
+      macro to pull them into python bindings at compilation time. Seems 
+      designed to document python bindings only - no comments about C++ at all. 
+      Will be Interesting to see if both Python and C++ can be documented from 
+      the same source.
+    - Ideally the documentation will just live in the headers, but will need 
+      work to be explicit API docs, instead of lots of explanatory text. This 
+      will be needed sooner than the main OCIO v2 release. After the call with 
+      ACES it was clear there should be a sense of urgency in getting 
+      documentation going.
+    - Once general docstrings are in place, we can discuss how to structure 
+      docs and website. The current structure is not logical. The bulk of the 
+      work will having to describe things beyond API docstrings.
+    - Doug: The sooner we have a template the better. The AD team can then help 
+      fill it in places. A template within the month would be very helpful.
+
+* Logos
+    - LF creative services is helping redesign an OpenEXR logo. For OCIO 
+      branding should we do the same, or reach out to the OCIO community for 
+      ideas?
+    - Carol: Using LF would bring consistency between ASWF projects. Related 
+      projects with different designers tend to look ad-hoc. Not bad, but 
+      something to consider.
+    - Sean: Would be nice to get the O*IO project branding aligned.
+    - Doug: If anyone knows designer to work on it, we could get some ideas to 
+      give to LF as a starting point. 
+    - Sean: I can ask Mario if he has ideas, since he proposed some previously.
+    - Patrick: It's a good opportunity to update the logo at the same time as 
+      the library.
+    - Carol: There could also be packaging and tweaks to work for different 
+      uses.
+    - Doug: LF can design different flavors of logo like they did previously 
+      with OCIO typography.
+
+* Python unit tests
+    - Doug: Python unit tests are needed soon. It would be great to get a PR 
+      to set guidelines and establish the implementation. This could just be 
+      for a small portion of the library, to be followed by other PRs.
+    - Mei: I made some changes to two Python test modules, which Michael 
+      reviewed in his fork. Can keep working on it to get a good template we 
+      can use across project.
+    - Patrick: Don't try to write them all; it's more so we can see next steps. 
+      When CI moved to GH Actions, the bindings are compiling but not running. 
+      Unit tests are needed to make sure it is working.
+    - Doug: We also need some new good first issues for the project. There 
+      aren't many good first issues there now. Python unit tests could be 
+      included.
+
+* Built-in transforms
+    - Doug: More built-in transforms will be needed, and could be contributed 
+      by the community once the current PR #1006 is merged.
+    - Mark: I was hoping to have OpenColorMath in before going too far with 
+      those.
+    - Doug: It depends on when that would go in. When we get to doing v2 
+      configs, we need examples of how to make ACES output transforms. This can 
+      be an area for community contributions.
+    - Mark: There will still be work to do once library is feature complete. 
+      I will take a deeper look then to help refine before a final release 
+      later in the year.
+ 
+* Important items for community contribution over the next few months:
+    - GPU CI
+    - OpenColorIO-Configs
+    - Documentation / branding
+    - Python unit tests
+    - Built-in transforms
@@ -0,0 +1,70 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+May 11, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [x] Michael Dolan (_TSC Chair_) - Epic Games
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carol Payne (_TSC_) - Netflix
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * Joseph Goldstone - ARRI
+  * Bernard Lefebvre - Autodesk
+
+Apologies:
+  Sean Cooper
+
+# **OCIO TSC Meeting Notes**
+
+* Videos for OCIO
+    - Michael: Emily Olin (ASWF PR director) is hoping to help us develop some videos explaining 
+      and demonstrating OCIO, and is looking for studios who can contribute recent images, videos, 
+      breakdowns etc. that could be used within that. If any of you have some content you could 
+      clear, let me know and I can put Emily in contact with you.
+    - Michael: I was able to get a few things cleared when I was at Sony, but it would be great to 
+      get some new content in addition to that.
+    - Mark: I think anything from our YouTube videos should be available.
+    - Carol: We have been working with some international studios and may be able to get something.
+    - Michael: It's a nice opportunity for a studio to show public support for OCIO.
+    - Doug: We're thinking of maybe having two videos: one is an overview introducing what OCIO is,
+      and a second that is specifically about the new features in OCIO v2.
+    - Michael/Doug: It would be nice to have some images from a recognizable movie that are in
+      different color spaces to help with the explanations.
+
+* OCIO Configs Repo
+    - Michael: If anyone has any objections to me getting the ball rolling with getting an 
+      OpenColorIO-Config-ACES repo set up under ASWF GH org, please let me know. We can rename it 
+      later, but I would like to start some momentum on that effort. We can hold off on any other 
+      config repos for now, but the ACES one seems pertinent to get going.
+    - Michael: We would like to have a v2 example config in place by SIGGRAPH and need to start now 
+      to avoid a last minute rush.
+    - The TSC expressed support for that plan.
+    - There was some discussion about whether this would be useful for OCIO unit tests since the
+      existing tests build "toy configs" on the fly rather than real configs.  However the group
+      felt it would be difficult to leverage this for several reasons including the fact that it
+      is in a separate repo and also changes to it might break tests.  Also, we are trying to
+      minimize the number of external files the unit tests require.
+    - Micheal: On the topic of unit tests, it might be cool to use Github Actions CI to do some
+      testing where images are processed and compared to reference images.
+
+* Documentation
+    - Doug: We are just over two months from feature complete, we need to start updating the 
+      documentation as soon as possible.  It sounds like we have a lot of agreement about wanting
+      to refresh the landing page, restructure the documentation, etc. but if we don't get that
+      in place soon we may be stuck having to just update what is already there.
+    - Carol: Sean has been working on a solution for the docstrings and we have had some
+      discussion on other aspects.  I will try to block out some time to work on a list of items
+      that will need to be addressed. 
+    - Carol: There are a number of tasks involved in making the refreshed landing page: a nice 
+      design, making it mobile friendly, doing the SEO work, etc.  Could the Linux Foundation help?
+    - Michael: Yes, we should reach out to Emily about that.
@@ -0,0 +1,119 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+May 18, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Joseph Goldstone - ARRI
+  * [X] Troy Sobotka
+
+Apologies:
+  * Patrick Hodoul
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* Documentation
+    - [Public working document, by Carol and Sean](https://docs.google.com/document/d/17IQR2tRYxqGXkExOLvP9S_dMkOkOID-NIIAGXGfyxNk/edit?usp=sharing)
+    - Carol: Document is a first draft. Went through existing documentation 
+      to outline what's there, and thoughts around it. The rest of the doc has 
+      examples and info on static site generators, themes, etc. Sean added a 
+      proposed plan of attack for getting the work started.
+    - Doug: Good focus for the discussion. Thanks for putting it together!
+    - Carol: Putting it all down is good for establishing priorities. Some 
+      items can happen concurrently, but some first steps are needed.
+    - Sean: First two points to decide on are the look and a static site 
+      generator.
+    - Carol: If there was a time to change things, it is now. We could go a 
+      different direction if needed.
+    - Michael: Many of us have expressed an openness to Sphinx alternatives if 
+      something else makes more sense.
+    - Sean: Trying to find the best solution. Three options seem to be: Write 
+      everything by hand, use an auto-generation tool, or be stuck in some 
+      middle ground of building your own tooling.
+    - Carol: Looked at [Jekyll](https://jekyllrb.com/); has best integration 
+      with GH pages, which would make it easy to use. I've never used 
+      [Staticman](https://staticman.net/), but that looks like a good 
+      integration which takes a static site and can add forms, tables, etc., 
+      which trigger auto-rebuild or generation of issues, PRs, etc., which is 
+      nice. Might be other tools, but these looked cool, to keep functionality 
+      on website, but with GH handled changes.
+    - Sean: My initial thinking is that most of the world knows Sphinx, so it 
+      could be picked up by anyone. The more obscure you get, the harder it is 
+      for others to pick it up. Could have one build for static site, and 
+      another for API docs. One option is to use a 
+      [VuePress](https://vuepress.vuejs.org/) website, and then RTD could use 
+      the VuePress theme to house API docs.
+    - Carol: I'm going to try and build some stuff locally to test.
+    - Michael: We could reach out on Slack and in ocio mail lists for community 
+      input.
+    - Carol: I can reach out. The bulk of work will be rewriting the user guide.
+    - Sean: I added points to end of doc around documentation and its 
+      organization. Asked the question, "who is the end consumer?", and called 
+      out 4 groups: artists, studio config maintainers, studio TDs 
+      (troubleshooting OCIO integrations), and OCIO integrators. Who is the 
+      target, and who do we focus docs on? Maybe all?
+    - Carol: A lot of it can hopefully be to work with DCC vendors to help them 
+      update their docs as well, and to understand coming changes. Then we can 
+      point our docs to theirs.
+    - Michael: The [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/docs/CompatibleSoftware.rst) 
+      page of the OCIO website was updated recently and contains many 
+      up-to-date documentation links.
+    - Doug: Also may want to add OCIO developers to the list of consumers, to 
+      orient them to the code base.
+    - Joseph: that would be great. Also a 6th group: people submitting 
+      transforms to a config. Camera manufacturers, etc. What are procedures 
+      for contribution? How to provide test cases?
+    - Carol: Contributors is a block in there, and different contributor types.
+    - Sean: We should also work on documentation for configs we provide. That 
+      was something provided previously for the SPI configs: user case studies, 
+      etc. Those docs should live in config repos, and the main docs could 
+      point to the config websites.
+    - Carol: Ideally they use the same process as the site
+    - Doug: Config docs would be simpler, with no API generation.
+    - Michael: At the next TSC meeting we can reconvene to discuss further, with 
+      community input received this week.
+    - Sean made #docs channel in Slack, and will add all TSC members as Slack 
+      admins.
+    - **TODO**: Carol will get documentation conversation started by posting 
+      document in #docs channel as ocio-dev (possibly ocio-user too).
+
+* [OpenColorIO-Config-ACES](https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES)
+    - Michael: This repo has been created and the committer group is being 
+      setup, which will include current active OCIO committers, plus Thomas 
+      Mansencal and Michael Parsons. Sean, are you ok with the multiple repo 
+      approach? I know you've expressed other approaches too.
+    - Sean: Multiple repos are ok. The use case that convinced me was ability 
+      to version up and generate artifacts independently for the configs.
+    - General agreement that the ACES config is the best place to start, and 
+      other configs can be explored/discussed later.
+    - Michael: I added one issue to the new repo to discuss formation of a 
+      config working group, which can determine next steps, and decide on a 
+      chair.
+    - **TODO**: Michael to make initial PR with LICENSE, etc.
+
+* PR #1011
+    - Doug: CLF-specific PR up and ready for review, with changes from the CLF 
+      ACES working group. Would like to get it merged by tomorrow for the next
+      working group meeting.
+    - Michael: I will review today.
+    - No voiced objections to merging it.
+
+* Items for next TSC meeting agenda:
+  - Next week is a holiday in US and UK. Group can still meet to discuss 
+    documentation if there is interest, otherwise we can skip and keep
+    the conversation going in the new #docs Slack channel.
@@ -0,0 +1,159 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 1, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Troy Sobotka
+  * [X] Joseph Goldstone - ARRI
+
+# **OCIO TSC Meeting Notes**
+
+* OpenColorIO-Config-ACES first steps
+    - Michael: Thinking of setting up a meeting to discuss a starting point. Do 
+      we feel that a working group would be good for oversight?
+    - Sean: Could use oversight of technical maintenance, and of what goes into 
+      the config; architecture vs implementation. Need to decide who owns the 
+      decision making. OCIO or ACES?
+    - Michael: In previous discussion Academy preferred OCIO ownership, but 
+      they were happy to guide.
+    - Sean: Need to discuss topics like: should the config have 300 color 
+      spaces or 20?
+    - Doug: It's an Interesting issue. There are cameras in there that perhaps 
+      should not be there. A group can discuss what the config should be. 
+      General VFX config? Or implementation of ACES?
+    - Joseph: Should known broken transforms be weeded out or fixed? Can 
+      someone at Canon confirm the transform is right? Could be a discussion 
+      with ACES.
+    - Carol: Would be useful to have someone from ACES involved.
+    - Doug: From the previous conversation, we would become a product partner, 
+      and ACES is involved through that. Partners will meet at events to 
+      discuss how things are going. Somewhat hands off so far, and they 
+      generally want external organizations to manage it. There's no active 
+      certification process to test IDTs, etc. Up to product partners to own 
+      their implementations.
+    - Michael: Does the ACES logo program have a validation process?
+    - Doug: There is a test kit, with a list of categories for levels of 
+      certification; for grading software vs. a camera, for example. The test 
+      kit had CTL and CLF files, etc. It may not be completed, due to ACESclip 
+      being incomplete? 
+    - Michael: For validation it would be great to have CI with verification of
+      config against ACES test images. I would be interested in contributing 
+      this if there's need.
+    - Doug: There are some issues with some ACES reference images that don't 
+      match CTL. I support the need to have a group meet and oversee these 
+      configs.
+    - Carol: Perhaps we can have an ACES Central partnership; a dedicated place 
+      to talk and participate? ACES sometimes get blamed for problems with 
+      implementations. We need to be partners.
+    - Michael: They did express the desire to partner with OCIO. ACES just 
+      wouldn't own the code.
+    - Sean: Should we tease apart the concept of an ACES config? It's really 
+      more of a workhorse config for the industry currently. Studios grab it 
+      and use it. Different configs have different needs. Just an ACES config
+      would be smaller and more straightforward. We should get a sampling of 
+      users; pull them into the conversation. It's not just about ACES and 
+      OCIO, but about helping the community with color management.
+    - Troy: The current config has some scripting implement already.
+    - **TODO**: Michael will work on getting a meeting schedule with interested 
+      parties.
+
+* Keeping track of OCIO v2 TODOs
+    - Michael: Proposal to use GitHub Projects for _some_ task management:
+        - [GitHub Projects](https://github.com/AcademySoftwareFoundation/OpenColorIO/projects)
+    - Doug: OpenEXR has a discussion on that too, for the Imath work. People 
+      have been supportive for using it.
+    - Carol: Agree this would be a good place to track and split up work.
+    - Doug: Documentation is the highest priority. Would like to have something 
+      up and running at OCIO v2 launch time. That was going to be at SIGGRAPH, 
+      but we still need to decide on a date. It could also be at DigiPro. This 
+      is coming up quickly. I feel an urgency for getting something in place 
+      where people can contribute to docs.
+    - **TODO**: Michael to explore setting up GH Projects to help keep track of
+      initiatives and priority.
+
+* Documentation status update
+    - Sean: Community feedback was fairly quiet. Started slack channel for 
+      further discussion.
+    - Doug: Ben replied to the post with good ideas.
+    - Carol: Some replies from people interested in following along and others 
+      with some ideas. Not a ton of response. I will go back and continue 
+      research, and meet with Sean offline to establish a proposed plan for 
+      implementation.
+    - Sean: Agree. My intent is to get PR in this week with a hosted GH page to 
+      look at something and talk specifics. Can currently compile docstrings 
+      from C++ headers and use with Python docstrings. I've been reformatting 
+      C++ headers and making them doxygen compatible. Once the implementation is 
+      worked out it will become a conversation about structure and what to fill 
+      in.
+    - Sean: General question: Since Python and C++ docstring largely use the 
+      same text, should we use abstract API docs? These could pull out 
+      specifics about implementations, and can be manually written where needed.
+    - Michael: I have seen other API docs that will use tabs for specific 
+      language implementation. The C++ docs also do this for different C++ 
+      standards.
+    - Doug: Sean's doxyfy prototype had tabs for languages. 
+    - Sean: It looks funny in VuePress, but could be fixed with CSS. My vision 
+      is to have a generic description with language notes. I will try to do a 
+      demo at the next meeting.
+    - Doug: We could set up different time for a focused discussion on docs if 
+      needed too.
+    - Sean: Might be more people with thoughts, like Ben.
+    - **TODO**: Sean will get mechanical part of docs working and can arrange 
+      additional meeting from there.
+    - Michael: Others can help once structure is in place.
+    - Sean: Doxygen generates headers with string literals. Not sure if we 
+      should be committing auto-generating headers to the repo, or let them be 
+      generated as part of the build process. It would need to be rebuilt 
+      every time.
+    - Mark B: Better to do this in the build system. The Existing repo has the 
+      same concepts for generated code.
+    - Sean: It needs to be there for python bindings to be built.
+    - Mark B: CMake can have target dependencies to make sure build order is 
+      correct.
+
+* Foundry SDK usage in CI?
+    - John: We had a discussion around Foundry SDKs and CI build processes a 
+      while back. Is this still something needed? I'm working with legal to 
+      make an agreement with companies to allow SDK use in the build stack. 
+      This topic was restarting to help with some needs on OTIO.
+    - Mark B: There was a discussion on who would maintain the OCIO Nuke 
+      nodes, but that conversation stopped. OCIO v2 scratches a lot of their 
+      itches, so they chose to wait and see.
+    - Mark T: Foundry would like to take ownership of the Nuke nodes and open 
+      source them.
+    - Mark B: The nodes are already open source. New versions could be 
+      contributed there.
+    - Mark T: True. We want to have more involvement with development of the 
+      nodes. Nuke would be a requirement for the build process. Pete and I 
+      will discuss how to proceed.
+    - John: The topic with legal is for terms around SDKs for open source use, 
+      so that ASWF projects could leverage these. Both of these projects are 
+      good example use cases to develop that. 
+    - Michael: If nodes came back into repo, CI would be needed, so that would 
+      be useful.
+    - Doug: CI currently doesn't build any plugins. Possible that core changes 
+      could break plugins without us knowing.
+    - Mark T: We tried building the Nuke nodes against OCIO v2 recently and 
+      weren't able to.
+    - Michael: There have been quite a few API changes.
+    - Mark T: We are not against contributing the nodes to the main project for 
+      hosting.
+    - John: I will follow up on discussions with Foundry. We are going through 
+      SDK terms and conditions.
@@ -0,0 +1,122 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+Jube 8, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+# **OCIO TSC Meeting Notes**
+
+* Move OCIO Slack to LF organization to ease sign-up?
+    - Michael: Emily and John reached out about the possibility of moving our 
+      Slack channels to the ASWF Slack workspace. I didn't think we would want 
+      to merge with their workspace since we have many active channels, but 
+      John proposed that if we moved our existing workspace to the ASWF 
+      organization, LF could setup self-sign-up, to make the space more 
+      publicly accessible. Thoughts on that?
+    - TSC agrees that sounds good.
+    - Sean: Do they have paid access? Would be good to not have message limits, 
+      since we are losing discussion history now.
+    - Carol: Can the existing discussion be migrated?
+    - **TODO**: Michael will follow up with LF for more details of their Slack 
+      account.
+
+* OCIO docs discussion
+    - Carol: We are going to meet to discuss structure and writing of docs. 
+      Maybe discuss in v2 working group?
+    - Doug: Time can be made available, but maybe a doc-focused meeting could 
+      be held sooner.
+    - [Sean's straw-man docs for demo](https://seancooper.xyz/OpenColorIO-Docs/index.html)
+    - Sean: Best example of work is the API section, under Baker. Small but 
+      complete example. Has generic class description at top, and API docs 
+      below. Method signatures needs some work, but C++ and Python are grouped 
+      together in tabs. In general, the goal is to have a page per class, and a 
+      tab per language in each API section. Language tabs are ganged together 
+      to avoid confusion while browsing docs.
+        - Docstrings are pulled from C++ headers, and from Python bindings via 
+          autodoc. 
+        - Doxygen is used to parse C++ headers. This is good for flexibility 
+          without maintaining our own parsing code. Doxygen and Breathe convert 
+          docs to Sphinx.
+        - It's a bit awkward if someone wants to modify a docstring. They would 
+          need to modify the header, which means more traffic on the public 
+          headers. Could get messy if we're not careful. It's a downside, but 
+          in general we can create the outline and from there just update it 
+          when the code changes. If you add additional methods or classes, they 
+          also need to be addded to the reST doc structure.
+        - Currently cant' be super language specific in docs.
+    - Mark: Does it include text blocks which are stored somewhere else?
+    - Carol: The text part at the top might be nice to separate. If you are 
+      changing API docs you are changing code. Maybe it would be safer to 
+      separate descriptive sections. There may be times where we need to make 
+      examples and reference something. Would be good to have control over that 
+      text outside of header.
+    - Sean: It's just like that right now because of the current header 
+      structure. We can decide what's in the header vs. what's in the reST. 
+      Sphinx is nice because you can directly reference classes (with links), 
+      which is hard to do with markdown. Still some quirks with the VuePress 
+      theme that's being worked out. Some clean up needed. Remaining work is to 
+      continue working on fleshing out API. Need to decide how to interface 
+      with docs. How do people want to build?
+    - Michael: Needing to build the lib to build the docs could be a blocker 
+      for something like RTD.
+    - Sean: Yeah, build time could be issue, since there is a timeout. Can 
+      deploy Sphinx in RTD. We still need to add a version picker. Also need to 
+      consider compiling code embedded in docs in CI to make sure it is still 
+      valid. The old code base had examples that no longer worked. Also not 
+      sure how to handle localization yet. Someone offered some language 
+      translation if needed.
+    - Doug: How does this work fit with other things in documentation; 
+      site-generators, etc. Does this proposal replace that?
+    - Sean: We haven't decided yet if Sphinx should just generate API docs and 
+      something else build the website. Currently it's all through Sphinx. 
+      Could go either way. We could have all the expository stuff on the 
+      website, and API docs in RTD. It's flexible so we could do both. The 
+      Doxyfy static site generator is user friendly, so could be used for the 
+      website. Perhaps host API on RTD and host Doxyfy page on GH pages; two 
+      deployments linked together.
+    - Carol: Worth seeing how much complexity is needed. A nice homepage and 
+      separation of API docs all within one framework would be nice. Does 
+      separating it make generation more complicated? 
+    - Sean: Updating the headers requires recompiling python bindings.
+    - Mark B: There will be a lot of churn up front, but it should stabilize. 
+      We could take the pain of rebuilding often up front, and it should get 
+      better. It's not going to impact contributors long term.
+    - Sean: Complicated to find balance of being nice for contributors and nice 
+      for documentation. The current design favors developers a bit more. So 
+      far the work has mainly involved a slight change in header comment 
+      formatting. There's still a lot of work to do for OCIO v2 docs, and 
+      deciding what to cover and talk about. In theory much of the docs will 
+      involve writing plain text.
+    - Carol: We'll set up a time to look over everything. It would be good to 
+      discuss what makes contribution easier too.
+    - Sean: We can form a TODO list, so that interested contributors can pick 
+      things to work on.
+    - Michael (post-TSC meeting note): This could implemented by adding issues 
+      for each item to the documentation GH Project, which could be assigned 
+      and tracked.
+    - **TODO**: Sean and Carol to plan a meeting to discuss structure and next 
+      steps.
+
+* ACES Config
+    - Michael: Working on scheduling a meeting to discuss next steps, possibly 
+      this Friday, but it is flexible if that conflicts with another meeting.
+
+* Items for next TSC meeting agenda:
+    - Carol: cineSync OCIO integration
@@ -0,0 +1,86 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 22, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Troy Sobotka
+
+# **OCIO TSC Meeting Notes**
+
+* GPU CI investigations:
+    - Infrastructure is in place for GPU CI on AWS. Credentials are for 
+      organization-wide use so all projects can benefit.
+    - **TODO**: Michael will work with LF releng and JF Panisset on 
+      implementation starting this week.
+
+* SIGGRAPH BoF:
+    - 30 minutes this year and virtual. With summer vacations coming up we 
+      should have a plan in place.
+    - Doug: We may want to schedule a longer event to go into more detail, 
+      could be after SIGGRAPH. Not sure if people will want to sit through full 
+      week of online meetings. Could do 30 minute overview, and longer 
+      "intro to v2" session after SIGGRAPH.
+    - Mark: Could use SIGGRAPH time to do presentation, but spin up Zoom 
+      meeting to chat about it afterwords for an hour or two.
+    - Carol: Emily mentioned possibly doing Open Source Day as a separate thing 
+      from SIGGRAPH.
+    - Doug: BoFs are separate from SIGGRAPH and free to all. Don't know exact 
+      date yet, but thought it was positioned relative to the original SIGGRAPH 
+      date.
+    - **TODO**: Double check with Emily whether ASWF Open Source Day will be 
+      part of SIGGRAPH or separate, and if date is known.
+    - Michael: We had discussed with Emily the idea of creating some OCIO 
+      videos. Perhaps this could intersect?
+    - Doug: Those videos may have been more for promotional purposes than 
+      education. 5 minute videos. Educational video will need to be longer.
+    - Kevin: Is the scarce resource our time or that of people joining? People 
+      can watch videos when they want, so the BoF room time could be used for 
+      discussion. Usually the BoF is half presentation and half discussion.
+    - Michael: If we go that route, we'll need to make sure we communicate 
+      to the community where to find the video ahead of time.
+    - Kevin: Could do offline presentation a week in advance, which would 
+      result in less schedule conflicts.
+    - **TODO**: Determine BoF/in-depth presentation plan once more information
+      on Open Source Day is available.
+
+* Pull requests:
+    - Patrick: Some old PRs. Are any blockers? Bernard's review is important, 
+      but there have been open CMake and Python PRs for a while.
+    - Michael: I can now address feedback on CMake PR, but can't merge until 
+      Sean has CCLA in system. This raises the point that with many initiatives 
+      ramping up and more contributors, getting CCLAs signed will be important. 
+      If you haven't started the process yet, it can take some time, so 
+      recommend starting soon.
+    - Doug: In EasyCLA instructions, says CLA manager at company should approve 
+      all projects, which simplifies the process for companies already 
+      contributing to another ASWF project. The CLA manager can add a company 
+      email domain so that anyone with a company email address can be approved.
+    - Mei: For Python unit test PRs, I am responding to PR comments. Working on
+      completing tests for transforms first.
+    - Michael: Feel free to open GH issues for unit tests that have not been 
+      completed. Others can then help and we can track the overall initiative.
+
+* New work on EGL support (#1039):
+    - Doug: New contributor doing work on EGL. Anyone have experience?
+    - Patrick: Window-system agnostic graphics APIs. On paper it's a good way 
+      to improve GPU unit tests.
+    - Doug: JF proposed this originally as way to avoid Nvidia GRID licenses 
+      for GPU tests.
+    - Patrick: It's mostly for headless machines. WIll require a lot of testing 
+      but huge benefit to project.
@@ -0,0 +1,90 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 29, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Troy Sobotka
+
+Apologies:
+  NONE
+
+# **OCIO TSC Meeting Notes**
+
+* Open source day, DigiPro, SIGGRAPH plans:
+    - Michael: Plans not final yet for Open Source Day, but between these 
+      events, how do we want to announce and present the OCIO v2 release.
+    - Both DigiPro and OSD are 25 minute presentations.
+    - Patrick: These are not enough time for all of v2.
+    - Doug: Main thing at SIGGRAPH is to get the word out, get it on people's 
+      radar. SIGGRAPH will be a busy time with many zoom meetings over those 
+      weeks. We'll probably want to do something longer after.
+    - Patrick: Would the audience be the same as with the v2 working group?
+    - Doug: Would be bigger group. We do want to have a presentation more for 
+      developers that want to upgrade their app to use v2.
+    - Patrick: How do we make sure we have these people? How do we get more 
+      people who are less active in other discussions.
+    - Carol: If we have a presentation at SIGGRAPH, part of that could be to 
+      bring up when questions can be discussed at a later, less formal, event.
+    - Michael: Could we do the longer meeting as a Bof? To also leverage the 
+      SIGGRAPH schedule?
+    - Sean: Will be good to have something on the schedule. Get the initial 
+      discussion, updates, etc. to the general audience, and invite them to 
+      something specific afterwords. May be able to put out word at the VFX 
+      Reference Platform discussion.
+    - Carol: Can the DigiPro talk be done twice? Once at OSD, once at DigiPro?
+    - Doug: OSD might require more practical project related topics to cover. 
+      We have a lot of material to cover. Could talk at OSD about case study 
+      of OCIO joining ASWF.
+    - Patrick: ASWF will provide a forum, but we can decide how to use that 
+      time and what content to cover.
+    - DigiPro to focus more on technical part of paper; OSD to focus more on
+      admin aspects of project, and as an invite to longer BoF session; BoF 
+      to provide longer update and discussion forum. The BoF could also be 
+      replaced by a later independent event if needed.
+
+* Summer vacations:
+    - Patrick out second half of July.
+    - Michael out next week.
+
+* OpenColorIO-Config-ACES meeting tomorrow:
+    - Continue discussion on initial work to design and build the config. 4pm 
+      EST, 1pm PST.
+
+* Pending PRs:
+    - Close to feature complete. Please have a look to keep reviews moving.
+    - Sean: PRs with multiple contributors are getting complicated. Not now, 
+      but we may want to explore using shared feature branches in main repo for 
+      collaboration. Topic for future discussion.
+    - Patrick: Student actively working on headless rendering support. Making 
+      great progress, but currently encountering CI failures. Headed in the 
+      right direction.
+    - Mark: Making progress on OpenColorMath. Currently working on the JIT 
+      evaluator.
+
+* Slack #helpdesk channel:
+    - Sean: Added a new #helpdesk channel to Slack to help with general 
+      questions. With self-signup being active that will be a good place to
+      manage those discussions.
+
+* V2 Working Group Discussion:
+    - Kevin: Looks like last v2 update got cut short based on slides. Anything 
+      more to discuss?
+    - Doug: Will set up another meeting in near future. More to discuss around 
+      caching and context variables.
@@ -0,0 +1,56 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 06, 2020
+
+Host: Doug Walker
+
+Rotating Secretary: Patrick Hodoul
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Joseph Goldstone - ARRI
+  * [X] Troy Sobotka
+
+Apologies:
+  Michael Dolan
+
+# **OCIO TSC Meeting Notes**
+
+* Recap. of the last documentation meeting
+    - Doug summurized the discussions (check the meeting minutes for details):
+      - Graham Fuller from Autodesk to advise on the documentation effort.
+      - Discussion around the table of content.
+      - No consensus on the overall documentation structure.
+
+* The documentation structure starts a new discussion:
+    - Sean: Put the documentation in a separate git repo or in a dedicated branch?
+    - Joseph: Propose a 'cook book' style of documentation.
+      For example, How to modify the config (Yaml) to do X?
+    - Troy: Propose that it helps the transition to Python with step by step examples from trivial
+      to more complex ones.
+    - Mei: Propose that it contains use cases from Python to config (Yaml) changes.
+
+* Config sanity check:
+    - Troy: Way to improve the sanityCheck() for whitespace issues?
+    - Mark: It relies on the Yaml library.
+    - Patrick: Recent pull requests greatly improve the sanity checks.
+    - Doug: Best would be to create an issue documenting the problematic cases.
+    - Mei: Find a way to enforce syntax?
+    - Mark & Patrick: No way as the Yaml library is permissive by design.
+
+* During the discussion Mei asked about how to 'debug' a color transformation:
+    - Patrick: Think about command line tool e.g. ociowrite to output an exact ctf representation
+      of the color transformation.
+
@@ -0,0 +1,107 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 13, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Troy Sobotka
+
+# **OCIO TSC Meeting Notes**
+
+* CLA, DCO, sign-off, challenge for first contribution and new contributors.
+    - New system often has problems for new contributors. People forget to 
+      sign-off, sign CLA etc. Can be tough to resolve related issues in PRs.
+    - Michael: Could improve CONTRIBUTING.md to further clarify process.
+    - Troy: CLA was painless. Sign-off was confusing.
+    - Mark: It is confusing. Just need the sign-off line. DCO plugin will try 
+      to help, but not always clear or effective solution.
+    - Sean: DCO sign-off can mess up commits for PRs with multiple 
+      contributors.
+    - Patrick: Sometimes these issues require redoing a PR.
+    - Troy: This is especially important for documentation work. A road block 
+      for small fixes like typos.
+    - Sean: Agree. It becomes noise that takes time and effort to solve.
+    - **TODO**: Michael will reach out to LF about improving usability of DCO 
+      plugin. Perhaps a method for signing off commits within a PR?
+    - **TODO**: Look into git mechanism to require sign-off when committing 
+      from local machine; method for solving issue before a PR is opened.
+
+* ociodisplay improvements or other ideas for contributors to work on?
+    - Patrick: Student eager to contribute. Looking for defects to solve. Any 
+      ideas for improvement? GSoC projects could be "revisited" to become GH
+      issues (smaller size).
+    - Michael: Does ociodisplay support dynamic properties?
+    - Patrick: Yes. ociodisplay is in good shape with recent updates, but could 
+      be improved further. Would be great to get feedback from production use
+      cases.
+
+* GPU CI update:
+    - Michael: Need to follow up with LF releng on getting AWS CodeBuild 
+      project created. Current DRAFT PR is in-theory read to go, but we'll see
+      once the infrastructure is in place.
+    - **TODO** Michael will follow up with LF releng on next steps.
+    - Patrick: Keep us in loop. The work on headless rendering can be completed 
+      once GPU CI is in place.
+
+* SIGGRAPH/OSD/DigiPro update:
+    - Michael: Not much new to report, but there is quite a bit of discussion 
+      happening around the topic. Will likely be a major point at the next TAC
+      meeting. Events are coming up quickly.
+    - **TODO**: Waiting to hear details on DigiPro talk recording for Doug.
+
+* Working group meetings:
+  - Doug: ACES impl TAC meeting tomorrow, which conflicts with ACES config 
+    meeting. Several of us need to be there.
+  - Michael: We can cancel. Thomas submitted PR with config discovery work 
+    which needs review in the meantime.
+  - There are also conflicts for the documentation working group meeting this 
+    week. Can cancel that too.
+  - **TODO**: Michael will cancel this week's working group meetings.
+  - **TODO**: Sean lost write access to OCIO GH account. Michael will reach out 
+    to LF about getting that restored.
+
+* Documentation update:
+  - Sean: Looking at RTD more. Can't build OCIO through RTD currently, which is 
+    problematic. Need to do local build to generate Python API RST. Sphinx will 
+    render RST from autodoc signatures. RTD picks that up and renders HTML. 
+    Need to add this process to CMake target.
+  - Michael: PR needed to update docs?
+  - Sean: Yes, but only needed when public API changes. The built RST needs to 
+    be added to the main repo, under docs/. Has normal RST and API RST subdir, 
+    which only contains autodoc content initially, but is built into RST.
+  - Mark: Bad to have build artifacts contributed to repo.
+  - Sean: Need to see what Larry is doing in OIIO docs. Another option could be 
+    to upload generated HTML from CI to RTD.
+  - Mark: Why is build needed to get RST? 
+  - Sean: Because of building python bindings, which depend on the OCIO lib, 
+    and doxygen too.
+  - Michael: pybind11 provides signatures and types etc.
+  - Mark: Could make a basic stub version of OCIO lib just for pybind; fast cpp 
+    build to trick the system, but would have to maintain the moc lib build. 
+    Could even auto-create it.
+  - Patrick: Too many steps. Need to be careful not to make development 
+    overcomplicated.
+  - Sean: Has PR on standby with doxygen header reformatting. Waiting on CMake 
+    updates to complete. Also created style guide for how to maintain new 
+    header formatting.
+  - Doug: The doxygen merge is needed soon to avoid further work.
+  - **TODO**: Investigate if RTD can support build step for generating docs.
+  - **TODO**: Sean to retry PR to Michael's CMake branch on the new clean 
+    branch.
+    
+* Notes:
+    - Patrick is on vacation for the last two weeks of July.
@@ -0,0 +1,110 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 20, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Troy Sobotka
+  * [X] Joseph Goldstone - ARRI
+  * [X] Chin-Ying Li
+  * [X] Simran Brucherseifer
+
+Apologies:
+  * Mark Boorer
+  * Patrick Hodoul
+
+# **OCIO TSC Meeting Notes**
+
+* OSD planning:
+    - Wed-Thurs, August 19-20 (55 minute session).
+    - Michael: We talked previously about having discussion for users and 
+      integrators. Should we try to use this session for that?
+    - Doug: Last year's OSD wasn't much discussion. Large room, large group. 
+      Didn't feel like BoFs from previous years. Not sure the virtual format 
+      will allow.
+    - Michael: Good point. OSD may end up being a webinar format, where there 
+      are limited speakers, but chat based Q&A throughout. If we focus more on
+      a presentation format, how much overlap with DigiPro presentation?
+    - Doug: Depends on whether DigiPro has a pay-wall. If it's free we can 
+      encourage people to watch that presentation. The paper will be available 
+      either way, but if DigiPro is not free, overlap may be needed. We can 
+      prepare 55 min of material, pause for questions, and dynamically adjust 
+      content based on volume of discussion.
+    - **TODO**: Michael will follow up with Emily on virtual DigiPro attendance 
+      policies.
+
+* CLA (Apache, umbrella CLA):
+    - Michael: There was discussion at the TAC meeting around switching to the 
+      Apache CLA (from the current LF CLA) which is preferred by some 
+      contributors. OpenCue already has this CLA (and OCIO used it previously),
+      and if all projects agreed to switch we could potentially have an ASWF 
+      umbrella CLA to allow contributions to all ASWF projects from a single 
+      CLA. I expressed that now was probably not a good time for OCIO to switch 
+      due to v2 "crunch time", but that we would discuss the change following 
+      this push. Any objections to making this change later in the year when 
+      time allows?
+    - No objections raised.
+
+* CMake PR; is it ready?
+    - Michael: It's ready, but Sean has an additional Python-related fix which 
+      we have been discussing the best way to merge. DCO issus created some 
+      branch conflicts earlier so I resubmitted from a clean branch. Sean could 
+      follow with a supplemental PR if we merge it now.
+    - Sean: Patrick and I encountered issues with this change discovering 
+      Python 3 on our systems (macOS and Linux respectively). The proposed fix 
+      resolved these problems for both.
+    - Michael: CI is passing, but that may be due to using explicit Python 
+      paths in the CMake commands. Sounds like the current method os not 
+      finding python-dev headers.
+    - **TODO**: Merge the CMake changes as-is since CI is passing, and Sean 
+      will submit fix in a followup PR since the change is small.
+
+* Website design/logo refresh:
+    - Doug: Month out from feature complete. Need the update docs before 
+      inviting people in to v2. Pushing up to the wire. We need to focus on 
+      docs in the coming weeks. Looking at Simran's toolchain data flow 
+      diagram, this provides good overview of documentation approach. Is it 
+      correct?
+    - Sean: Yes, just need to add a node for generating RST from 
+      pybind11 code.
+    - Doug: Can we define concrete projects so contributors can work on this? 
+      In the next two weeks we either need to get this working or stay with 
+      existing system.
+    - Sean: Docstring header PR is in. Need another PR for pybind11 docstring 
+      header, and another for reorganization of doc structure. The RTD page 
+      points to official OCIO repo, so we're live now, but API docs and new 
+      style is missing. Any changes to master are getting pushed to RTD now. 
+      Not as much holding back docs as it seems. 
+    - Simran: An event hook in GH communicates to RTD when to update the site.
+    - Michael: Can we open GH issues for logical chunks of work?
+    - Sean: Remaining infrastructure work is to finish Python docs extraction. 
+      The CMake workflow needs work, which uses another pybind11 component 
+      that doesn't install with pybind11 by default, so will be need to be 
+      pulled at runtime.
+    - **TODO**: Sean will create PR with his current Python extraction work. 
+      Chin-Ying Li willing to assist with this work to help finish doc 
+      infrastructure.
+    - Doug: There are two parts of docs: infrastructure and writing content. 
+      Separate tasks. Infrastructure should be in place to see what final 
+      product is going to look like. For content objective, Carol has been 
+      writing table of contents/outline. Lots of discussion on that. AD team 
+      can help write docs.
+    - Sean: Would be good to get GH issues and volunteers for writing certain 
+      sections of docs.
+    - **TODO**: Break remaining work into GH issues to help with contribution.
+    - **TODO**: Michael will reach out to LF creative services about help with 
+      frontend work. Can collaborate with community on re-branding effort.
@@ -0,0 +1,68 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 27, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Troy Sobotka
+  * [X] Joseph Goldstone - ARRI
+  * [X] Chin-Ying Li
+  * [X] Simran Brucherseifer
+
+# **OCIO TSC Meeting Notes**
+
+* "Sanity check" function uses non-inclusive language:
+    - Simran: Brought up in ASWF diversity Slack channel. This function uses 
+      non-inclusive language related to mental health:
+      [https://www.selfdefined.app/definitions/sanity-check/](https://www.selfdefined.app/definitions/sanity-check/)
+    - Mark: Would be an API breaking change. No problem changing it though.
+    - Kevin: "validity" check also not ideal.
+    - Michael: What about just "validate"? Now is the time to change it since 
+      the API has already changed for v2.
+    - Carol: Should we do a sweep for other terms too? 
+    - Simran: Yes. Only checked this one term so far, but can check others.
+    - Kevin: Can you do a word scan?
+    - Mark: Can open issue per term to discuss.
+    - **TODO**: Simran will submit PR with suggested changes to promote 
+      inclusive language.
+
+* Status updates:
+    - [Comment in this document's TOC for sections of documentation you would like to contribute to](https://docs.google.com/document/d/1AdCWgo_g7SHoVCakGTizs8j6AljSVfx1u6RKnyxIC2A/edit)
+    - Michael: For open source days, suggest reusing DigiPro content and just 
+      expanding for the audience.
+    - TSC agrees on reusing content where possible.
+
+* Apple silicon build and CI:
+    - Joseph: Any discussion about support for Apple silicon?
+    - Michael: This was discussed at the last CI working group. It's on the 
+      radar and Apple has a representative in the group who is knowledgeable 
+      on the subject. Ongoing discussion will continue.
+    - Doug: We will need to check OCIO's SSE code.
+
+* Logo discussion:
+  - Logo type all caps or upper/lower mixed case? Discussion in #branding Slack 
+    channel on this topic. Other ASWF projects use mixed case.
+  - Carol: Like the all caps. Individual projects can have unique logos.
+  - Doug: Adding spaces helped readability a lot. I see Emily's point for 
+    consistency, but there is already some difference in ASWF logos.
+  - Patrick: Good to have consistency across ASWF, but should not be mandatory. 
+    Should do what's right for the project. Best to see what's appropriate for 
+    OCIO first.
+
+* Items for next TSC meeting agenda:
+    - Discussion around whether additional static libs should be shipped for 
+      libutils.
@@ -0,0 +1,75 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 3, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Troy Sobotka
+  * [X] Chin-Ying Li
+
+Apologies:
+  * Mark Boorer
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* Outstanding work to hit feature complete date:
+    - Doug: Bare-bones website running by Aug 12th (DigiPro talk), for marketing 
+      and building interest. Will be traffic following DigiPro.
+    - Michael: Any areas of docs unaccounted for?
+    - Doug: Grahame and I working on key pieces. Creating starting point, with 
+      documented high level features. Other part is landing page - Carol 
+      working on that.
+    - Carol: Looking at Hugo for landing page. Seems simple enough to set up. 
+      Hugo is better setup out of box. Easier to get started. Better support 
+      community. Static site for gh-pages. Talking design ideas with Mario, but 
+      will get something up for now.
+    - Michael: Will have PR in by end of week with documentation sections 
+      committed to.
+    - Sean: Anyone able to get docs built?
+    - Doug: Requires Python 3 so a bit problematic. Requirement for Sphinx 2, a 
+      theme dependency, which is Python 3 only. 
+    - Any other open infrastructure tasks?
+    - Sean: Still working on API doc build. Current PR is for extracting 
+      docstrings from python binding, blocked by a clang dependency.
+    - Michael: Only potential issue is Windows. Clang is common on Linux, and 
+      default on macOS. What do you need to complete API work?
+    - Sean: Getting workflow down for extracting RST files from Python bindings. 
+      Only way to do it is locally generating RST files with breathe and autodoc. 
+      Need to find a way to do this at runtime - RTD limitation. Might be way 
+      for RTD build server to use Docker container with pre-built OCIO libs
+      locally available. Sphinx plugin can rebuild expanded RTS, as a fallback 
+      solution.
+    - Michael: Anything Autodesk team needs to hit date?
+    - Doug: May need help with local doc build, but will reach out. Will then 
+      try to get RST files written.
+    - Sean: There is a requirements file that pip can be pointed to to install 
+      dependencies.
+
+* OSD preparations:
+    - Michael: Any interest in talking documentation process at OSD?
+    - Carol: Could talk angle of community involvement with docs.
+    - Michael: Can also have brief intro to docs to get interest.
+    - Doug: Good to have more participation in the BoF.
+    - Carol: Sean and I can talk and have slides about process and introducing 
+      docs. If there's no Q&A, good to introduce landing point for exploring 
+      docs. More important if there's no discussion.
+    
+* OCIO v2 WG meeting
+    - Doug: Will this Thursday work? Will send email. Number of PRs going to 
+      land soon. Want to give explanation and guidance about the work. Will 
+      discuss the work remaining to be feature complete.
+    - TSC agrees this day will work.
@@ -0,0 +1,82 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 10, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Joseph Goldstone - ARRI
+
+Apologies:
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* Admin updates:
+    - Michael: Will get Open Source Days slide deck ready early this week and 
+      share for input. Also going to send message to ocio-dev and ocio-user 
+      announcing upcoming events. Let me know if you have anything to add to 
+      either of these.
+    - Michael: Some open questions in ocio-user if anyone has cycles to give 
+      guidance. I can mention these in Slack too.
+
+* PR: follow-up on existing PRs:
+    - Patrick: Several open PRs. Any work needed before DigiPro? Is the Python 
+      docstring PR critical (#1074)?
+    - Sean: Needed to complete API docs, but not ready by DigiPro. Can use 
+      static build for now.
+    - Patrick: Any comments on Simran's PR (#1081)? All agree on sanity check 
+      and other language changes?
+    - Kevin: Just wondering if the term change is correct. It's an API change, 
+      so should use caution. We don't want to have to change it again later.
+    - TSC agrees the change is ok. Will merge.
+    - Patrick: SPI1D and SPI3D PR can wait.
+
+* Documentation questions:
+    - Carol working on CCLA to be able to merge homepage page PR (#1091). Will 
+      need to update gh-pages with another PR following that.
+    - Michael: Can make PR against gh-pages. Pull local, update and test in 
+      browser, and then open PR for live site update on merge.
+    - John: Take a look at Netlify, for live preview of site in PR. Can do Hugo 
+      build and provides link to a preview page of the site. OpenCue uses this.
+    - **TODO**: Consider integrate Netlify at a later date.
+    - Doug: API docs. Can we have drop in baked version for now? Since gh-page 
+      update will remove them.
+    - Sean: Python package for reST build mangles API doc style. May have to 
+      reformat by hand for now. Trying to take the Sphinx autodoc features and 
+      recompile into full RST files. This affects C++ and python API docs. Will 
+      try to have PR in tonight.
+    - Doug: Working on doc content. Will be making PR tonight to reorganize docs, 
+      imposing new TOC structure on top of existing work, which will condense 
+      sub-chapters. Added a lot of new documentation. New feature structure is 
+      there and out-of-date/incorrect content is removed. If anyone has time to 
+      review that PR tomorrow, we'll try to get it merged by EOD Tuesday, to have 
+      the new site and docs live.
+    - **TODO**: Need to add work-in-progress note to RTD homepage. Also planning to 
+      remove the quick start from doc landing page, since we now have a dedicated 
+      quick start section.
+    - Doug: Docs talk a lot about the Nuke plugins. Since Nuke now has native 
+      integration, these references are not as helpful. Remove?
+    - Mark T: Talking to Nuke team about how to push out new Nuke plugins, and where 
+      to put them. Recommend leaving Nuke nodes out of docs for now since it will be 
+      misleading. Having conversations about OCIO v2 with team now.
+    - Doug: I'm adding a lot of info about upgrading to v2, so worth looking at for 
+      products that use OCIO.
+    - Doug: Noticed that TOC navigation isn't always updated properly. Some sections 
+      look wrong when clicked.
+    - Sean: Sphinx doesn't update every page when you update docs. May need to rebuild 
+      to prevent old pages showing up. Can use make clean, or  sphinx-build -a to 
+      update all files.
@@ -0,0 +1,121 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 17, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Joseph Goldstone - ARRI
+
+Apologies:
+  Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* OSD Slides & talk:
+    - OSD Slide deck is ready for updates. OCIO talk is first thing on 
+      Wednesday. We will likely have Q&A time at end since the event is 
+      55 minutes.
+
+* Documentation TODOs:
+    - Carol: Will submit PR before Wednesday to fix some homepage bugs.
+    - Doug: Thomas dove into docs and gave good feedback on Slack. One focus 
+      should be Python example code, which is missing. Will look at writing 
+      some examples. Should look at how to integrate python and YAML into 
+      documentation via discussed tabs, etc.
+    - Michael: How should we identify doc sections is need of work?
+    - Carol: Time to move outstanding issues from Google doc to GH issues.
+    - Doug: Some issues are referenced in the Documentation GH project. We 
+      should triage those on Friday.
+
+* libutils discussion:
+    - Michael: Continuation of discussion from two weeks ago about whether 
+      libutils should be distributed alongside libOpenColorIO.
+    - Mark B: Don't want optional features because OCIO gets embedded in DCCs. 
+      Should be consistent everywhere. Previously was an issue with optional 
+      Boost shared pointers, so DSO couldn't be swapped. Don't feel we should 
+      be shipping anything other than the main lib. If other libs are needed, 
+      needs to be a compelling reason for them to exists. Calling them utils 
+      doesn't hit that bar for why they should ship. If they are examples, make 
+      them available as code only.
+    - Michael: We could separate out the libutils cmake, making it available 
+      for users to build on their own. Still needs to be included in OCIO CI 
+      though.
+    - Mark B: Once we dist OCIO, a cmake stub lists all exported targets, and 
+      those are what were expecting others to import. Could make them pruned 
+      off from tree as a separate project, not built by default. Can still 
+      build those and run as part of CI. Can have docs on how to get started 
+      with example programs and how to install them, linking against deployed 
+      OCIO.
+    - Kevin: Would it still be a library? Could they still get used as such? Is 
+      it something that should be a static lib that you can optionally link 
+      against.
+    - Patrick: That's how they are now, and are currently statically linked by 
+      apps.
+    - Mark B: Can compile them, just don't install them in the install 
+      location. Lib folder should only contain core OCIO.
+    - Patrick: In OIIO, there is a shared lib for utils. Could be like that.
+    - Mark B: Not a good practice, and that is a shared library.
+    - Patrick: Could it be an option to make it a dynamic lib released as 
+      utils?
+    - Mark B: Small amount of users will use these. Don't need the extra 
+      library to do anything. Most people will encounter OCIO through a package 
+      manager or as an end user, and just want to run OCIO. Won't need all the 
+      extra bits. From our lib side, it's about shrinking the amount of stuff 
+      that we're supporting. Good to keep it small. Most libs don't come with 
+      utils.
+    - Patrick: Valid point, but fear people will rewrite these pieces. They 
+      will help ease transition to v2.
+    - Mark B: If that stuff is good, should have a space in libOpenColorIO.so, 
+      part of namespace with utils.
+    - Michael: Like OIIO::ImageBufAlgo.
+    - Patrick: Want to limit dependencies. libutils depends on OIIO and other 
+      libs, which is why it was decided to make it external. Want to avoid 
+      people rewriting these pieces.
+    - Mark B: Think it's good to provide, but shared lib probably not right way 
+      to do it. Provide code and allow implementors to decide how they want to 
+      implement and what dependencies to use. We've made it easy to get started.
+    - Patrick: If we don't distribute, package managers will not have these 
+      pieces.
+    - Mark B: Most people downloading lib wont need this.
+    - Doug: There are different categories. Some things could be separate, but 
+      apputils probably needs to move into the core library.
+    - **TODO**: Patrick will investigate alternative options and report back 
+      when there's time.
+
+* PR #1104:
+  - Patrick: Fix for cmake detection via CMake user registry, could use review 
+    by someone else. Special case, but should be merged soon.
+
+* Python optional parameters:
+  - Patrick: Thomas discovered some Python interface that should have default 
+    parameters, which were previously optional parameters are now mandatory 
+    (issue #1105). C++ has no optional parameters per OCIO design, but this 
+    rule is not necessarily appropriate for Python. How should we handle this 
+    in Python? Also highlights being backwards compatible for C++ vs Python. 
+    We should decide if we are backwards compatible and consistent with v1 
+    Python API.
+  - Mark: Perhaps both can change if the APi is bad.
+  - Patrick: Think we need to be consistent where possible.
+  - Mark T: Hit the same issue while testing at Foundry. Differences in 
+    default parameters of API were problematic.
+  - Michael: There have also been some issues where null pointers in the C++ 
+    API don't interface well with None in Python and cause a crash. pybind11
+    provides a solution for this which we've been fixing whenever a case is 
+    found.
+  - Doug: We also made improvements in C++ to not crash in these cases.
+  - TSC agrees that optionals args in the Python API (contrary to the c++ API)
+    is good and to move ahead with suggested fix.
@@ -0,0 +1,136 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 31, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Daniele Siragusano - FilmLight
+  * [X] Joseph Goldstone - ARRI
+  * [X] Anandhaiyappan M
+
+Apologies:
+  * Mark Titchener
+
+# **OCIO TSC Meeting Notes**
+
+* Issue #1124 discussion and resolution
+    - London holiday today so we don't have quorum. We can discuss solutions to 
+      present at the next TSC meeting where all members can provide additional 
+      input and decide on a resolution together.
+    - Any additional thoughts to share for the issue discussion?
+    - Doug: Transparency and communication was actually something we felt we 
+      had been doing a good job on, so it was discouraging to hear that we 
+      still have more work to do on that front. The distributed nature of open 
+      source development does make it difficult for people to track, especially 
+      if they cannot attend all of the live discussions. If we can make 
+      additional improvements in this area, I think they would be appreciated.
+    - Carol: It goes both ways. Some things we've been aware of like struggling 
+      to get PRs reviewed. There will hopefully be some good on that end, 
+      improving feedback and contributions.
+    - Patrick: We can improve things, but should not do so by adding more 
+      process to what we're doing. Managing a project at Autodesk is a full 
+      time job. I don't think we have the resources to do that in the 
+      community.
+    - Doug: Carol made that point too. Not sure if there's a precedent for 
+      non-developers who want to participate in open source. Is that a thing? 
+      Could we get people to contribute in that role?
+    - Carol: Will be sitting down with some Netflix PMs to get some initial 
+      thoughts on it. Also could bring it up at the next TAC meeting. Would fit 
+      nicely in with the ASWF.
+    - Doug: Could even be a paid position.
+    - Carol: There's room to expand what people think of with open source. 
+      Cool and exciting opportunities.
+    - Doug: Good opportunity for someone who wants to be a developer but start 
+      in an admin role to get involved with the process. The project doesn't 
+      necessarily intersect with that group. Most involvement is from 
+      developers.
+    - Mei: Is there an example of OSS project of this scale with road map?
+    - Michael: ASWF does have budget if need was presented across projects.
+    - Patrick: Already have two OCIO projects (documentation and Python unit 
+      tests) that could be a starting point for exploration.
+    - Carol: This is something I can tie back into the D&I working group too.
+    - Patrick: Good point. Doesn't need to know a lot about OCIO. Good 
+      opportunity for someone with interest.
+    - Michael: I think it would help if new design work was presented in a GH 
+      issue earlier in development. I know most new features are already there,
+      but going forward we could have a two week proposal period at start of 
+      development.
+    - Patrick: True, but being pragmatic, only one or two people are looking at 
+      the issues we open now, and only one at PRs. No question for improvement, 
+      but that's why we have had the v2 working group.
+    - Doug: What I've been trying to do is create issues in advance of PRs. 
+      This case was different because we are all so busy with conferences and 
+      docs. Usually the issue does go up well in advance, but it's rare that we 
+      get much feedback.
+    - Michael: It's important to note too that the decision to have a two-week 
+      rule was important for keeping development on track. Earlier in the 
+      project PRs would sometimes sit for months and block further work. The 
+      investment of three full time engineers from Autodesk is a generous one 
+      and it's important to not take that for granted, and to utilize the 
+      time as much as possible to keep an interest in the investment. The 
+      resolution was no comments following the two week period implied 
+      acceptance.
+    - Carol: If I don't have an issue I don't comment, since that is the 
+      process.
+    - Michael: To improve, we can document the current process in one place, 
+      as it is, and make adjustments that the TSC agrees will improve 
+      transparency. That way it's documented and clear.
+    - Doug: Agree. PRs can be made on document to propose changes to the 
+      process.
+    - Patrick: Can extend the meeting to speak about features too. Talk more 
+      about technical discussion. Could be a way to improve process wih no 
+      cost. Speak about features, etc.
+    - Doug: Agree it's a good idea. Initially having two meetings was good, 
+      but now they can be combined.
+    - Michael: As mentioned too we can adjust the time to work for the NZ time 
+      zone, but we should discuss with our London members first too, since it 
+      would put the meeting later in their evening.
+    - Patrick: Also have meeting notes which can get feedback on. Minutes can 
+      be way to document points. Also, when we wait two weeks, we put a warning 
+      before merge. The warning does not mean we will merge no matter what. 
+      Just a final warning about the merge if there are no objections. Worth 
+      explaining that. It's just a notification. Could better explain process.
+    - Doug: Yes that could go in the document. I agree.
+    - Michael: And let me say that all of the work you have done Doug, Patrick, 
+      and Bernard is highly appreciated by the community and industry. You have 
+      all done excellent work with huge impact.
+    - Doug: And thanks also to all the community who invested so much time 
+      along with many other responsibilities.
+    - Patrick: Yes, thank you all for all the effort on part time involvement.
+    - Doug: Thoughts on this issue John? On Trello board or feature roadmap 
+      discussion, etc? We don't have a full time project management. Are there 
+      LF projects with scrum master/project manager contributors. Not 
+      developing code; just making sure the interface between developers and 
+      the community is solid.
+    - John: Yes, it varies. One project I'm involved in has a lot of project 
+      managers because of stakeholder involvement. Some smaller scale projects 
+      just don't have those resources available. For one project I work on I've 
+      put together a kanban board tracking the work we're doing as a staff. We 
+      tried to address that transparency by putting issues and actions in there 
+      for the community to see. That's one example and the lift is pretty 
+      light. GH has a serviceable kanban board ability. Good points. Good to be 
+      as transparent as you can, but not to kill yourselves in process. Good to 
+      consider trying to make sure you're very public about pointing where key 
+      things to check are. Documentation, etc. Make those assets as 
+      discoverable as possible. Pretend you're starting from zero. What 
+      challenges would you face while getting started in the project. On a 
+      cadence, put together a blog post of what's being worked on, and where 
+      we're headed. A way to chronologically say whats going on, without taking 
+      a ton of time. Helpful communication.
+
+* Items for next TSC meeting agenda:
+    - Discuss proposed resolution and make decision.
@@ -0,0 +1,126 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 14, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Alessandra Tomassi - Industrial Light & Magic
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] J Schulte - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* Zoom
+    - Mark B: Some people having trouble logging into Zoom. Is this meeting 
+      open to the public?
+    - Michael: Yes it's open to all. I do believe a free Zoom account is 
+      needed to login to some Zoom meetings now. Zoom has been making changes
+      to improve security. Later in the month joining a meeting will require 
+      either a passcode (not to be confused with password) or meetings will
+      require a waiting room with a host to let attendees in. We will try to 
+      embed the passcode in the meeting URL. If anyone has an issue joining,
+      have them reach out to me and I'll help troubleshoot.
+
+* PROCESS.md (PR #1140):
+    - Michael: New PROCESS.md document outlines new feature development process 
+      for project in response to issue #1124. Please have a look and provide 
+      feedback. I attempted to document the current process with expanded 
+      detail around design review.
+        - Also created a "Roadmap" GH project to track feature proposals. Open 
+          for discussion.
+
+* New TSC meeting time and duration:
+    - Michael: Continuing previous discussion on merging OCIO v2 working group 
+      with the TSC, extending the TSC meeting to 1 hour, and pushing the time 
+      back to make accessible for NZ attendees. This makes for a later time for
+      London, but makes the time work for all time zones. Propose same time 
+      slot used for other ASWF meetings (8am NZST/4pm EST/1pm PDT/9pm BST).
+    - Mark B: Would prefer earlier if possible, but can work.
+    - Mark T, Kevin: Time works ok.
+    - J: Can we rotate meeting between different time slots. Every other 
+      meeting early and late. Some other meetings do this and works.
+    - Carol: D&I working group does that. Might be an issue for getting quorum 
+      though.
+    - J: Monday also intersects with many holidays.
+    - Kevin: And other days of week don't work well because of other ASWF 
+      meetings, etc.
+    - Carol: Can push meetings on holidays whe needed.
+    - Michael: We will try to reduce cadence once v2 is released, to either 
+      bi-weekly or monthly, as needed.
+    - Kevin, Mark T: Later is fine if we're meeting less frequently.
+    - Doug: Carl Rand, who is a TSC member can't make it due to time. Thomas 
+      is an active contributor and testing v2 features also. Should consider 
+      something that works for them too. As I wrote in issue #1124, we (AD) 
+      second the proposal to merge the working group and TSC.
+    - Mark B: Could be longer than an hour. Sometimes v2 working group 
+      discussions run over.
+    - Carol: Discussions may calm down after release.
+    - Kevin: Hope so. With the new cadence and longer time, should amount to 
+      similar amount of time. Wont be as many controversial features to 
+      discuss.
+    - Doug: Hour should be good. Let's start with that.
+    - Carol: In terms of transparency, agenda is king. People should have 
+      visibility into topics for a meeting ahead of time, which will help 
+      inform who want to join the discussion.
+    - Michael: Yes, agree. I have not been the best with getting the agenda 
+      out early. My intent going forward is to link the ongoing Google doc we
+      use for agenda items each week in the calender event for visibility, 
+      with a note about adding agenda items ahead of time.
+
+* GH main branch:
+    - Michael: Wider discussion happening in GH and ASWF right now about 
+      default branch names. GH is moving to "main", and OpenEXR is considering 
+      "dev". We should decide our course of action. GitHub recommends waiting 
+      a bit before making the move since they will introduce tooling to ease 
+      the transition.
+    - Doug: Prefer to wait till we branch for v2. Would be an ideal time to do 
+      it.
+    - Mark B: Disagree with OpenEXR workflow. Prefer "main" over "dev". People 
+      should land in a stable branch, which "dev" does not imply. 
+    - J: Agree.
+    - Mark B: A bit different with CI keeping the branch stable, but good to 
+      land on first stable branch ideally.
+    - Carol: All for changing the name in due course, but recommend staying 
+      with what GH is supporting, so we can utilize their tooling and avoid 
+      creating more work for ourselves.
+    - Michael: Ok, so we'll plan on switching to "main" when branching for OCIO
+      v2 release.
+
+* Help Wanted issue label:
+    - Doug: Want to create a label for issues needing help, but that aren't 
+      good first issues. Have list of tasks planning to add that are good for 
+      people who have some time to contribute but aren't new to the project. 
+      Thomas uses a "Help Wanted" label, and other projects use it also. 
+    - Michael: Sounds like a good choice.
+    - TSC agrees.
+
+* GH Issue subjects vs labels:
+    - Kevin: Noticed in some cases that subjects will have notes like "\[RFC\]". 
+      Like labels but not. Need some cleanup with labels, with some new ones like 
+      "RFC", etc.
+    - Carol: Yes. Looking for ways to track stuff for documentation work. I've 
+      been using checklists and the project board, etc.
+    - Michael: Need new committer level that isn't "Write" but allows adding 
+      labels to issue and general admin work.
+    - Patrick: I'm doing follow to add labels on issues. Don't want to add 
+      labels to all defects, since it's not always clear and we don't want too 
+      many, but new labels like "RFC" should be added. Will improve understanding 
+      of project to clean up.
+    - Doug: Labels can add issues to GH project automatically, which might be 
+      worth looking into.
+    - J: Can get busted in my experience.
+  
@@ -0,0 +1,174 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 21, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [X] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Simran Spiller
+
+Apologies:
+  * Mark Titchener
+
+# **OCIO TSC Meeting Notes**
+
+* Some pending pull requests (1130, 1133 and 1134):
+    - Patrick: Three PRs needing review, ready to merge
+      - 1130: Cache processing - also topics related to context variables.
+      - 1133: Improved grading ops - no feature changes, just fixing some 
+        issues.
+      - 1134: Not new, but some changes to VFX ref platform (CY2021). Updated 
+        Makefile to adhere to that. Not a feature.
+
+* Some ‘small’ pull requests (1146 and 1551) which help contributors testing 
+  using the Windows platform:
+    - Patrick: Important for Windows platform, to be merged ASAP
+      - Removing MFC dependency.
+      - Improvement for Python 3.8 support, small change (From Simran).
+    - Michael: 1140: PROCESS.md proposal needs additional reviewers.
+
+* Building on Windows requires the build/config type to be specified up to 
+  three times, how to default to CMAKE_BUILD_TYPE? (issue #1153):
+    - Mark: CMake build type not respected on windows. Different way to 
+      describe targets. On Linux generates Makefiles, but on Windows 
+      generates MSVC project, where debug, release etc. is decided. Huge pain 
+      in Windows. Have to keep the same flags for all dependencies. If you 
+      build one thing with different flags, and one package is wrong, the whole 
+      thing will fail. If we give pre-built binaries, they are stuck with the 
+      build modes we provide. Other projects have turned own project into meta 
+      builder that first builds dependencies, and then builds package.
+    - Michael: OCIO_INSTALL_EXT_PACKAGES does something similar, but not in one 
+      single solution.
+    - Mark: Only works if they are all in one MSVC project, Needs meta project. 
+      Usually not worth it. Either users are on their own, or we provide 
+      instructions on how to build.
+    - Michael: Can documenting the process for now.
+    - Patrick: Not a fix, but workaround. Ninja could also work.
+    - Mark: Same linking issue regardless of generator. MSVC linker used with 
+      Ninja or VSProject. All will have the same problems. How Windows builds 
+      dynamic libraries and sets optimization flags.
+    - Patrick: Perhaps something is missing in OCIO project.
+    - Mark: Because we statically link all these dependencies. Hard to enforce 
+      passing the same flags though. Especially if sub-projects have own cmake 
+      projects, since one can break the entire chain. Have to massage each. 
+      yaml-cpp is the first offender for breaking the linkage.
+    - Patrick: Already have a problem with one dependency not using 
+      CMAKE_BUILD_TYPE.
+    - Mark: On Windows doesn't matter at all. XCode generator has similar 
+      problem on macOS.
+    - Patrick: Document on Windows for now, and add something missing if we 
+      find better solution later. New VS 2019 also introducing problems by 
+      itself.
+    - Thomas: Should follow VFX platform, mandates VS version now. If you want 
+      to be compliant on Windows, use 2017.
+    - Michael: CI VMs use 2019, no option to use other version without a 
+      container. hopefully can find solution in CI working group.
+    - Simran: There is in fact an option with GHA: the windows-2016 virtual 
+      environment has VS 2017. But it's some 2017 version that GitHub updates 
+      every now and then, no control over the exact compiler version (but will 
+      always be 2017).
+
+* TSC opinions on C++/Python API Docs Generation (Issue #1148):
+    - Sean: Just RTD was problematic. Everything else working well. All 
+      features listed in issue work well locally, but RTD can't do what we 
+      need. Other projects have made hacks with skeleton python bindings, but 
+      unless you automate it, it drifts.
+    - Doug: One thing discussing in documenting wg - we want to know who our 
+      customer is. Feedback is that biggest customer of web based API docs is 
+      python developers since C++ devs will often just go to the headers and 
+      dev env. If Python user is target, and since there are some significant 
+      differences, question came up as to whether we should target python 
+      specifically. IS C++ docs needed? Question to raise, not suggesting one 
+      or the other.
+    - Carl: As C++ dev, we generally just look at header since html docs are 
+      usually pretty lacking.
+    - Mark: Useful for showing someone relevant part of docs, link to html.
+    - Carl: As long as it's well documented. In v1 was primarily looking at 
+      python docs. Would prefer html, but at end of day, well documented header 
+      is most accurate. Local host of docs may not be up to date. API 
+      differences, etc.
+    - Thomas: Other example is if you look at Qt. There is no python docs, but 
+      python developer uses C++ docs to work on python. May not even need python 
+      docs. Possibility to use C++ docs.
+    - Mark: Easier now that they are similar, but were different before. We'll 
+      have similar problems with more pythonic API.
+    - Carol: All of us are going do what we're comfortable with, but for new 
+      users a well documented python API will be very helpful.
+    - Sean: This is why I proposed using matching C++ and Python, which still 
+      allows for overriding python docstrings where they differ. Just RTD 
+      getting in the way.
+    - Mark: Still no appetite to offline doc build and upload to branch?
+    - Sean: Could put website on RTD and docs on GH branches, but lose API 
+      versioning. If we only do python docs, could be something different. 
+      Either have to make scripts to generate skeleton code, or someone working 
+      fulltime on skelton code.
+    - Mark: Is RTD appetite for us not wanting us to host ourselves? Could be 
+      our instance of RTD.
+    - Thomas: Might be worth looking at what matplotlib does. Building docs 
+      themselves and supporting versions. NumPy and SciPy too.
+    - Sean: If we do something custom there are many possibilities.
+    - Doug: RTD is very responsive. Updates quickly.
+    - Michael: Can we push docs to RTD?
+    - Thomas: Was not possible when I looked, but may now. Can pay for hosting. 
+      Might be possible.
+    - Michael: Could use Sean's work, but just rework deployment.
+    - Sean: Agree.
+    - Mark: RTD business account could solve it.
+    - Sean: Not sure if we can build all of OCIO. Would have to do dependencies.
+    - John: Might be a good Andy question on RTD. Most projects using free 
+      tier, but if it's something projects want, can investigate. Some services 
+      have non-profit discounts.
+    - Carl: OIIO is on RTD; should check with Larry.
+    - Thomas: Basic price $50/month. Advanced $100/month.
+    - Michael: Any objection to Sean's approach with new deployment method? 
+    - Doug: Any current example of Python API override? Transitioning from 
+      previous system, so unless you see the output, it's hard to make final 
+      call. We've been discussing doxygen limitations. Either not converting 
+      header files properly, or some underlying problems.
+    - Patrick: API documentation quite broken now since mix of doxygen and 
+      previous approach. In C++ API, greatly increases size of headers. Would 
+      be good to have commitment if we stick to doxygen or stick to previous 
+      format since we have to mix right now. Not pleasant currently. Decision 
+      of syntax.
+    - Sean: Shouldn't need to mix rst and doxygen. Right now docs cmake target 
+      not generating API docs at all, since those features break RTD. From user 
+      standpoint should be handled on backend.
+    - Doug: Other point is how verbose we want to be if we convert to doxygen. 
+      Old docs were pretty minimal, for functions not needing explanation. 
+      Adding obvious comments will bloat the headers. Is that a change we want 
+      to make?
+    - Sean: Need to see what autodoc and breathe do. May do something default.
+    - Mark: Can docs be separated from header?
+    - Sean: Probably possible, current solution based on what breathe supports 
+      on sphinx side. Not sure.
+    - Patrick: Can a test be shared for analysis?
+    - Sean: Will do some cleanup and push something.
+
+* Foundry SDK usage in CI environment:
+    - Josh: Foundry asked about OCIO needing Foundry license for CI. Was that 
+      requested?
+    - Not that anyone is aware of. May be useful in future depending on how 
+      Foundry distribute plugins.
+
+* Ongoing priorities for stabilization period:
+    - Doug: Two components. Were looking to get feedback from implementors. Had 
+      some feedback with a logged issue. One main goal at SIGGRAPH was to raise 
+      awareness. Hopefully that message went out and starting to be looked at. 
+      Hopefully comments start trickling in are assigned to dev roadmaps.
+        - As people do have time to contribute, we'd like help with some 
+          issues. Will be posted to GH as help-wanted label issues. High 
+          priority items we need help with.
@@ -0,0 +1,222 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 28, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Nigel Hadley - Foundry
+  * [X] Simran Spiller
+
+Apologies:
+  * Kevin Wheatley
+  * Mark Titchener
+
+# **OCIO TSC Meeting Notes**
+
+* TAC update on GSoC. Focus for next year:
+    - Michael: Good feedback on results. Likely that ASWF will participate 
+      again next year and are hopful that all projects can get a project. 
+      Should start thinking about where to focus. CUDA, Metal renderer impl 
+      seems like a good place to try again on.
+    - Doug: Good to have volunteer for each project. Is Hacktoberfest 
+      happening again this year?
+    - Michael: Good question. I believe that was based on a tag search.
+
+* Issue #1117 -- Help Wanted:
+    - Doug: Added new label help-wanted. Others use this too. Can start adding 
+      this to high priority issues. This issue is to create OFX bindings for 
+      OCIO v2. High priority since it would increase test coverage with so many 
+      supporting apps. Could get more practitioners and developers to download 
+      and test those.
+    - Michael: OFX is supported by Nuke; Curious if it would create conflict 
+      with existing OCIO v1 binary in that env.
+
+* Open PRs: 
+    - 1147 (optimization):
+        - Doug: Updates config default version and optimization improvements. 
+          When create new config, it is now v2 by default instead of v1. Other 
+          thing in PR enhances optimization flags. Now ability to control types 
+          of optimization. Two new flags: one simplifies ops down to component 
+          parts; CDL without power becomes just matrix if possible, etc. 
+          Benefit is that can be combined with another matrix op. Another flag 
+          controls whether SSE log and power are used. Does much faster version 
+          of these functions but not 32-bit exact - 16-bit half precision. 
+          Useful to turn it on and off, and off for unit tests since we’re 
+          comparing with higher precision results.
+        - Bernard: Fast log is not used for baking.
+        - Mark: Why is SSE path not as precise? Because of writing own exponent 
+          functions etc?
+        - Patrick: Yes, wrote own implementation. Benefit in performance is so 
+          important that both approaches are supported.
+        - Doug: Uses fewer iterations than needed for full float 32-bit results.
+        - Mark: Had similar challenge getting this working in CTL expression 
+          code. Finding concise method of operations challenging. Since we 
+          already have concept of optimizations sounds fine. Is this default?
+        - Doug: Yes, both are turned on by default, in OPTIMIZATION_VERY_GOOD.
+        - Patrick: optimization is based on bits, so can disable any of the 
+          items. Fine control of optimization.
+    - 1157 (file transform interpolation):
+        - Doug: Prompted by issue (1121) from Remi. File transform will now use 
+          DEFAULT interpolation as default, instead of UNKNOWN, which prevents 
+          exceptions being thrown in various places. Also cleaned up some file 
+          transform interpolation. If you specify an interpolation that can't 
+          be used for file, will log warning. For CLF, where interpolation can 
+          be specified in file, if an op doesn't specify interpolation, it will 
+          try to use the FileTransform interpolation specified. Will ignore 
+          file transform if specified in file. Also addresses issue with 
+          caching. If multiple transforms used specify different 
+          interpolations, that will now work.
+        - Bernard: Also added a function to get the type of a transform (CDL, 
+          Matrix, etc.).
+        - Mark: Any reason to default interpolation to DEFAULT instead of BEST? 
+          Should we change it to BEST?
+        - Bernard: For 1D doesn't matter, but for 3D, difference between 
+          tetrahedral and trilinear.
+        - Mark: Should change to BEST to get tetrahedral.
+        - Bernard: If we want to use BEST all the time, change DEFAULT to BEST.
+        - Doug: Tetrahedral slower than trilinear, and GPUs do trilinear by 
+          default. CPU and GPU will match better and get faster behavior. 
+          Defaults usually land on faster. You can request tetrahedral in 
+          transform.
+        - Mark: Why use trilinear if tetrahedral is available? Now that 
+          tetrahedral is available on GPU.
+        - Doug: Still uncommon for other apps to use tetrahedral on GPU. 
+          Usually use trilinear.
+        - Mark: But we're bringing fantastic tetrahedral to the table.
+        - Doug: Trilinear would behave like other apps.
+        - Mark: Did old code default to DEFAULT or BEST?
+        - Doug: Used to be INTERP_UNKNOWN and would throw in evaluation.
+        - Mark: FileTransform would work out of the box. I’ve never seen it 
+          throw, and usually just give filepath.
+        - Doug: Would get through YAML ok, but throw on processor.
+        - Bernard: v1 initialized with UNKNOWN, perhaps YAML changes it?
+        - Patrick: We will validate if v1 throws if it is UNKNOWN.
+        - Michael: Same as Mark, never had to set it explicitly, maybe defaults 
+          in YAML parse?
+        - Mark: Think it defaults based on file type, 1D LUT, 3D LUT, CDL, etc.
+        - Doug: Will comment on this issue to see what happens in v1 to explain 
+          why behavior was what it was.
+        - Michael: Should we switch DEFAULT behavior?
+        - Mark: Seems odd to have DEFAULT and BEST, should just use BEST.
+        - Bernard: Same as defaulting to faster exponent in SSL because faster.
+        - Mark: In studio would pick tetrahedral every time.
+        - Michael: Agree with Mark on quality. 3D LUTs are touchy so will take 
+          any precision improvement we can get.
+        - Doug: Agree tetrahedral is best. Just a question of whether we want 
+          to make it default since its not usually the default.
+        - Michael: Have we done extensive benchmarking?
+        - Doug: On CPU tetrahedral is faster. On GPU it's a texture lookup. 
+          Benchmarking on GPU is involved. Not opposed to tetrahedral default. 
+          Do as separate PR. Want to get other eyes on it.
+        - **TODO**: Mark will open issue about changing default interpolation 
+          of 3D LUTs to tetrahedral (or BEST).
+    - 1140 (process):
+        - Michael: Doug and I have been working on revisions to this document. 
+          Good to get more eyes on it if you have time.
+
+* Open Source Project Management Discussion:
+    - Carol: Talking on and off in doc meeting about ASWF/open source. At what 
+      point does project get big enough to need project management. PMs help 
+      keep organized and on track. There’s a balance between process that 
+      creates more work and that that creates less work. Talking to PMs at 
+      Netflix. Seeing things that could be useful for us without creating nag 
+      structure putting more on our plates. Any thoughts about talking to 
+      people about this? Would it be beneficial for our projects? Looking at 
+      OCIO, but could be wider across ASWF.
+    - Doug: Think its an interesting idea. Surprised this isn't already a 
+      thing. Forging new ground, but worth exploring.
+    - Mark: I don't think it would be good. Never heard a OSS project at scale 
+      doing this. Think it would add democracy to already democratic process. 
+      Should ask LF.
+    - Carol: Have seen on this TSC that a few people spend a lot of time on 
+      project management, but as we move toward releasing v2, the constancy of 
+      our time may not be as full time long term. If we had process in place 
+      that was not dependent on Patrick tagging issues and following up on PRs. 
+      Interesting to here from patrick if that would be helpful.
+    - Doug: Comment on Mark’s point about asking LF. We did ask and there isn't 
+      a model to copy at this point. A lot in response to Thomas' issue about 
+      transparency and a roadmap, etc. That was the why.
+    - Carol: Yes, how can we make this easier. What is missing from what we do 
+      internally at company. Obvious thing is project management. Not that 
+      anyone hasn't done their job well. Realize project management can be boon 
+      if done well.
+    - Mark: Many OSS projects led by small group of developers rather than 
+      committee. In case of OCIO, may not align with everyone's goals from 
+      project. Some reason people don't know final goal is when features don't 
+      align with what we were expecting. OCIO’s goals are wider now. More 
+      needs to fill and goals to solve.
+    - Carol: All of that makes the case for project management.
+    - Mark: Think less bureaucracy is better. We haven't failed in mission to 
+      achieve goals. Can see why when someone sees lots of PRs that don't 
+      necessarily follow their world view, they would ask for clarification.
+    - Doug: When Thomas wrote the issue, it wasn't opposed to specific feature, 
+      just that it was being worked on without an issue having been created to 
+      communicate it. If project manager had attended that working group 
+      meeting, might have avoided the surprise. Project manager isn't there to 
+      set roadmap, just to communicate what is being worked on and what is the 
+      status. More of a communication type role.
+    - Carol: Agree. Hard to picture what it would look like. Wanted to get 
+      others take on it. Ok if the conclusion is that it's not helpful. Have 
+      worked with great PMs that have helped achieve goals, which is cool.
+    - Mark: Someone not knowing where an idea came from, ok to mention to that 
+      person when it was decided. If they weren't at meeting.
+    - Carol: Not saying anything is lacking, just looking for help and 
+      improvement on what is already great.
+    - Doug: Is part of agile development. If AD devs were doing work at AD, 
+      would have agile workflow and team with scrum master. That's a 
+      significant part of someone's job. Takes a lot of time. For OSS projects 
+      it is just developers. No QA, doc, scrum person. Why is that? Because 
+      it's developers showing up to work on these things, but when projects get 
+      big enough, these roles might be more helpful.
+    - Mark: It's different for AD devs since it is full time. For others it's 
+      people scratching their own itch and contributing it back. Other projects 
+      don't know goals, just hear that something new has been added. Don’t 
+      think its necessary. Can be a mess of bureaucracy and fail. If not broken 
+      don't fix it.
+    - Patrick: Two aspects to consider. Example of grading. We forgot to create 
+      issue early and someone outside of development could have commented that 
+      we forgot it. Also helpful to know where we stand. Are we close to v2, is 
+      documentation close, are Python bindings close? We don't have that. Not a 
+      problem, but information isn't somewhere for people checking in on project. 
+    - Mark: OSS projects - first thing to do is ask.
+    - Carol: Is that the best way to do it? If it could be done without 
+      bureaucracy, could it be an improvement? Could be en experiment. See 
+      opportunity. Once project grows it becomes a product, which OCIO has. A 
+      lot in industry depends on consistency, and project status is a positive.
+    - Michael: Curious what a PM opinion would be. No commitment, but just to 
+      get opinion.
+    - Carol: Would probably want to be a fly on the wall for a while.
+    - Michael: Even in consulting role would be helpful.
+    - Carol: Yes, keeping accountable. Don't want to add more process.
+    - Patrick: With projects and labels in GH we can do some project 
+      management. Took time to put labels to help see trends and see what 
+      remains to be done. We don't have what is missing, only what is done. 
+      Thinking about the missing part; we could find something with low 
+      overhead to have first version of project management.
+    - Carol: Agree. What would we need to take what we have and make system 
+      around it. Just needs a little work.
+    - Michael: Added feature development project which could be home to some of 
+      this.
+    - Mei: Can get Thomas' input next week, to see what he is more concerned 
+      with. Would be nice to talk to him about it. Can put on agenda.
+
+* Meeting time change for NZ daylight savings:
+    - Carl: Daylight savings, now is 9-10 am in NZ. Thomas and I may not be 
+      able to make it. Could move meeting.
+    - All: Ok with moving back an hour.
+    - **TODO**: Carl will reach out of Thomas to verify time and Michael will 
+      move meeting back one hour and update invites if helpful.
@@ -0,0 +1,130 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 5, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [ ] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Aymee Yeh - Netflix
+  * [X] J Schulte - Industrial Light & Magic
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+
+Apologies
+  * Doug Walker
+
+# **OCIO TSC Meeting Notes**
+
+* Review pending PRs:
+    - #1160 - C++ API docs:
+        - Initial work and structure of C++ API docs. Feedback on organization 
+          of content welcome. Can look at RST or build locally. Also includes 
+          some general CMake changes and removal of auto-install of 
+          documentation-specific dependencies.
+        - Patrick: Noticed this morning on tsc-private topic related to 
+          copyright of images found with license scan. Needs a look.
+    - #1159 - Improve CMake files:
+        - Patrick: Not C++. Faced issues with CMake on Windows and tried to 
+          fix.
+    - #1157 - FileTransform interpolation:
+        - Patrick: Last meeting discussed v1 not throwing if interpolation was 
+          missing. Bernard checked and it is throwing for FileTransform 
+          (i.e. LUTs) as expected.
+    - #1156 - Meeting minutes:
+        - Patrick: Needs another approval.
+
+* Introducing Aymee Yeh:
+    - Carol: Introducing Aymee to OCIO project. PM from Netflix who is 
+      interested in learning more about project management in open source. 
+    - Aymee: Work with Carol at Netflix on project management. Here to listen 
+      to see where I can help. 
+    - Carol: Provided some resources from GH repo.
+    - Michael: Please let us know if you have any questions. OCIO Slack 
+      workspace is a good place to discuss, and any ideas an input are very 
+      appreciated.
+
+* Issue #1162 - PROCESS.md feedback:
+    - Thomas: In a good place. Would be great to have more people giving 
+      feedback. Explicit approval better than silent assent.
+    - Carol: Also think it looks good, but will have another look.
+    - Patrick: To highlight, there's a trend in OSS that saying nothing means 
+      its fine, but sometimes better to have explicit approval in a comment to 
+      an issue or PR. Some feedback to know where you stand.
+    - Michael: "LGTM" is a good response if you're in agreement.
+    - Patrick: If you take time to read it, take a time to comment.
+    - Thomas: On GH, approval is a click away also.
+    - Mark B: Only comment is with big changes throughout development. Since 
+      PRs were dependent on each other, decided to wait till work was more 
+      complete to review. Have some concerns that there's not enough time to 
+      vet work while pushing towards release date.
+    - Patrick: Good concern, and why we have 4 month stabilization period to 
+      test and dig into what we did. Up to you to tell us. We did our best to 
+      explain and add tests, which are also a way to explain the features. 
+      Please tell us if something is unclear or a concern.
+    - J: Understood. Sometimes huge wave of commits takes a lot of time to 
+      review. Good buffer to look and rethink it.
+    - Michael: Good to take time to review PRs if you can since it's easier to 
+      adjust work in progress than completed work. Probably too late to change
+      architectural decisions.
+    - Patrick: Best to start with unit tests and public API to get sense of 
+      features and changes. Can also start with Python. Start with something 
+      you are familiar with. 
+    - Thomas: Whenever not finding something in Python code, looking at C++ 
+      unit tests and that is very helpful.
+    - Mark B: Lots of stuff from previous TSC meetings and working group 
+      meetings where it's hard to track outcome of discussions. Not sure 
+      whether those changes were addressed or gone over. Need to check up on a 
+      lot of stuff and follow through. No issue with architectural stuff so 
+      much. Two or three things to follow up on though. Worried our concerns 
+      will be lost because of imposed deadline. Would be a shame if features 
+      go out if solutions doesn't match spirit of previous library version.
+    - Mark T: What things are you concerned about?
+    - Mark B: ICC display transforms. Live grading controls and how those 
+      interact. Environment resolution. Bit-depth - how it's expressed in graph 
+      and config.
+    - Patrick: Suggestion - build a list and next TSC meeting would like to 
+      discuss these points. We can address questions over several meetings. 
+      Even if we did some WG sessions and created defects for all the features, 
+      we could still explain again what we all agreed to do and follow up on 
+      any concerns.
+    - All: Agree this is a good idea.
+    - Mark: T: Others can look at areas of concerns too.
+    - Patrick: Yes, we are waiting and eager to have more eyes on what we did.
+    - Michael: Lots of little pieces have come together, so understood that 
+      it's easier to review larger features now that they are complete.
+    - J: Continuity of involvement has been challenge, with big waves of work.
+    - **TODO**: Mark B and others to provide list of features for review with 
+      AD team during future TSC meetings. Similar discussion to v2 working 
+      group.
+    
+* ACES Gamut Mapping Quick Update - for FYI:
+    - Carol: Matthias and I co-chairing gamut mapping wg. We put out a status 
+      update and will share a link. We're getting close to moving on to 
+      implementation of the algorithm as long as user testing goes well. 
+      There's a test impl on GH: 
+      https://community.acescentral.com/t/aces-gamut-mapping-vwg-status-update/3259
+      which can be tested in Nuke, Baselight, Python, etc. Hoping to get into 
+      OCIO v2 as builtin transform. Imagining OCIO big use case for this 
+      operator in lots of VFX spaces. More complicated than a 3D LUT.
+    - Matthias: Main reason for this implementation is precision, in particular 
+      for inverting the transform. Is possible to implement in OCIO v1 with 
+      shaper space potentially, but precision is compromised and made 
+      non-invertible. Much more desirable to be evaluated as builtin transform. 
+      Not super complicated on processing side, shouldn't slow things down.
+    - Carol: May be asking for input in best way to implement, probably 
+      starting early next year. Getting user testing done in the next month. 
+      Finalizing architecture deliverable to Academy, which is CTL by end of 
+      year.
@@ -0,0 +1,76 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 12, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [ ] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Aymee Yeh - Netflix
+
+Apologies:
+  * Patrick Hodoul
+  * Doug Walker
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* PRs ready for review:
+    - #1157: FileTransform interpolation - to be merged tomorrow without 
+      objections.
+    - #1159: CMake updated - to be merged tomorrow without objections.
+    - #1163: BuildOps functions refactoring - new PR from Bernard 
+      simplifying some op build code.
+    - #1164: app docs - Documentation contribution from Zach Lewis.
+
+* Issue #161 feedback:
+    - Michael: Continuing discussion around PROCESS.md and any revision 
+      that might be needed. Larry raised good points around 
+      implementing a feature freeze to prevent holiday and near-release
+      merges without review.
+    - Mark T: Agree. Would provide a good to have safety net.
+    - Kevin: Two issues, feature freeze before major release, and then freeze 
+      where people will be away, to prevent magic PR approval over holidays. 
+      Both make sense. Don't want these merges to happen by accident.
+    - Carol: Can 2-week window be extended after OCIO v2 release? Lengthen to 
+      3 or 4 weeks. With release nearing completion this could be less of an 
+      issue. Will add comment to issue.
+    - Michael: Agree.
+    - Kevin: After v2 there will be fewer things to review, so the current rule 
+      may be ok.
+    - Carol: You would expect more people to comment, and less PRs to go 
+      through without comment. Ideal is no PR without feedback.
+    - Michael: Bigger features need more review, i.e. expressions. Smaller work
+      like bug fixes could go through quicker potentially.
+    - Mark: I agree as well. The way it is now is mostly because there are 3 AD 
+      employees, who could approve and merge otherwise. Time period is chance 
+      to give us time to step in. Will change when AD contributions change.
+    - Michael: We can revisit the rules following release if needed.
+
+* RTD credentials and account:
+    - Michael: Does anyone here have credentials to get into the OCIO RTD 
+      account? I'm working on API docs and will need to do some tests.
+    - Carol, Mark: Sean has credentials.
+
+* Topics for AD feedback:
+    - Michael: Last week discussed raising concerns for discussion with AD team
+      on v2 features. Everyone will be back in the TSC meeting next week. 
+      Please post discussion points somewhere for discussion.
+    - Mark: Going through API over last week trying to implement ACES builtin 
+      transforms. Have Google doc with current questions and will add to next 
+      week's agenda. Also noted in tests that the v2 build is very smooth now.
+    - Michael: Are you using the external dependencies, or linking to local 
+      dependencies.
+    - Mark: Using the external libs, statically linked. Namespace handling is
+      working well.
@@ -0,0 +1,121 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 19, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] J Schulte - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF usage/feedback survey questions for OCIO:
+    - Michael: ASWF will be sending out a survey on project usage/feedback and 
+      asking that we provide OCIO specific questions we want industry input on.
+      Any specific questions you would like feedback on?
+    - Mark B: Feature usage. How many users create configs from scratch vs. use 
+      distributed configs. How many use and rely on context variables and look 
+      transforms? How many use look transform expression language?
+    - Carol: What software do you most use OCIO in?
+    - Mark B: Any areas of color management we aren't helping with? Do you 
+      build OCIO or rely on package manager. Do you need to replace builtin 
+      OCIO shipping with DCC?
+    - Michael: OCIO v2 transition concerns?
+    - J: Any requirement for specialized documentation? UX/UI convention 
+      document, etc? Any more levels of docs that help people get on board.
+    - Mark B: Are you aware of documentation efforts and new website?
+
+* New PRs:
+    - #1172: Improve the FileRules behavior for some limited cases:
+        - Patrick: Fixes inconsistencies with file rules after using and 
+          documenting them. Small change.
+        - Doug: How to handle case where string is empty - no rule. An edge 
+          case.
+    - #1171: Change the ICC monitor profile reader:
+        - Patrick: Bug discovered by Rémi. Fixed.
+    - Doug: Going to create issue for cleanup - removing unknown direction 
+      enum. Will clean up a lot of code and be better for error handling. 
+      Errors will show up at parse time instead of evaluation time.
+    - Patrick: Pasted PRs in Slack awaiting feedback.
+
+* General discussion:
+    - Doug: Anyone watching VIEW conference? Like FMX, European VFX conference 
+      in Italy. Free this year. Rob Bredow did a session and gave shout out to 
+      ASWF and OCIO. Encouraged people that ASWF is a great way to get 
+      involved. Encouraging to see support for the project.
+    - Patrick: New contributor with work to look at. PR #1169.
+    - Michael: Since October is almost over, what is the timeline for 
+      stabilization period? Are we targeting end of year or looking to push 
+      into new year?
+    - Doug: Good topic for future TSC meeting. A number of projects have been 
+      accepted into VFX ref platform 2021, with releases at end of year or 
+      early next year. OpenEXR 3, OpenVDB 8. Talked with Larry about how he 
+      releases OIIO (RC releases, etc.). Think it's a decision for TSC, about 
+      when release will be. Will certainly need 2.0.1 next year for bug fixes. 
+      Hoped to get a lot of testing this fall, opportunity to fix bugs for 
+      release. If we could extend into next year will help with stability. VFX 
+      ref platform starts in calendar year.
+    - Michael: Any work on integration at Foundry?
+    - Mark T: A bit, but waiting for engineering team to free up off another 
+      project. Will start investigating Nuke integration in coming weeks. 
+      Hopefully can make good progress.
+    - Michael: Is Autodesk working on implementation? Deciding what to do in 
+      terms of UI/UX will be a discussion point, since not much has been done 
+      yet with related new features.
+    - Doug: We are looking at it, but requires more documentation. UI one of 
+      biggest ways to take advantage of new features.
+    - Mark B: For studio to upgrade, the last app to use v1 has to disappear. 
+      Probably a long lead time.
+    - Doug: Is it possible to have two configs side by side? v1 and v2?
+    - Mark: Depends how complex. Not ideal.
+    - Michael: I have been answering questions for an SPI engineer looking at
+      v2 integration. He might be a good source of feedback.
+    - Mei: Yes, we have a developer looking into it. Installed and playing 
+      around with it. Will have more feedback soon.
+    - Carol: At Netflix people very excited about new ACES config and config 
+      generation tools. Most conversations around that. When those tools are 
+      ready to pick up, will be time that dev work would happen.
+    - Michael: Reminder that the next config working group meeting is tomorrow.
+      Now alternating weeks with the documentation working group to free up 
+      schedules a bit.
+    - Patrick: Related to UI - have a look at the code. Have apphelpers static 
+      lib to help. C++ only. Demonstrates how to filter color spaces, how to 
+      present them, color picker, etc. See if it fits your needs.
+    - Mark T: From Zoom chat: Any work on OFX reference yet?
+    - Doug: Someone was going to get started but hasn't panned out. Updated 
+      issue and someone else expressed interest. Student so may need some help. 
+      Anyone want to collaborate? Would be welcome.
+    - Michael: OFX plugins will be a big job, and are a good opportunity for a 
+      UX first pass if anyone has strong opinions on that.
+    - J: OFX example could be really valuable for UX/UI, making sure a tool 
+      embodies all of that, as reference. Having something usable beyond docs 
+      would be good to evangelize the work. 
+    - Michael: Agree. Good opportunity to help steer the UX work.
+    - Doug: Told interested contributor first pass could be simple and second 
+      pass can refine UI. Break work into milestones. First PR might be bones, 
+      and then several could collaborate on how UI should work.
+    - Mark T, J: Interested in helping with that. Could help test and feedback 
+      designs. 
+    - **TODO**: Michael will open an issue to discuss. Can help DCCs be 
+      consistent.
+    - J: Hopefully enough stuff for new developers. Standards, etc.
+    - Doug: Alluding to this with documentation. UI mockups could find way into 
+      docs and tutorial. How to build UI for OCIO v2.
+    - Carol: Would be great. The more visual the better.
+
+* Items for next TSC meeting agenda:
+    - **TODO**: Mark B organizing OCIO v2 feature discussion points. Will add 
+      to agenda next week.
@@ -0,0 +1,82 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+October 26, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* Survey questions
+    - Patrick: At the TAC meeting last week there was discussion around ASWF 
+      survey and project questions. Categorization and multiple choice are 
+      the main areas to improve.
+    - Michael: Yes, will need to pare down question somewhat and make multiple 
+      choice where possible to reduce time commitment to fill out. I can work 
+      on converting them to multiple choice, but please comment if you think 
+      any could be reduced or removed. We can ask any other questions we have 
+      within the OCIO community.
+
+* API documentation status update:
+    - Michael: Finalizing Python API doc setup. Python module which walks 
+      Doxygen XML and generates header matching pybind11_mkdoc. Working on 
+      updating DOC references in binding source, which is time consuming. Will
+      open PR once that's done. Will need to revisit bindings to add 
+      Python-specific documentation in a later PR.
+    - Patrick: For Doxygen extraction: any limitations to doxygen features 
+      that can be used? Want to update docs as we're adding stuff.
+    - Michael: The XML conversion module will fail if it hits an unhandled 
+      element, which will help keep it up to date to support any Doxygen 
+      features we need. Code is fairly simple to update, so can be done as 
+      needed.
+    - Michael: I have not dug into RTD side of docs yet as I don't have access. 
+    - Sean: I tried to add you but didn't find your RTD account. I can try 
+      again.
+    - **TODO**: Michael will create RTD account so Sean can add it.
+
+* PR/issue discussion:
+    - Patrick: Nothing complex right now.
+    - Doug: Mostly bug fixes or minor improvements.
+    - Patrick: Opened issue about vcpkg (#1179). Good to put attention on it. 
+      vcpkg is broken for v1. Should update to work for v2. If someone has 
+      knowledge, should be simple to fix. Could also fix v1 if there's time. 
+      All the needed info is linked in the issue.
+
+* OCIO v2 discussion:
+    - Mark: Going through v2 updates and making notes. Going to write it up 
+      and share for next week. Some little style things. Some fundamental 
+      things for discussion.
+    - Michael: Anything to report from current AD efforts?
+    - Doug: Next week will give an update and share some slides. We're busy 
+      working on v2 stuff. Not feature related, but one feature mentioned in 
+      last v2 working group meeting will have PR. This work is documented in 
+      a GH issue already.
+    - Carol: Larry gave OCIO a very nice shout out in ASWF slack - general 
+      channel. Have a look when you can.
+
+* Python minimum version:
+    - Mark B: Is there a minimum supported Python version in the new bindings? 
+      Ran into an odd Python 3.6/3.7 issue, but think is was environment 
+      related. Some of Python's threading API must have changed between these
+      versions.
+    - Michael: OCIO Python bindings support down to 2.7, but docs require 3. 
+      It's only our sphinx theme that limits docs to 3, which is unfortunate.
+      I ran into a Python env issue as well recently. I was building OCIO on 
+      Linux subsystem for Windows, but didn't have python-dev installed (only 
+      python). The CMake find module grabbed libs from my Windows Python 
+      install from the Linux side, which failed.
@@ -0,0 +1,206 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 2, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] J Schulte - Industrial Light & Magic
+
+Apologies:
+  Carol Payne
+
+# **OCIO TSC Meeting Notes**
+
+* ILM’s v2 questions
+    - Doc: https://docs.google.com/document/d/11obAVucrsJ3e5HMuR40GD8fLUGAwwfbWD_jU5xId07Y
+    - Mark B: Feedback on:
+        - Dynamic and grading Transforms:
+            - What these are trying to represent as building blocks in OCIO. 
+              Who is the target user? Useful for color sub-tasks, but not 
+              necessarily a core goal of OCIO.
+            - See conversation below...
+        - LogCameraTransform:
+            - Parameters on transform don't coincide nicely with camera 
+              whitepapers or reference transforms. We understand the 
+              translation but a bit of a closed box to those authoring 
+              configs. Future of this transform - will additional curve 
+              characteristics be needed?
+        - GetEnvVariables:
+            - New get/set env vars. Do they need to be in OCIO API?
+        - etc.
+
+* Dynamic and grading Transform discussion:
+    - Mark B: For wider world, why are our attributes for transforms different 
+      from other implementations? Might impose worldview on grading which 
+      doesn't reflect industry.
+    - Doug: A lot of discussion about this. Motivation explained in GH issue. 
+      Not intended to change what OCIO is used for. OCIO already has ASC CDL 
+      and Lut3D transforms, which are used for looks typically. Felt there was 
+      a gap between those extremes. Felt need for other transforms to fit 
+      between those and have advantages of both. Wasn't to change OCIO or its 
+      usage. One thing at meeting that raised a lot of discussion was not about 
+      transform themselves, but the dynamic parameters that were part of them. 
+      To modify transforms with dynamic parameters. Main reason for this is to 
+      make OCIO more usable in GPU scenarios. Without this, every change needs 
+      re-compile of shader, which was a major blocker for some GPU application 
+      usage.
+    - Mark B: Main place we differ is nobody is authoring looks in OCIO. Being 
+      done in other apps. OCIO responsible for using them only. Grading 
+      transforms don't have file equivalent, that someone might want to 
+      implement. Not on same parallel in our view. CDLTransform could fall into 
+      this too, since FileTransform can handle a CDL. Custom shader code can 
+      be glued into shader.
+    - Kevin: We would love to have done dynamic adjustments in single step. 
+      We're trying to do this in our playback/review tool. Much cleaner than 
+      jumping back and forth. Would be nice to be able to plug something in. 
+      Would also be nice if there was an agreed upon spec of what these 
+      grading controls meant. Do like being able to do real time adjustment of 
+      transforms, since we do that.
+    - Mark B: DCC authors could need this, but not config authors. Don't see a 
+      config file equivalent to some of these knobs. Would love all of this as 
+      a DCC author, since it simplifies implementation, but not a lot of that 
+      problem in OCIO. Makes OCIO more complex and more uncertain of use case.
+    - Kevin: Had not made strict limitation on where boundary should lie. 
+      Without grading transforms, dynamic parameters allow you to do thing 
+      like control where an exposure change is happening. Mostly temporary 
+      adjustments. Some of the grading transforms allow me to do things where 
+      I have previously had to bake LUT, so idea of parameterized methods is 
+      useful. I'm in the middle somewhere. Think grading transform naming is 
+      wrong and misleading.
+    - Mark B: Current impl with DisplayTransform controlling where pieces are 
+      dynamic had idea of limiting (gamma, exposure) adjustments. Maybe we need 
+      more display transforms which ensure the knobs are in the proper place. 
+      Do like building block transforms to replace need for LUTs.
+    - Kevin: Yes, low level ops to support this. Isn't it up to config author 
+      to choose where to express the dynamic parameters? The way these two 
+      features come together is what creates a risky area.
+    - Doug: Yes, there is a specific tag to make things dynamic.
+    - Mark B: New building blocks could be confusing. Grading transforms don't 
+      have file to back them up.
+    - Doug: CTF format could be used.
+    - Kevin: Concern with these transforms is they are not standardized. Not a 
+      big deal having additional transformations.
+    - J: BLG is a black box, but fills a need in industry. CDL doesn't do that. 
+      We like fixed pipeline, and limited input to what can be changed. CDL has 
+      been building block for this. Who makes and communicates these decisions? 
+      How do we know what the right version for a parameter number is? Does 
+      that fit into OCIO core concepts?
+    - Mark B: Would expect to being given CTF rather than a grading transforms 
+      with dynamic parameters set.
+    - Doug: Wouldn't be handed config with dynamic parameters and expect them 
+      to edit it. Understand the concerns, but don't see how grading transforms 
+      are different from CDL in that regard.
+    - Mark B: The workflows it introduces are a big shift in the tool. If 
+      someone adjusts in their config and send the config without those 
+      numbers, there's an extra bit to account for.
+    - Kevin: If I got a config file with parameters that would be helpful. At 
+      moment we get CDLs and stuff that should match, but they don't sometimes.
+    - J: The variability of these controls is something to help facilitate 
+      re-baking LUTs. There's value in this, but our concern is this will 
+      create dynamic version of this OCIO experience that is not intended. Can 
+      forsee a future that used builtin grading tool that uses these transforms 
+      and export that to handoff to studios, but would be a nightmare. 
+    - Mark B: Or combining grading transforms in row. What will that mean?
+    - Kevin: Nothing stopping onset grading from baking out CLF/CTF files, so 
+      not that different.
+    - J: Not sure if fix for these problems should exist in OCIO. Concern from 
+      supervising standpoint that we'll have multiple versions of a color 
+      pipeline, since it's no longer static. If Foundry opens up these tools to 
+      artists for example, that would have big effect. Not what OCIO 
+      foundationally supported.
+    - Doug: Distinction want to emphasize is that Nuke right now allows editing 
+      CDL, but there is no way to insert that back into a config and write out 
+      a new one. Would be same thing with grading transforms. Someone could use 
+      this and save it, but would they be allowed to edit a config?
+    - J: Don't want people affecting the state of color. Shouldn't allow means 
+      to affect that change, since that's not something we would do in our 
+      workflow. Some industries may need this though.
+    - Mark B: Concern is that they can be put in config. Perhaps some parts of 
+      OCIO are for DCC tools and others for rigid color pipelines. Not sure how 
+      you can merge those things.
+    - Doug: What's the concern about transforms vs non?
+    - MArk: Transforms can be put in configs, whereas tools are for display.
+    - Doug: Use case was for these to be put in configs, with advantages over 
+      CDL.
+    - Michael: The use cases I have seen are for supes to create CDLs for looks
+      in a review session, which can then be passed off and used in shots or in
+      the config. The implementation is specific to a custom tool, but not 
+      something that would be exposed in DCCs. Not needing to rebuild shader 
+      interactively a big gain for this workflow.
+    - Doug: Not a requirement for DCCs to make these editable. Don't see that 
+      happening. Not likely DCC is going to browse a config, edit it, and write 
+      it back out.
+    - Mark B: Not concerned about writing back out; more concerned about artist 
+      changing stuff in display pipeline.
+    - Doug: Would be surprised if DCC allowed you to edit looks.
+    - Mark B: If you're a DCC author, there's a different track, but that 
+      problem is unrelated to config author and those maintaining transform 
+      hierarchy.
+    - Sean: your thought is then that OCIO should only take image to certain 
+      point? If review tool did want dynamic parameters, it handles it on its 
+      own and then hands off to OCIO. Seems like more room for error. Nice to 
+      handle it in OCIO where transform is consistent. I see both sides points, 
+      but final control of pixels is a bit exaggerated. Every DCC has exposure 
+      and gamma slider. No concern that when I tweak those I am tweaking the 
+      config. Imagining an OCIO display with two views, one with the canonical 
+      look, and another called "editable". You would have tw switch between 
+      them, allowing a supe to make creative decisions when needed, but would 
+      require explicit switching between display chains. Don't see any 
+      operation which would require editing the original config.
+    - Mark B: Not about editing the config; about expressing changes made when 
+      editing. 
+    - Sean: CDL-centric workflow for example. Would need to bake the changes 
+      into a file (CTF) which could be referenced. Hard though since you can't 
+      switch between dynamic and file transform. Like that this gives more 
+      capability than what a CDL can, but am safe in knowledge that decisions 
+      can be reproduced.
+    - Mark B: New file format can be designed by ACES to handle additional 
+      changes. Just problem with live aspect.
+    - Sean: Natural extension of DisplayTransform. Causing more issues since 
+      can be placed anywhere in config.
+    - Doug: The dynamic aspect is what seems to be most troubling. See that as 
+      an implementation detail. There's nothing preventing an application from 
+      editing parameters. The dynamic parameter is only there to allow doing it 
+      interactively with GPU. Could bake out new transform continually. Whether 
+      something can be edited is separate from whether developer uses these 
+      tools.
+    - Mark B: A DCC author will implement it at some point.
+    - Doug: Most tools already have CDL transform.
+    - Mark B: But none allow you to edit it live.
+    - Doug: Dynamic feature there as a convenience. There because of exposure 
+      contrast in viewing pipeline. That tag is there to say doing exposure at 
+      front and gamma at back. Doesn't need to be there for grading parameters.
+    - Kevin: Can do dynamic functionality right now with search paths, etc. We 
+      abuse that for CDL selection, an explicit choice.
+    - Doug: Thanks for the feedback. We have response for all of these. In 
+      terms of written response, would you like answers in this doc, or in 
+      separate doc?
+    - J: Separate doc is preferred.
+    - Michael: Will be good to share these topics and conversation with wider 
+      community too, for additional input. We can continue this discussion 
+      after we all have time to think through the concerns raised.
+    - **Update:** After the meeting, Doug provided a written response to the 
+      ILM questions: 
+      https://docs.google.com/document/d/1HeA9fJvrxAVoUQ3M1p8K3gAgd7cLkHUmChCoPfmyZvQ/edit?usp=sharing
+
+* Items for next TSC meeting agenda:
+    - Overview of new PRs (1183, 1184, 1189)
+        - #1183 - Add operator << for FormatMetadata
+        - #1184 - Description in config files
+        - #1189 - Named color transforms
+    - CUDA support
@@ -0,0 +1,251 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 9, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] J Schulte - Industrial Light & Magic
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* Response to ILM questions:
+    - Doug: Wrote up answers for ILM, provided doc in last week's TSC notes. 
+      Also created issue #1199 to facilitate discussion on topics.
+
+* Overview of new PRs:
+    - #1183 - Add operator << for FormatMetadata:
+        - Doug: Making more convenient to access file format metadata from 
+          python. Maps to `__repr__` in python.
+    - #1184 - Description in Config files
+        - Doug: Improved descriptions in config files. Cases where single or 
+          multiline desc for color space, etc. Cleans up handling of those and 
+          adds unit tests.
+    - #1189 - Named color transforms
+        - Doug: Issue #1101, discussed at August v2 wg meeting. Sharing slides 
+          from wg meeting. How to integrate legacy transforms into OCIO. 
+          Sometimes users just want to apply gamma or log-to-lin (with no 
+          matrix). But want to specify them in OCIO config and access via OCIO 
+          tools. Example: "Utility Curve/Shaper" color spaces in ACES config, 
+          which are kind of broken (i.e. only a shaper if going to ACES2065-1).
+            - Add named transforms section to config. Authors can define these 
+              transforms in that area. ACES config has these transforms, 
+              represented as color spaces, but problematic if you're not 
+              starting from the right color space. These curve/shaper color 
+              spaces could then become named transforms instead.
+            - Apps could provide plug-in for accessing named transforms, or use 
+              with ColorSpaceTransform or DisplayViewTransforms. They do not 
+              show up in color space menus by default.
+            - In ColorSpaceTransform and DisplayViewTransform, accepted like 
+              color spaces as arguments to these transforms. Would bypass the 
+              "other half" of the conversion. e.g. 
+              ColorSpaceTransform("Utility - Curve - sRGB", "ACEScg") -> apply 
+              the named transform and consider the result as ACEScg.
+            - As mentioned in previous meeting, open to other proposals for 
+              how to handle this, but nothing has been presented. Made very 
+              clear that this is a hard requirement and want to do it within 
+              OCIO rather than as separate tool. See issue and PR for more 
+              info.
+        - Mark B: Not excited about it. Not part of config authoring process 
+          so can't see how chain of operations ties together. Highlighted by 
+          ACES config, which ref color space is ACES2065-1, but people want to 
+          work in ACEScg, so problematic with the extra matrix and color shift. 
+          What users have hard requirement?
+        - Doug: From users of thing like Maya and Flame, CG animation and 
+          rendering, or finishing or compositing.
+        - J: More dangerous in those applications. Easier for UX, but breaks 
+          fundamental rules of moving to color managed process.
+        - Doug: In big facility with color scientist, makes sense. A lot of 
+          users don't have that. Proponent of the benefits of working proper 
+          color managed way, but a lot of our users have not gotten to that 
+          point yet. Looking in OCIO example configs repo, one is called 
+          nuke-default, a Foundry config, made up of these sort of utility 
+          transforms as well.
+        - J/Mark B: Legacy config, made to allow continuation of Nuke workflows 
+          with OCIO. Just proof of concepts to get Nuke color management 
+          outside of Nuke.
+        - Mark T: Just to replicate Nuke color management system.
+        - Doug: Not recommending this approach, just saying it's a reality that 
+          a lot of people want to work this way. Because of legacy. Users 5-10 
+          years behind state of art.
+        - Mark B: Talking about OCIO, not legacy workflows. Don't want to 
+          enshrine these workflows, allow people to break the model.
+        - Carol: If not using the standard ACES config, using nuke-default, not 
+          making own configs. If you're trying to get facilities caught up in a 
+          non-disruptive way, this would be an ok way to do that since it's 
+          saying what it is explicitly. Not getting unintended results. I Like 
+          that.
+        - Mark B: Disagree. This is enabling people. Those that don't 
+          understand color management are not are not going to be set right by 
+          named transforms. Going to be enabled to work how they want and think 
+          they have OCIO blessing. OCIO is an opinionated color management 
+          library, not just a toolbox.
+        - J: Valid question, is there an appetite for something like this as a 
+          guiding path? Love to get input on that. Everyone has valid point of 
+          view, but as a whole, what is the missions statement here? Are we 
+          willing to compromise OCIO principles, or are there decisions and 
+          workflows we want the industry to move into?
+        - Doug: To clarify, think its clear users feel a need for this. It's in 
+          the ACES config for a reason. Not that we're encouraging this, just 
+          calling it what it is. Right now masquerading these as color spaces, 
+          but they aren't. Reality that some want these and we should not call 
+          them color spaces. If you're worried about encouraging this behavior, 
+          I don't see that. See it as making it clearer to people how to do 
+          color management. If you say we don't want you to use named 
+          transforms, clear way to talk about the scenario. Don't want to frame 
+          the question as: is this a good idea for color management? Most on 
+          same page to not recommend it. If they are going to do it, and ACES 
+          config has it, and should be called what they are.
+        - Mark B: Color spaces are a simplification to allow talking about 
+          OCIO. Just a block in chain that joins images together.
+        - Carol: Should be explicit though, call this what it is, not a color 
+          space.
+        - MArk B: Increasing complexity with little benefit.
+        - Matthias: Sort of agree with Carol. Agree having them in there as 
+          first class citizen potentially perpetuating workflow and simplistic 
+          interpretation of color management to avoid. Don't like to 
+          compromise, but if have to have it, see benefit of it being explicit.
+        - Mark B: Who needs it other than the config author? If you're the 
+          author you know where you need to_ref and from_ref. Current toolkit 
+          not complex and solves all these problems without extra level.
+        - Carol: Another group pf people sit between authors and users. Those 
+          that don't have someone to write config for them and need to 
+          understand the config. This would aid those people and it's a big. 
+          Not everyone can be a config author, requires skill not all have. 
+          Need to support them.
+        - J: The question is what is OCIO, who does it serve? A lot of that 
+          user experience is driven by applications that use OCIO. What do we 
+          want to enable those workflows to be like in OCIO. If there's a need 
+          for these, that's a thing. But does OCIO have an opinion about this? 
+          Or do we sacrifice some of that to give users accessible use of OCIO?
+        - Matthias: Look at it from different point of view. Having transform 
+          is one thing. Doug, any idea what would look like when presented to 
+          end user, in say... Nuke. OCIOColorSpace node would not have this. 
+          Doesn't fit there. Would it be a separate thing? Just an OCIO 
+          transform or legacy transform?
+        - Doug: Will vary based on application and task. For example, if 
+          importing something into proper color managed env. If using Maya and 
+          ACEScg as rendering space. May want to bring something in and call 
+          it ACEScg, but you're not sure what the original texture is. Don't 
+          have info so going to apply inverse gamma curve and call it ACEScg. 
+          Same workflow as textures where you do know color space. May have 
+          other scenarios where want to apply transform itself like 
+          FileTransform.
+        - Kevin: If I know how to read config, and just want to get transform, 
+          this is a convenience. File transforms don't encapsulate all new 
+          transforms, so harder to put this in file.
+        - Mark: Config author could do that.
+        - Kevin: Convenience for mocking up a config, but once done, not have 
+          it. Could create separate Nuke node with obscure name for special 
+          use, but not to be used by default. 
+        - Matthias: Feels like amalgamation of old Nuke 1D input color space 
+          for read node, and the new ability to use specific color space. Feels 
+          like jamming those two workflows together. Could cause confusion down 
+          the line, if you have color managed workflow.
+        - J: From user perspective, having one thing that does full transform, 
+          or one that does just the 1D path, does this make it harder for 
+          people? User may not know what the differences are. Are we making it 
+          harder?
+        - Carol: Like the analogy of using this in place where would have used 
+          FileTransform before. As simple as that.
+        - Mark B: Who uses raw file transforms though? If this is just a 
+          shortcut to a 1D LUT.
+        - Kevin: If it was just 1D LUT, no point, but encapsulating other 
+          transforms has more benefit. Have a lot of users who will try to 
+          decipher how to get between two images. Would be handy for that. Once 
+          you figure it out, put it into color space.
+        - Carol: For many users, try in Nuke to figure out what happened, get 
+          to place of confidence of where they are at, and work on image.
+        - Doug: A lot of people on OCIO/ACES forums that don't understand how 
+          OCIO config works, but in positron of having to use it to solve 
+          problems. Think there are a lot of those people out there.
+        - Matthias: Maybe needs clear distinction that this is not a color 
+          space, with no to and from ref, just forward or reverse with name.
+        - J: How do you solve this without offering up these workflows. At 
+          least gives them something over nothing.
+        - Mark B: Just documentation, teaching how to use it. Adding named 
+          transforms not going to improve that.
+        - Doug: Don't see how to solve this with documentation. Would need huge 
+          number of color spaces, for this audience who aren't config authors. 
+          If these are color spaces, would need every possible combination of 
+          color space and non-linearity. Another workflow is unfortunately that 
+          some apps allow a color transform where you specify independently a 
+          matrix and a non-linearity. Can create a lot of trouble by mixing and 
+          matching weird combinations. Sometimes people get things from these 
+          other software. Nightmare to include every combination, but with 
+          named transform, have way of undoing what had been done.
+        - Carol: Seems like added complication, but could look at it as 
+          building block of step in direction of where we want to be. More 
+          educated users knowing what they are doing in color managed scenario. 
+          Until we get to that point, could view this as interim. Helps to 
+          teach and educate. Like in ACES gamut mapping wg, all agree it's not 
+          ideal, but we have to do what helps.
+        - Mark B: Having multiple named transforms to reconcile error from 
+          another user. Are you anticipating a user assigning multiple named 
+          transforms in Maya UI, or still picking single transforms from named 
+          lists. If the later, still at mercy of config author, at which point 
+          it's just a doc or training session to explain choices. 
+        - Doug: Tried providing combinations in SynColor, many options, huge 
+          list of matrix and log-to-lin combinations and nightmare to deal 
+          with. Not desireable way of solving the problem.
+        - J: Does TSC have a point of view on what color space interaction and 
+          user experience should be.
+        - Michael: Think that's an important topic for discussion. Created 
+          issue #1174 for UX discussion where some of this could be determined.
+        - Kevin: What I really need is a Nuke node, op builder, to put ops in 
+          a row.
+        - Michael: Suggested a GSoC project to create OCIO GUI last year for 
+          exactly that reason. Would be awesome to have visual method for 
+          authoring configs.
+            - Let's bookmark this conversation for next week. Gives us time to 
+              think this through more and can follow up to make an agreement.
+
+* CUDA support:
+    - Doug: Larry brought up topic about CUDA support, pressing issue for 
+      OSL and a number of CG rednderers. 
+    - Michael: We should follow up with Dennis about his OpenCL renderer. Could 
+      perhaps influence other GPU compute implementations like Metal, Vulkan, 
+      etc.
+    - Mark B: Think this need is dying, since we now have OpenGL compute 
+      shader.
+    - Michael: CUDA requirement might be tied to OptiX. Could also explore 
+      tools to emit to multiple APIs. Spir-V.
+    - Mark: Spir-V builder needs large dependency graph, needs LLVM. Not stable 
+      dependencies.
+    - Patrick: Something to keep in mind. A lot of effort in current impl to 
+      not have direct OpenGL dependency in core. Clear distinction between core 
+      and shader language. Try to keep that. Advantage of OCIO.
+    - Michael: Could be like OIIO which has plugins depending on optional 
+      dependencies. More ideal to only depend on runtime though.
+    - Mark B: Windows has HLSL, Mac has Metal. Don't want to support all that 
+      stuff in the GPU impl. Emitting HLSL on Linux, etc. Could have call to 
+      get native shader code.
+
+* Misc:
+    - Michael: Please have a look at my question in PR #1197 about workarounds 
+      to support Python API docs on RTD. somewhat controversial choices so 
+      would like input. Also to TSC, please have a look at the ASWF survey 
+      questions. Could use some input on multiple choice answers.
+    - Patrick: New API docs very helpful. Built branch locally and looks good.
+    - Mei: Pavel, engineer from SPI starting using OCIO v2. Provided feedback 
+      that overall very happy. Performance is faster, and has not been any 
+      issues. Happy with it. Can get more feedback if there's specific
+      questions for him.
+
+* Items for next TSC meeting agenda:
+    - Continued discussion on named color transforms.
+    - Follow up on AD response to ILM feedback and questions.
@@ -0,0 +1,100 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 16, 2020
+
+Host: Doug Walker
+
+Rotating Secretary: Carol Payne
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Epic Games
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carol Payne (_TSC_) - Netflix
+  * [x] Mark Titchener (_TSC_) - Foundry
+  * [x] Carl Rand (_TSC_) - Weta Digital
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * [x] Bernard Lefebvre - Autodesk
+  * [x] J Schulte - ILM
+  * [x] Matthias Scharfenberg - ILM
+  * [x] Larry Gritz - SPI
+  * [x] Aymee Kennett (Yeh) - Netflix
+
+Apologies:
+  Michael Dolan
+
+# **OCIO TSC Meeting Notes**
+
+* Named Color Transforms - Continued discussion
+    - Doug: Patrick, Bernard and I have been discussing the feedback and how to respond. We have made it possible to turn off the NamedTransforms - similar to an environment variable. Config author/ dev would be able to control whether or not the feature is visible to the user. Bernard has pushed that commit to the PR so it should be available for viewing.
+    - Mark: on/off isn't a true solution - we don't want to fracture the community. The opposition was because we felt that NamedTransforms opposed the way we want OCIO to work.
+    - Doug: would be interested to hear alternate proposals.
+    - Mark: the solutions already exist - you just have to utilize your working space as your reference space. 
+    - Doug: Not everyone is going to be solely using the working space of the config. 
+    - Mark: You design your config based on your requirements for your work. Having different in and out colorspaces is not how it's defined to work.
+    - Doug: We can't expect everyone to have a separate config per working space. Even a difference between rendering space vs. compositing space. Thinking ahead to the studio config as well, it would be ideal if this workflow was easier to implement. 
+    - Mark: But ACES is trying to be the single working space - and should be for the future. 
+    - Carl: WETA works in a different compositing colorspace than rendering space, for example.
+    - Matthias: verifying that we're talking about NamedTransforms that are basically a transfer funtion or something similar? So you don't get the matrix transform that you would get by using the colorspace which goes through the reference space as well? It sounds like a "trapdoor" in the color management system.
+    - Kevin: I didn't see it quite that way. Instead of performing a 2-sided transformation, it's a 1 sided.
+    - Matthias: but isn't that not how OCIO is designed? That you need to go through the reference? This becomes like a "transfer function toolbox" for debugging, design, etc. Could be handy but don't see how it ties into the OCIO ecosystem itself. 
+    - Kevin: Are we talking about something that a DCC needs access to? Or just a toolbox of options. 
+    - Doug: So we wanted to clarify this by not calling it a colorspace - it's a NamedTransform. The ability to define a transform rather than a colorspace. 
+    - Mark: will you see these in say, the list of options to load a texture in an application?
+    - Kevin: Are we just missing some UI/UX design features? Do we need an OCIOTransform op? Would that accomplish the same thing?
+    - Matthias: the concern is that this really offers a trapdoor - an exit from the color managed worflow - what happens when you don't know where you're coming from or where you're going? 
+    - Mark: Still don't understand who the end user is here - seems to be config authors, but config authors already know how to do this correctly.
+    - Doug: we have received feedback that this feature is a requirement. From multiple users / DCC authors. Not everyone knows how to write a config
+    - J: but if we think to the future, and if we can help users move forward to a correct color management workflows, that a lot of these requests would be moot?
+    - Doug: a lot of users don't understand/want anything more than a 1d linear/log workflow - but still need to be able to connect into a color managed world.
+    - Mark: I don't think you can have it both ways.
+    - J: Is the concept of what we're trying to get out of this enabling workflows that go against the "correct" OCIO usage? Does this matter - or are we just providing ways to work to DCCs to use it as they will. 
+    - Carol: Is there a middle ground? We want people to graduate to color management, and if this is a feature that's been requested, wouldn't we rather enable them to move forward into OCIO?
+    - Mei: what transforms are we talking about that couldn't be expressed via an OCIOFileTransform node in Nuke?
+    - J: Worried about introducing this potential for breakage in already complicated pipelines and worflows. 
+    - Doug: tools already have this, what's the opposition to having it in OCIO?
+    - J: We try to operate solely in fully color managed workflows, and introducing this throws a wrench in those workflows that requires additional support and tracking and awareness. Should OCIO be setting the standard and authority of good practices, or is it solely middleware at this point?
+    - Doug: It's a complete color management solution. I feel that if it's going to be complete, it can't only be state of the art, as practiced by the best. We need to make it applicable and achievable to all. There's an expectation that workflows that have existed still exist and there is a broad user base we need to support. We need to be realistic.
+    - Carol: there's a huge group of people who have been working the way they are for years, who might not benefit at all from changing their workflows. 
+    - Mark: the rest of the line in the documentation is - geared toward the motion picture industry for visual effects and animation.
+    - Doug: visual effects is a very big industry - learning the craft through youtube without guidance. A number of these features are indeed broadening the scope of the original OCIO features. I don't think that is uncommon as projects grow, their user base expands, and needs change. Michael and I tried to start this earlier in the year when we updated the mission statement. We feel we've been very clear in our participation in OCIO - which is to suit the needs of a wide range of visual effects and animation artists in every area. We used to have two color management systems - we are trying to have one system to meet all of the needs.
+    - J: Thank you, that's very clarifying.
+    - Doug: I don't know where this leaves us, we have a few more things to discuss.
+    - J: would love to think about this and regroup.
+    
+* RC1 or beta1 tag:
+  - Doug: we are fine with beta1 instead of rc1.
+  - Mark: Good with that.
+
+* CUDA implementation followup.
+    - Doug: We talked about this last week, but missed the intent of Larry's original question - so he's here this week to help us understand his ask for OSL and other renderers.
+    - Larry: Traditionally OCIO functionality has been in 2 directions - using interactive graphics APIs to color correct a display. Makes sense for this to be OpenGL. But there's a 2nd interface callable from c++, which we use in OSL which do arbitrary transforms in shaders that we need at the time, as long as it's in the config. Trick here is renderers that take advantage of that are switching to CUDA based implementations - want to figure out how to continue to access this functionality in the new CUDA world? Or is this not something these libraries will continue to be able to use OCIO for? It's not uncomplicated - there has to be a directly accesible implementation for CUDA. 
+    - Mark: So added functionality to the API to get a CUDA callable alternative would this solve the problem? 
+    - Larry: CPU based c++ app launching CUDA kernels. Can the CPU app ask for the correct CUDA version to pass for the shader - think this would be fine. Just want something - get a handle to a CUDA callable transform.
+    - Mark: only thing we have now is the GLSL "get me a shader". Another API call where you pass in CUDA instead of whatever, that would work? Either texture source or byte code?
+    - Larry: either is fine.
+    - Mark: Textural source would be much easier. 
+    - Doug: Issue with the GPU is how to get the texture onto the GPU.
+    - Patrick: Yeah it's a big blob of data - the texture that you have to get onto the GPU. The structure is there to be able to generate the CUDA code. There are two APIs - one that's openGL oriented, the other that just takes what it needs to do.
+    - Larry: CUDA has similar texture lookup to what you find in OpenGL.
+    - Patrick: Dynamic properties are another functionality to consider.
+    - Doug: Yes, how would you do uniforms?
+    - Larry: Not sure, will find out - but not critical right now.
+    - Mark: Imagine it's there, values you can tweak on your shaders.
+    - Larry: There are assumptions it makes - numbers you can't change without regenerating the shader. But it's not the primary concern right now.
+    - Mark: should be doable - just need someone to do it. There's not a lot to change, it's just annoying - go through every transform to add the CUDA implementation.
+    - Larry: good news is CUDA is basically C++ with decorators. 
+    - Patrick: Another thing we have are helper functions - still C++ but soemthing to consider. It's a function in the shader. 
+    - Mark: so the hooks in the shader where you're expecting user input?
+    - Patrick: No, at the intitial generation. A shader might use another method to call to perform a function - it's a subfunction.
+    - Mark: Ah, so it's like a standard library of things you can use in your GLSL.
+    - Patrick. Yes, so we're not repeating a bunch of code. 
+    - Doug: to summarize, the current API would support CUDA, but it would be a fair amount of work to implement - we have an issue open for it now, looking for volunteers.
+    - Doug: thanks everyone, there's a configs meeting tomorrow, make sure you check the times! 
+    
+
@@ -0,0 +1,153 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 23, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Deke Kincaid - Digital Domain
+
+Apologies:
+  Mark Boorer
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF Survey:
+    - Michael: Our part of the ASWF survey includes a question "Are there any
+      areas of color management that OCIO is NOT helping you with?".  Is there a
+      way to make this multiple choice to fit with the rest of the survey?
+    - Carol: I would remove if it needs to be multiple choice.  Don't want to
+      seed responses.  Michael, Doug, Kevin: agree.  
+    - Kevin: Also don't want to imply we are thinking about adding something
+      that we actually are not.
+    - Michael: Will try to keep it as an optional write-in.
+
+* Documentation Update:
+    - Michael: Hoping to wrap up PR #1197 in a few days.  Adding the part to
+      handle Python that we discussed previously.  Basic issue is that RTD does not
+      allow us to use cmake and build.  Implies Python needs to be pre-generated and
+      "frozen" into the repo.  Also implies Doxygen needs to be run via Sphinx rather
+      than cmake.
+    - Michael: Not happy with how complicated the solution is but until RTD
+      supports cmake, will need some kind of solution like this.  The process of
+      generating and updating the documentation will itself need careful
+      documentation.
+    - Doug: Thanks for working on this Michael!
+
+* Review of Current and Upcoming PRs:
+    - Doug: We've pushed several PRs in the past week: #1208, #1214, #1215. 
+      These are all either minor clean-ups or bug fixes.  The most important is #1215
+      since it fixes a bug reading v1 configs that use "interpolation=unknown" in a
+      FileTransform.  We view this as a critical bug fix and would like to merge it
+      before placing the beta1 tag.  Does anyone object to us going ahead and merging
+      this one now?
+    - Michael, Mark, Carol, Kevin: Yes, merge #1215 immediately.  (No one objected.)
+    - Doug: We will go ahead and merge it and then place the "beta1" tag
+      discussed at the previous TSC meeting.
+    - Doug: We have two more PRs that will land this week.  First is related to
+      Issue #1155.  In that issue I proposed cleaining up the CDLTransform API.  We
+      have done that and moved the parsing and serialization code out of CDLTransform
+      and put it in the FileFormat modules, to be more like the other formats.  We did
+      not go quite as far as I had proposed in Issue #1155 in that we did not remove
+      all the mentioned functions (although the name of one was changed to clarify
+      what it does).  Also, we moved the write method from the Processor class to the
+      GroupTransform class.
+    - Michael: Why move the write method to the GroupTransform?
+    - Patrick: It allows for more flexibility, don't need to create a Processor
+      in order to write.  No functionality is removed, one may always get a
+      GroupTransform from a Processor.
+    - Doug: Note that this was not in v1, so moving it will not break any
+      existing apps.
+    - Michael: Is there a case for also leaving it on Processor so that it's
+      more discoverable?
+    - Patrick: Metadata may be lost when a Processor is built, also some
+      spurious items may be added (Allocation, etc.).  Having it on the GroupTransform
+      is a better design, allows one to write exactly what is intended.  It's more
+      deterministic.
+    - Kevin: If the worry is about making it discoverable, that could be done
+      via documentation rather than leaving it in the Processor API.
+    - Michael: Yes, and it could also be confusing to have it in both places
+      giving somewhat different results.
+    - Doug: The other PR landing this week is a move of the AppHelpers modules
+      into the core.  This is following up on the TSC's request to move it from a
+      separate library into the core.  The goal is to avoid needing two OCIO libraries
+      (for Linux distros, etc.).
+    - Michael: What about the OIIO and OGL helpers?  Patrick: Those remain as
+      separate.  Really don't want to bring those third-party dependencies into the
+      core library.  AppHelpers adds no third-party dependencies.
+
+* OpenEXR 3.0
+    - Michael: Their v3 is on the way.  Pulling from top of tree may break
+      downstreams.  We pull from most recent tag, so not impacted yet but will be
+      soon.  Currently we do some special stuff in our cmake since the only thing we
+      need is half.h.  This could probably be improved based on their refactoring.
+    - Patrick: This dependency is not in our public API, but agree it will
+      require some updates.  Could be a good first issue for someone.
+    - Doug: Michael, would you create an issue on GitHub so it has more
+      visibility?  Michael: Yes, will do.
+
+* Open Tasks Needed for OCIO v2
+    - Michael: Wanted to discuss some of the remaining items.  Mei, where do we
+      stand with the Python unit tests?
+    - Mei: The Transforms is the area that needs the most work.  Would also like
+      to centralize more.
+    - Michael: If you need help, reach out.  Don't want you to feel like this is
+      all on your shoulders.  Mei: Will do.
+    - Michael: On the documentation front, where are there holes?  Is it all
+      documented in the GitHub Project?
+    - Carol: We don't have Issues created for everything.  There are still some
+      items in my head, and Doug's too probably.  We have been trying to onboard new
+      contributors.  Have received some great assistance from Zach.  We have some
+      tasks that would benefit from having a sample v2 config, but not blocked by that
+      yet.
+    - Doug: Another important task is making OpenFX plug-ins for v2.  We have a
+      student who has volunteered to help with this but he is having trouble getting
+      the example plug-ins from the OpenFX SDK loaded.  He's tried Natron but the
+      plug-ins are not loading.  Not sure if it is a problem with what he's built or
+      in Natron.  Once he gets the plug-ins loading in a host, Patrick and I could
+      help him with the OCIO part but is there anyone that could help us get him over
+      this first hurdle of getting some example plug-ins to load?  The student has
+      posted in #dev on Slack asking for help.
+    - Michael: Mark, OpenFX was originally a Foundry initiative, right?  Is
+      there someone on your team that could help?
+    - Mark: I will check.  Also, once the plug-ins are ready to test, we could
+      help with that too.
+
+* Items for next TSC meeting agenda:
+    - Doug: The Named Transform will soon be a blocker for us.  Need to get to a
+      resolution on that.  Also, would like to know if our reply to ILM's memo
+      addressed their other concerns.
+    - Michael: I have put Named Transform on the agenda for next meeting. 
+      Carol: Could set a goal to resolve it.
+    - Patrick: The end of the year is rapidly approaching and in the roadmap
+      presentations we showed releasing a v2 library at year end.  Need to make rapid
+      progress.
+    - Michael: We may need to settle for just having the release candidate done
+      by then.  Would like to have more feedback before the final release.
+    - Doug: Agree.  I'd also like to have a discussion around the categories feature. 
+      The code was added a long time ago but we still need to have the discussion
+      around what are the recommended strings.  (These are the strings that allow apps
+      to filter the list of color spaces based on the specific menus.)
+    - Deke: Sounds good, we're excited about that.
+    - Carol: Yes, I'll also put some thoughts on GitHub prior to the next live
+      discussion.
+    - Doug: I'll create an Issue for the category naming.
+
+* Documentation Meeting Schedule
+    - The group decided to cancel the documentation working group meeting this
+      Friday due to the Thanksgiving holiday in the US.
@@ -0,0 +1,213 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 30, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [x] Bernard Lefebvre - Autodesk
+  * [x] Deke Kincaid - Digital Domain
+  * [x] Joseph Goldstone - ARRI
+  * [x] Matthias Scharfenberg - Industrial Light & Magic
+  * [x] Nick Shaw - Antler Post
+  * [x] J Schulte - Industrial Light & Magic
+  * [x] Alessandra Tomassi - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to recap goals of OCIO v2 and relation to OCIO mission:
+    - Some recent discussions about controversial topics. Thought it would be 
+      useful to recap what we're doing with v2 from AD point of view - clarify 
+      motivation for some of these new features. As written in origin proposal, 
+      goal is to be able to use OCIO across apps more broadly, and to rely on 
+      it entirely as our color management system (CMS). We would like to 
+      standardize on OCIO across apps. Need OCIO to do a variety of color 
+      management tasks. When thinking about how OCIO is used, there's color 
+      space based transformations (OCIOColorSpaceNode, etc.) and other 
+      operations which are more ignorant of color spaces (OCIOFileTransform, 
+      etc.). In ideal world, only the former would exist, since it requires the 
+      least knowledge from user. Reality is though there is need for people to 
+      apply independent transforms, in apps where it's expected the user knows 
+      a reasonable amount about color management (e.g. Flame - users know how 
+      to load a LUT and apply it). Don't want two separate libs for applying 
+      LUTs. For things like dynamic properties and NamedTransform, it's more 
+      the latter case, using the same CMS to apply the independent transforms. 
+      We aren't trying to change the existing config way of working - very 
+      supportive of that workflow. Don't want to enable people with ability to 
+      edit individual transforms in a config to edit look of a config.
+    - Mark B: Caught up with Doug offline to discuss. The way Doug describes it 
+      now, it makes sense. Objections were based more around how these features 
+      would map to configs. Some of the objectional features don't map to 
+      configs, so we're ok with that.
+    - Deke: Really useful for tools like Nuke, where you have to jump over a 
+      wall to implement things differently based on what workflow you are 
+      doing. Would be nice if Foundry could have one code path instead of two 
+      separate ways.
+    - Mark T: Agree. We would like that too and hope to standardize on OCIO in 
+      Nuke and across products.
+    - Doug: Would be helpful to write whitepaper to try to establish best 
+      practices. Sometimes we have people who are asked to implement color 
+      management but are not color management experts, and implement without 
+      being aware of best practices. Think having something that documents this 
+      more extensively than current docs would be helpful. Hope TSC can focus 
+      on this once v2 is out. Help people understand color management and 
+      implement it correctly.
+    - Deke: Any support for deep merging of multiple configs?
+    - Doug: There is a way to convert between multiple configs in OCIO v2. USD 
+      for example could reference one scene config, and import an asset using 
+      another config. We added a processor command which can convert between a 
+      known color space present in both configs. Looks for these two roles that 
+      have been added which act as an interchange. Also added a version where 
+      you can provide your own interchange (common color space used across 
+      studio).
+    - Deke: No way to merge two configs though? To support vendors having 
+      configs which inherit from each other.
+    - Doug: No.
+    - Mark B: Any use case where you're trying todo that?
+    - Deke: If vendors could have their own internal config and add it on top 
+      of yours. You could add it above or below and merge them together and 
+      have access to those transforms. Also for MaterialX, USD, etc. Point to 
+      someone else's config to get transforms without cleaning up and 
+      ingesting.
+    - Mark B: Need to use the solution Doug describes since you don't know if 
+      the two config are compatible.
+    - Deke: Could also be a studio vs show level config.
+    - Mark B: We have same thing, facility, show, shot. We merge them through 
+      custom sanitizing tools.
+    - Deke: Same. Inherit from ACES config and build on it.
+    - Mark B: Might put out another doc to clarify what was discussed with Doug 
+      offline. Might be more to discuss but inconsequential compared to other 
+      stuff.
+  
+* Named Color Transforms - Continued discussion:
+    - Michael: Is this topic still up for debate? Or was it resolved through 
+      offline discussion?
+    - Mark B: Didn't cover this topic. Still up for discussion.
+    - Doug: We implemented ability to make NamedTransforms inactive. Commit 
+      pushed to existing PR that does this. Zach proposed alternative way to 
+      make them inactive. I replied that we are open to implementing that 
+      instead of or along with what was done. His idea was to use env var to 
+      disable named transforms all together, instead of treating them as 
+      inactive color spaces where they are disabled one at a time.
+    - Michael: Could be good to have a config attribute in that case too since 
+      the env could be cleared accidentally when shelling out to a process. 
+      That would prevent it in a persistent way. Like how active displays and 
+      views are handled currently, with env var or config property.
+    - Doug: The individual inactive flags are persistent, so can be used in 
+      that way.
+    - Michael: Does that answer ILM concerns?
+    - Mark B: Our concern is feature itself, not the implementation. And how 
+      it's exposed inside of tools. Does processor take NamedTransform 
+      constructor?
+    - Doug: Would call getProcessor which takes generic transform, and pass 
+      in NamedTransform. Same approach as using FileTransform.
+    - Mark B: Based on conversation earlier, don't have strong objection. If 
+      intent to enable DCC to expose individual transforms where they won't get 
+      confused with other transforms.
+    - J: Yes, and this is progress on previous discussion. With beta going out 
+      and implementation being considered, need to get standardized view on 
+      implementation.
+    - Mark B: In terms of enabling/disabling, like active displays/active 
+      users, sounds reasonable.
+    - Carol: As aside, another useful case Matthias and I were discussing. This 
+      would be the perfect vehicle for the ACES gamut compression transform. 
+      Would be nice to be able to do that separately, in ACES config. Fits 
+      nicely.
+    - Mark B: One point we discussed. Two very separate use cases for OCIO. One 
+      we're trying to defend is config author creating black box, being 
+      represented properly. Second use case with graph and a skilled artists 
+      making decisions with toolbox of consistent math. In terms of first 
+      users, don't see much use for NamedTransforms. Can see benefit for second 
+      group of people though.
+    - Michael: Use of NamedTransforms could be covered in Doug's proposed 
+      whitepaper too.
+    - Nick: Would that be a separate node in Nuke?
+    - Mark B: Think so
+    - Mark T: Yes, think that would be the case.
+    - Michael: Wanted to propose we form a UX working group to discuss these 
+      topics and forming standards for OCIO v2 implementation in DCCs. We could
+      transition from the doc working group to that. If anyone is interested in
+      helping lead that, please reach out.
+    - Others: Agree. 
+    - Deke: ACES has own UI rules, could collaborate between projects.
+    - J: Don't think OCIO UX being involved with ACES is good fit, since there 
+      are workflows that don't involve ACES.
+    - Doug: As config working group moves forward a lot of the same questions 
+      are going to come up. A lot of questions from initial config discussion 
+      was on things like naming and interface.
+    - **TODO**: Michael will help organize a UX working group. 
+
+* Categories discussion (Issue #1222):
+    - Doug: At last TSC meeting talked about this. Created issue #1222. Trying 
+      to collect a number of new features and discussions on how color spaces 
+      appear in application menus. Motivation is the new categories attribute. 
+      Hadn't gotten to the list of proposed categories, or sorted out how we 
+      expect applications to use this. Want to make sure we're all on the same 
+      page in case tweaks are needed to get this working as expected. Proposed 
+      some tweaks in the issue. One of the things that came up in v2 working 
+      group meetings was request from people that they want to specify, from 
+      studio perspective, env vars to filter color spaces for artist 
+      groups, like compositors, lighting artists, modelers, etc. Different from 
+      app developer point of view with different menus for tasks. Proposed both 
+      use cases and something which could work on both ends. Want feedback on 
+      whether I've captured this correctly. See issue content:
+      https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1222
+    - Kevin: Have existing concept of roles. Fixed set of assumed roles plus 
+      extended set. How would we choose to filter those with this. Nuke now 
+      shows roles in menus, and would be good to filter those as well.
+    - Doug: App helpers code has setting to show roles or not.
+    - Kevin: Want users to find the roles they want to find. Artists trained 
+      to use particular roles for certain tasks.
+    - Deke: Mari has roles listed too, and has its own roles.
+    - Mark B: Intention for roles was just to make sure basic color spaces were 
+      there. Roles have been misused since then. Don't think roles should 
+      appear at all in menus.
+    - Deke: Like roles there, but need to filter them.
+    - Mark B: Category system is powerful. If DCCs have prefs as to what 
+      category might be associated with a dropdown (i.e. texture in Maya). DCCs 
+      can assign categories to UI elements and only show those. Don't think 
+      this should be OCIO-wide env var. Should be per-DCC.
+    - Doug: Yes, would be fixed for certain menu. Specific documented category 
+      so config authors know what an app uses.
+    - Mark B: Could end up with overlapping categories. If up to user they 
+      could define that themselves.
+    - Doug: Proposing standard categories to encourage consistency, but doesn't 
+      need to be limited to this. The key part is there is a set pre-defined to 
+      an application. So Maya would say what categories it's using for different 
+      menus. There is another set that is end-user defined and would expect to 
+      find those at runtime.
+    - Mark B: What if you have both types of categories?
+    - Doug: Then would use the intersection. So for texture, you could have 
+      file-io intersected with an end-user environment variable (basic-3d etc.)
+    - Mark B: If either is empty, defaults to other?
+    - Doug: Yes.
+    - Mark B: Would make these categories configured by the config author. DCC 
+      authors would allow users to customize the category names, or fallback on 
+      the default list.
+    - Carol: Something to fall back on is good. Most people just use defaults. 
+      Don't have a problem with proposed options.
+    - Mark: Defaults from DCC (as documented) is fine. Want to avoid problem 
+      with roles where categories are inconsistent between apps. If all left to 
+      user can be very explicit.
+    - Michael: More topics for discussion at UX group.
+    - Mark T: Agree. Highlights importance of best practice to show how things 
+      are intended to be used. Developer may not find the right thing and use 
+      something outside standard use. UX stuff really important.
+    - Mark B: App helpers has concrete implementation for reference.
+    - **TODO**: All: Read through issue #1222 and provide feedback there or in 
+      next TSC meeting.
+
+* Items for next TSC meeting agenda:
+    - Finish discussion on standard categories.
@@ -0,0 +1,141 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 7, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Nick Shaw - Antler Post
+
+Apologies:
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to summarize in-progress work:
+    - Doug: With regard to categories, looking at issue (#1222). Idea to 
+      improve app helpers code to implement improved category mechanism.
+    - Other work in progress:
+        - Color space alias mechanism. Seemed to be good consensus on this 
+          being helpful.
+        - Improve list of builtin transforms in support of ACES.
+        - Various bug fixes.
+    - Michael: Any feedback so far on OCIO v2 testing?
+    - Doug: Not as much as we would like - a risk factor on release. Wondering
+      what we can do to improve that situation. Draft PR for OFX plugin arrived 
+      yesterday. Still ways from being done, but could get us more testing upon 
+      completion. Chicken and egg situation.
+    - Michael: Any studios here tested it out?
+    - Kevin: Not that I'm aware of [at Framestore]. Have used commandline stuff.
+    - Michael: Might be worth starting ocio-dev thread to invite people to beta 
+      test. Could mention what needs feedback and provide more details.
+    - **TODO**: Michael and Doug will draft ocio-dev thread to reiterate beta 
+      testing. 
+    - Mark T: We have started testing it, but off for break. In new year will 
+      hope to have something. End of January-ish.
+    - Kevin: Talked to Nigel about work done there so far. Suggested demoing 
+      the work for the TSC.
+    - Michael: We're happy to set up a Zoom meeting if that's helpful, to give
+      feedback. Will help once we have UX working group up and running.
+
+* Frozen doc generation platform differences and difference threshold:
+    - Michael: See PR #1197 for explanation, but faced challenge with frozen 
+      docs differing between platforms, due to subtle naming differences from
+      the C++ side. Implemented fuzzy matching to pass/fail CI based on 
+      difference threshold, which isn't ideal, but will work for now. Should 
+      probably limit freezing to Linux builds only since that's what RTD uses.
+      Any objections to the current RST freezing workflow?
+    - Doug: May impact developers. Have to build docs and run python 3 to pass 
+      CI. 
+    - Michael: True. Alternative solution was to store CI build artifacts in an 
+      S3 bucket and download those during RTD build, but current ASWF S3 bucket 
+      is not public and requires secrets to access. Would need another setup.
+    - Mark B: Good first step to get in the door. Good for now. Not such a bad 
+      thing.
+    - Doug: Huge step forward in process. Have looked at review. Think we 
+      should merge it, and do follow ups.
+    - **TODO**: Michael to talk to Lf and/or RTD about plans for future 
+      CMake/compiler support. Would remove need for these workarounds.
+
+* Categories, continued discussion (Issue #1222)
+    - Doug: To summarize, we're proposing making the 3 changes listed in 
+      summary of issue #1222.
+    - Doug: Documenting these initial categories would not be part of the 
+      initial PR. any questions?
+    - Kevin: The names we give these things have to be really bulletproof about 
+      what they mean, or leave it up to the apps to tell us what to look for. 
+      Would make is straightforward to link apps and config. May need default 
+      set of terms, but need to be careful to say what they mean.
+    - Doug: If we don't companies will come up with their own and could make 
+      the list much longer if everyone has different name for same thing. Will 
+      be differences between apps, so not clear cut.
+    - Carol: Can we reach out to some subsets of apps, Foundry, AD, and others 
+      (Black Magic) and ask what their preferences would be?
+    - Doug: Proposed these from an app point of view. These three seemed like 
+      they would be common menus. Proposed starting point. 
+    - Carol: Would be worthwhile to show to Foundry and others.
+    - Mark T: I can show this and discuss internally.
+    - Mark B: We could agree on the categories, but the list is large and some 
+      are not represented in this meeting. Felt that empowering users to always 
+      set it is the only answer. Would allow all needed workflows; up to config 
+      author if they want to tag them as disciplines or tag based on 
+      functionality.
+    - Carol: What would we do for ACES studio config?
+    - Mark B: That will come up in that working group discussion. Should expect 
+      the default case to be a user telling a DCC what category is assigned to 
+      what drop down menu.
+    - Doug: That would be the ultimate in flexibility. Does impose more work on 
+      app vendors - that customization, and not everyone may do it.
+    - Kevin: If we had that and same default terms. Would need map between apps 
+      and what they need to know about. Also other cases where rules were used 
+      in past. Becomes open ended at some point. Sometimes we have SG task or 
+      process step that tells the app why the user is loading it: tracking, 
+      lighting, etc. In that case, doing it in one config would be difficult.
+    - Mark: If you want artist based workflow, tag those, but still up to app 
+      to associate the tags with menus. Need app preferences of which category 
+      to assign to specific menus.
+    - Kevin: That's almost a different table of mappings.
+    - Mark: Or a different config per DCC, which we would likely not have.
+    - Doug: In terms of proposed code, app helpers implements possibility to 
+      pass in two categories and do a join/intersection. Initial PR doesn't 
+      need to sort out question of recommended categories or not, or if users 
+      should be able to customize menus. Talked about UX working group, that 
+      would be a topic to wrestle with.
+    - Mark: Current proposed work seems fine and mergeable then. Would be great 
+      if working group result would be PR into app helpers. Already a place to 
+      point to for DCC authors to buy into. Almost outside our scope, 
+      encouraging apps to save these options. 
+    - Michael: We have one volunteer to lead the UX group, but would like to 
+      have a second to balance the work. If anyone is interested place reach 
+      out.
+    - Carol: Definitely want to be part of it.
+    - Kevin: In response to Zach's comment in issue: Not sure I'm enamoured by 
+      the suggested do-not-use approach. If going to have a feature it should 
+      be explicit.
+    - Doug: Will make PR and have concrete stuff to review. For purposes of 
+      docs, what we can take these menu and artist categories and include them 
+      in docs as examples. Make it clear it's open to what users want.
+    - Carol: Agree.
+    - Doug: Can use OFX plugin as prototype. Can have field in plugin for 
+      categories to use, and users can type different things. Can anyone 
+      provide some help on this OFX work? It's an important step for 
+      testing.
+    - Mark T: Spoke to some at Foundry. Many involved in OFX no longer there, 
+      but some could help with specific questions. Reached out to contributor 
+      after previous TSC meeting about build issues and got that fixed. Tried 
+      examples on my end and worked fine. Just had bad flag. Definitely 
+      potential for help from engineers at Foundry.
+    - Michael: I can help with guidance too. I'll have a look at the PR.
@@ -0,0 +1,148 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 14, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Alessandra Tomassi - Industrial Light & Magic
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Joseph Goldstone - ARRI
+
+Apologies:
+  * Mark Boorer
+  * Mark Titchener
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to summarize in-progress work:
+    - Doug: Have PR in progress about moving app helpers to core, and for 
+      category updates described in issue #1222.
+        - Current PR for small BuiltinTransform changes. Much larger PR in 
+          progress - adding remaining ACES transforms.
+        - CDLTransform cleanup PR is ready to be merged.
+        - Maya beta going out with preliminary OCIO v2 integration. Not on 
+          by default - needs environment variable. Very preliminary, missing 
+          stuff, but felt it was important to get it out as soon as possible. 
+          We're worried it's not being tested enough. Good way to get 
+          additional coverage.
+        - Carol: We'll do some testing at Netflix with it.
+        - Thomas: Any word on Nuke?
+        - Michael: Mark Titchener mentioned last week that they are working on 
+          Nuke implementation. Hoping to have something around end of January 
+          or so.
+        - Patrick: Regarding the preliminary Maya integration - it just hints 
+          at what's coming, so keep in mind.
+        - Doug: Will be a post on rendering forum with more details.
+        - Michael: How long did it take to implement, roughly?
+        - Patrick: Took quite a bit of time. We did deep integration of color 
+          management in Maya, so replacement with OCIO v2 is a lot of work. 
+          Depends on integration in your tool; could be straightforward. In 
+          Maya it was deeply integrated, so was not trivial. Nothing to do 
+          with library itself. Even if it's preliminary, OCIO v2 is still here. 
+          Can use config and displays, etc. Limitations listed in release 
+          notes.
+        - Doug: Not sure in release notes, but in rendering forum. Will post 
+          issues there. We had the most difficult job since we're transitioning 
+          from SynColor and have to have backwards compatibility. Lot of work 
+          for us, but hoping companies already using OCIO v1 exclusively will 
+          be more straightforward. Some new work to take advantage of new 
+          features, but getting up and running should be less complex.
+        - Patrick: Someone did integration in another tool and had it up and 
+          running in week.
+
+* Enable the new GitHub Discussions feature for OCIO?
+    - Michael: Been some discussion on this in Slack with mixed responses. I 
+      can enable it to play with if we think it's useful.
+    - Thomas: Can mark topics as answered, so could be mini Stack Overflow on 
+      GH. Could be useful. Will try to use it on colour science.
+    - Patrick: How do you compare it to Google groups?
+    - Thomas: Good question. We don't have a lot of good Groups traffic, but 
+      think will make sense to put it in GH.
+    - Michael: Would be nice to get ocio-dev/ocio-user out there like that. 
+      Lots of channels currently, but lists is less accessible.
+    - Thomas: Not much traffic there now.
+    - Carol: Would be interested in that too. Could test as method for 
+      replacing it.
+    - Michael: Could enable it just to test. To push buttons, etc. Could set it 
+      up on OpenColorIO-Configs-ACES repo if we want to test it somewhere less 
+      active.
+    - Patrick: Have to be careful. We have changed a lot. Need to not lose 
+      existing community. Something to keep in mind.
+    - Thomas: Good point. We have same concern. Has useful features though, 
+      like turning GH issues into discussion. Can move between issue and 
+      discussion, to keep issue board clean. Much harder on mail list. Could 
+      de-clutter issue tracker.
+    - Michael: A lot of our traffic has moved to Slack, since it's more real 
+      time. Same for ASWF discussion. There was initially concern about Slack,
+      since it is expensive to keep history, but a lot of discussion has moved 
+      there.
+    - Doug: Happened to quite a few mail lists when they added Slack option.
+
+* Remove OIIO dependency from OCIO apps (Issue #1233)
+    - Michael: This topic has been ongoing for a couple years. Propose in #1233 
+      to implement the fix of replace OIIO with OpenEXR and libTiff. Any 
+      objections?
+    - Doug: Could also use DPX vs tiff.
+    - Carol: Prefer tiff.
+    - Thomas: Agree.
+    - Doug: DPX is simple enough that makes it easy to grab. Could be fallback 
+      if libTiff implementation is involved.
+    - Patrick: Do we agree on the direction?
+    - Michael: The main arguments for this solution are that the apps don't 
+      need to be rewritten (or duplicated) in Python, or broken into their own 
+      repo. The cpp apps are currently the main implementation example for app 
+      developers. Python examples are more useful for topic of config 
+      authoring.
+    - Patrick: Should not underestimate app examples. Some use these heavily.
+    - Doug, Patrick, Thomas: Agree with proposal.
+    - Thomas: OCIO/OIIO are a pain right now to build because of that circular 
+      dependency.
+    - Michael: Aloys is also facing issues with this in the development of 
+      production VFX ref platform Docker images for aswf-docker.
+    - Patrick: Should also think about package managers; brew, vcpkg, etc. 
+      vcpkg is broken right now.
+    - Michael: Yes, a discussion on Conan is what brought this topic back up.
+
+* GH Actions macOS runners maintenance:
+    - Michael: Received notice from GitHub that they are doing maintenance on 
+      macOS runners this week, so we may see interruption.
+    - Patrick: Any problems with CentOS runners?
+    - Michael: No, those are run on Ubuntu runners. CentOS is purely in the 
+      Docker container, managed by aswf-docker.
+
+* Next TSC meeting January 4:
+    - Michael: After tomorrow's Config working group meeting, no OCIO meetings
+      until January 4th. All events have been cancelled in that window since 
+      most have holidays.
+
+* Other discussion:
+    - Doug: As mentioned previously, a student is working on high priority OFX 
+      plugins for OCIO, and may need assistance. If anyone has time to help 
+      him, see PR #1231.
+    - Michael: I reached out last week to see if specific help was needed, but 
+      no request as of yet. Can bump issue to get status.
+    - Michael: Also, last week we talked about sending an update to ocio-dev 
+      to invite more testing, but I hadn't noticed that Doug already sent 
+      something like that to announce the beta 2 release.
+    - Doug: May do beta 3 before next TSC meeting. If anyone has time, would 
+      appreciate testing and feedback, to move forward with RC in early 
+      January.
+    - Michael: Are the PRs coming this week the last major changes?
+    - Doug: The last feature, aliases, should land next week. Still some other 
+      PRs finishing up features already in place. Polishing, fixing, etc. 
+      Will have some PRs in early January.
@@ -0,0 +1,122 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+January 4, 2021
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Robin Rowe - CinePaint
+
+Apologies:
+  * Carol Payne
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* rawtoaces:
+    - Michael: rawtoaces was accepted as an ASWF incubation project at the 
+      last TAC meeting. Might be some interesting collaboration opportunity 
+      there.
+
+* Doug to summarize in-progress work:
+    - Doug: New PRs two weeks ago, some updated commits last week.
+        - Grading op implementation now complete.
+        - Minor fixes/changes: v1/v2 serialization issue (#1244). 
+          to_reference/from_reference synonyms. Default view transform 
+          specification.
+        - #1241 implements color space alias feature.
+        - Michael: Use case for config name added in PR? Comment seemed to 
+          imply could be used as a color space namespace, and referenced 
+          externally?
+        - Doug: Optional config name, could be useful for:
+            - Alternative to filename for tracking config.
+            - Indicate version. 
+            - Future use as more fully qualified name for a color space. 
+            - Reference for USD, other projects, etc.
+        - Just metadata for now.
+        - **TODO**: Bernard will clarify comment in API that config name has no
+          influence on color space lookups.
+
+* Seeking approval to merge PRs #1220, 1234, 1241 (today), 1244, 1245 
+  (tomorrow):
+    - Doug: Want to get OCIO v2 out there, since we're over the VFX ref 
+      platform release date a bit. Suggest releasing 2.0.0 by mid-January. 
+      Want to get last PRs merged and RC tag to communicate final testing 
+      state.
+    - Michael: Have a Python binding fix for CPUProcessor that should be in 
+      RC release.
+    - Mark: Did apphelpers (#1220) add dependecy to core? OpenGL?
+    - Doug: No, that's in another helpers lib separate from core.
+    - No objections to proposed merges.
+
+* Version handling discussion:
+    - Doug: Once config v2 version starts getting used, will be need to bump 
+      version for future changes. Want to discuss how to handle versioning. If 
+      config syntax needs tweaking, what to do. Currently will throw for v3 
+      and warn for v2.1.
+    - Michael: Currently just single int right?
+    - Doug: Yes, and added ability to have minor version in OCIO v2.
+    - Kevin: What additions would we make to need a version warning? Fixed 
+      transform?
+    - Doug: Yes, and some things would throw. A new style string for a 
+      transform for example.
+    - Mark: Don't think there's need to be future compatible. Would prefer to 
+      fail fast vs. silently ignoring incompatibility. OCIO and config version 
+      numbers can diverge.
+    - Patrick: For debugging would be useful to keep major version in sync 
+      between lib and config.
+    - Kevin: Does the minor version increment sequentially, or is it tied to 
+      lib release? Under what circumstances is a warning valid. Or is it just 
+      valid or not valid, ok or throw.
+    - Doug: If an older version config is not using new features, it could 
+      try to load.
+    - Michael: Failing fast would avoid subtle differences, like 
+      ExponentTransform negative handling changing for example.
+    - Kevin: Or changed defaults.
+    - Michael: Could have metadata in config with exact lib version if needed.
+    - Patrick: Need to be careful with optional metadata. Could get out of date 
+      and be confusing.
+    - Mark: If having minor version helps keep it organized, have no problem 
+      with it.
+    - All agree to allow minor version, and fail on unknown/unsupported version 
+      rather than raising a warning.
+    - **TODO**: Bernard will push updated to #1244, which is related.
+
+* Discussion about creating a RB-2.0 release branch:
+    - Doug: After these PRs get merged, will create the branch. Should RC tag 
+      begin that?
+    - Kevin: If we create them together we are saying they are the same. If 
+      separated, might be different.
+    - Patrick: Where do we put the tag? In master or in RB-2.0?
+    - Mark: Have it in both, and cherry pick master changes into RB-2.0.
+    - Patrick: Only consequence is master will be tagged as RC.
+    - All agree to create tag in master and branch RB-2.0 from that.
+
+* General discussion:
+    - Kevin: If we are concerned with ABI compatibility, should we put 
+      something in place to warn about it? Extra symbol appears or disappears, 
+      etc.
+    - Mark: OCIO is good at avoiding this since all symbols have version 
+      namespace. Only issue if you don't update the version number.
+    - Patrick: If we are consistent, won't happen. Should be caught in review.
+    - Mark: Difficult to comare symbols to detect change. Would need two builds 
+      or maintained list of symbols.
+    - Patrick: Even changing order could be an issue.
+    - Kevin: What about for Python?
+    - Michael: We are setting __version__ currently.
+    - Mark: It is likely used in setup.py, etc.
+    - Michael: We will eventually setup PyPi, so could be used there too.
+    - Follow up: See PEP 396: https://www.python.org/dev/peps/pep-0396/
@@ -0,0 +1,40 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+DATE
+
+Host: NAME (Michael Dolan?)
+
+Rotating Secretary: NAME
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Epic Games
+  * [ ] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [ ] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [ ] Kevin Wheatley (_TSC_) - Framestore
+  * ...others...
+
+Apologies:
+  NONE
+
+# **OCIO TSC Meeting Notes**
+
+* Topic 1
+    - info
+    - info
+
+* Topic 2
+    - info
+    - info
+
+* Items for next TSC meeting agenda:
+    - xxx
+    
+
@@ -0,0 +1,232 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 16, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Michael Parsons - MPC
+  * [X] Chris Clark - Netflix
+  * [X] Rémi Achard - DNEG
+  * [X] Troy Sobotka
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Working group direction:
+    - Michael: Goal of group could be to design and develop the next gen ACES
+      config, but also to maintain it long-term. Do we want to make it a formal 
+      working group with dedicated leadership?
+    - Thomas: Good to formalize the group. Current ACES config work is done 
+      when there is time. There's not a good commitment which can lead to 
+      delays. Group would be good for prioritizing work.
+    - Sean: Should it be distinct from OCIO TSC, or a subgroup?
+    - Mark: Division of power is better. There's some overlap, but the OCIO TSC
+      is more dev centric. This is more user centric.
+    - Michael: There could be a formal chair, or co-chairs, but without a 
+      formalized group. 
+    - Sean: The TSC has the benefit of governance structure.
+    - ACES will likely be involved to support the work, but the goal from our 
+      previous meeting was for OCIO to own the ACES config.
+    - Carol: We just need to make sure the OCIO TSC is represented in the 
+      group.
+    - Michael: Studios will become highly dependent on this config, so it 
+      will be important work.
+    - Mark: Software vendors (i.e. Foundry) will also be dependent on it.
+    - Thomas: Vendors are already asking about it.
+    - Michael: Anyone interested in leading the group?
+    - Sean and Matthias will co-chair.
+
+* Config structure:
+    - ACES reference config, studio in a box, or both:
+        - Michael: As discussed, could potentially have one code base which can
+          create an ACES reference config (minimal), and the big "studio in a 
+          box" config.
+        - Mark: If nobody is using the reference config, there's no point in 
+          duplicating efforts.
+        - Thomas: The smaller config is a subset of the bigger one. May not 
+          need everything depending on what you are using. A base.
+        - Kevin: We will often take a stock config and strip out stuff not 
+          needed. Depends on distribution. How we generate it could lead to 
+          module configuration.
+        - Doug: Does seem like build settings to select options would be good. 
+          Pure ACES model is good for OCIO as an ACES product partner, to 
+          submit the implementation to the ACES logo program.
+        - Carol: Something to be said for ACES transforms being builtin to OCIO 
+          v2. Not needing external files is nice.
+        - Mark: If you have multiple things to release, people have to make a 
+          choice of what they use. People who want the studio in the box will 
+          be upset depending on what DCCs choose as default. Lose benefit of 
+          consistency. If we up front have minimal ACES only, that has some 
+          value. We should be clear about what we’re giving out.
+        - Matthias: Will the config be OCIO v2 only? Is it backwards 
+          compatible.
+        - Sean: Needs to be backwards compatible. We’re probably the wrong 
+          people to answer this question. Should ask community what they want, 
+          rather than deciding on something.
+        - Thomas: Breaking backwards compatibility makes migration hard.
+        - Carol: We might get polarizing opinions.
+        - Mark: Almost feel whole idea of giant config is atypical of how OCIO 
+          works. People are supposed to have their own configs. May as well 
+          build everything into the library at that point.
+        - Carol: Some just use whatever config ships with an application.
+        - Michael: Think it is useful to support ACES-only reference for 
+          checking against ACES, etc.
+        - Thomas: ACES would like this config to be “the” config, to make 
+          exchange between studios easier. Something ready to use out of the 
+          box seems to be desired.
+        - Doug: Some projects, Like MaterialX, want to make this config their 
+          default.
+        - Thomas: That could be done for USD as well.
+- Utilizing OCIO v2 BuiltinTransform, and CLF where needed:
+    - Michael: The implementation could focus on utilizing BuiltinTransform, 
+      and CLF where external files are needed, since CLF is the ACES format.
+    - Doug: If Academy publishes transforms in CLF as well as CTL, would be 
+      interesting.
+    - Mark: Doesn't hurt to use it.
+    - Doug: CLF also supports metadata.
+    - Thomas: We currently ship ICC profiles, for things like Adobe tools. Need 
+      those for wider support. We could provide scripts to help people generate 
+      ICC profiles. Would result in simpler package.
+    - Mark: ICC profiles generated with ociobakelut often need to have 
+      additional stuff injected into them from an external script. Cant just 
+      use ociobakelut directly necessarily.
+    - Kevin: Repo should mostly be Python code, and generated artifacts.
+
+* Repository:
+    - Python code base
+    - Store generated config in repo? Or only as build artifact?
+        - Mark: Nothing in repo but code.
+        - Michael: We discussed previously if we should include the generated 
+          config in the repo for reference.
+        - Thomas: Need everything to go with config. Would be missing LUTs, 
+          etc. We need to get past that old issue.
+        - Matthias: Might be some vendor LUTs that are needed, where it is just 
+          a curve. Would potentially need to be in version control then.
+        - Mark: if the only source is only a LUT.
+        - Michael: Thoughts on pulling dependent data from upstream?
+        - Mark: Prefer to store it in repo if it's ASCII.
+        - Kevin: Need to be careful relying on vendor storage. May not always 
+          be available.
+        - Config repo will only contain config generation code, and text data 
+          resources where absolutely necessary (i.e. LUT data where no 
+          BuiltinTransform is available)
+    - Compound versioning (OCIO, ACES, semver):
+        - Michael: People need to know what they are getting. Sean proposed a 
+          compound versioning structure previously, to include OCIO version, 
+          ACES version, and a config release version.
+        - Carol: Yes, users need to know what is being used.
+        - Mark: Version structure like: 
+          `<OCIO version>_<ACES version>_<Build/Patch version>`
+        - Kevin: Recommend incremental build #.
+        - Michael: Could also use metadata to associate with ACES version.
+        - Mark: Can reset build number counter at new ACES version or OCIO 
+          version, etc.
+        - Doug: Could be comment in config file that shows what you have. 
+          Printed out nicely with different components.
+        - Mark: There could also just be a text file with the config.
+        - **TODO**: Determine how and where to differentiate the config release 
+          versions.
+
+* CI/CD:
+    - Build configs/LUTs for download
+        - Use CI to build complete config packages for release and easy 
+          download.
+        - Mark: In releases tab should be multiple entries at a time. Can 
+          generate: ACES reference config, ACES full config etc. Any variations 
+          are present for download independently.
+    - Validate config results against ground truth (ACES images, CTL)
+        - Michael: Proposing (and volunteering) to setup CI system, via GH 
+          Actions, to validate config transforms against ground truth CLF 
+          and/or ACES images.
+        - Thomas: There is facilities like that now, in the current ACES 
+          config. Optional utility. Generator is slow.
+        - Michael: GH Actions supports 20 concurrent jobs, so can be sped up a 
+          bit there.
+
+* Config contents:
+    - Color space, alias naming
+        - Michael: Do we keep names consistent with existing config? A question 
+          was raised in ocio-dev regarding underscores in alias names. Without 
+          underscores, many color space names become problematic.
+        - Thomas: Make configurable delimiter for future version.
+        - Stick with existing names?
+        - Thomas: Can change names, but need easy way to migrate. People are 
+          building pipelines around this to do conversion. If we break 
+          everything, people will be sad.
+        - Kevin: Is there anything wrong with existing names? Or just opinions?
+        - Thomas: The later.
+        - Kevin: For OCIO v2 we had discussed being able to deprecate color 
+          space names but maintain backwards compatibility. 
+        - Doug: The new inactive color space feature supports this, yes. 
+          Deprecated spaces would work in color space transforms, but not 
+          discoverable in menus.
+        - Kevin: Need survey monkey to get feedback on general opinions of 
+          naming, etc.
+    - Displays, views, reference spaces, looks.
+        - Michael: Should displays and views be restructured to use OCIO v2 
+          features like display reference space and view transform. Might be
+          good to organize views by actual display instead of grouping under
+          one ACES display.
+        - Doug: Current config was setup to avoid display use. Needs to be 
+          revisited. To what extent do we want to use v2 features. They are 
+          optional, but would help with working.
+        - Mark: Make it v2 as much as possible, and if someone complains, 
+          make a backwards compatible config off the tail-end of the project. 
+          Good opportunity to force DCCs to do the right thing. Incentive.
+        - Carol: v2 makes things easier to implement. Will want config that 
+          works and takes advantage of new features.
+        - Doug: Good opportunity to ask vendors to improve things. Could put 
+          together list of minimum expectations: support displays, views, 
+          looks, etc.
+        - Sean: Agree on using displays properly.
+        - Matthias: Maintain family names (which group color spaces in some 
+          DCCs, like Nuke)? Want to keep name similar to aid migration, but 
+          might want to fix family names.
+        - Doug: v2 has option to build hierarchical menus from family.
+        - Sean: I think the ACES config families were a reaction to the size 
+          of the config.
+        - Thomas: Worth pinging vendors, to have more people on the table 
+          discussing that.
+        - Sean: Can't blame vendors in previous version. We didn't tell them 
+          what we were looking for.
+        - Kevin: Think the idea of roles appearing in menus was an annoyance. 
+          Roles should be a Pipeline detail.
+        - Michael: The new categories don't work with roles right?
+        - Doug: Categories are for reducing color spaces in menus based on use.
+
+* New code base:
+    - Doug: Where did we land on whether old code could brought over?
+    - Michael: I don't think it can with the current license.
+    - Thomas: Would be better to start fresh.
+    - Sean: Also thinking to start from scratch. To make it work well for CI 
+      too.
+    - Doug: Agree.
+    - Michael: When should we target completion for this project?
+    - Doug: OCIO v2 stabilization period over second half of year. Vendors will 
+      work on incorporating, and find bugs, etc. Want people to start using it 
+      before that.
+    - Thomas: Are builtin transforms being shipped at that point?
+    - Doug: ACES transforms are there now. Over stabilization period we could 
+      increase number of builtin transforms. Not changing API. Just adding stuff.
+    - Michael: Can we have something functional by end of year?
+    - Sean: Good to have unit test config at feature complete time. Need 
+      something to get right impression at start.
+    - Mark: There will be a long period of requiring v1 configs, until every 
+      DCC at studios is updated. Might be period where this config can't be 
+      used.
+    - Carol: Some people might not use OCIO v2 until there's a config.
+    - Goal is to target reference config at feature complete time, and 
+      end of year for "studio in a box". This working group will meet at the 
+      same day and time every other week, for now.
@@ -0,0 +1,145 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+June 30, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Troy Sobotka
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Initial color spaces:
+    - ACES discovery code (Thomas): 
+      [Graph](https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/3) 
+    - Thomas: Generated by python code which discovers all CTL transforms. 
+      With v2 we know what transforms are needed (graph edges), supported 
+      by OCIO BuiltIn transforms. Graph can be basis for building config. 
+      Once edges are implemented, the config is done.
+    - Doug: Would like to see BuiltIn transforms for all of these edges.
+    - Thomas: Can build config generator on top of that. Plan of least 
+      resistance. Discovery work also good for finding errors on ACES side.
+    - Kevin: This implementation could lead to a lot of transform 
+      duplication. Would that be simplified?
+    - Doug: In BuiltIn transforms, it's already factorized.
+    - Kevin: Thinking in terms of expressivity. Programmatically building 
+      this graph would fail to show underlying relationships between color 
+      spaces.
+    - Doug: If we are using BuiltIn transforms, we could break them down 
+      into matrix and non-linear components, composed as ColorSpace 
+      transform transforms. Already set up this way internally.
+    - Mark: ILM internal config generator does something similar. Generates 
+      color spaces composed of other color spaces, mapping of gamuts and 
+      transfer functions. Useful to generate all gamuts first, and from 
+      there generate all transfer functions that need each gamut.
+    - Michael: Would ACES GH repo be a runtime dependency or cached?
+    - Thomas: Runtime, like CI process.
+    - Doug: Good to have no external file dependencies.
+    - Thomas: For studio config could add extra LUTs, etc. Think everything 
+      in reference config can be expressed without LUT. Should just work.
+    - Doug: Even things that typically require LUTs, BuiltInTransform can 
+      handle it.
+    - Kevin: What about back port to OCIO V1? Bake color spaces from v2 
+      config?
+    - Thomas: Not planning to change anything for v1. This code won't work 
+      with v1 currently.
+    - Michael: Initial config solution is essentially a BuiltInTransform 
+      matchmaking system.
+
+* Display & views:
+    - Doug: Should do proper views and displays in this config version, Rec. 
+      709, Rec 2020, etc.
+    - Thomas: Can group/organize config how we want.
+    - Michael: Could use RRT view transform (display reference space), and have 
+      display/view per ODT
+    - Kevin: Would be good to do that, to express things properly.
+    - Mark: There are some differences (parametric display transform) which 
+      might make that not work.
+    - Carol: The new RRT+ODT design is more parameterized.
+    - Doug: In recent work, RRT+ODT is called output transform. More recent HDR 
+      work generates these as one piece. Can be expressed with view transform.
+      The display reference space would include part of ODT. We do this now 
+      with the SynColor CTF ACES transforms.
+    - Matthias: Would display reference be dependent on display device?
+    - Doug: Possible to have display reference space that is generic. Can be 
+      CIE XYZ. Just need to implement.
+    - Michael: Would the discovery code automate display creation from CTL 
+      directories, since they are grouped like that?
+    - Thomas: Already how the code is structured.
+
+* Looks:
+    - Michael: Are there cases where we want to define looks as well, for the 
+      blue light artifact fix for example.
+    - Carol: Depends on the ACES gamut mapping working group :)
+    
+* Next steps:
+    - Michael: As a first step, perhaps we should generate a simulated config 
+      structure. Can act as a TODO list.
+    - Thomas: Yes. Mock config to plan everything out. I can commit current 
+      code to a special dev branch, where it can be contributed to by others. 
+      Will set up README too, and then we can work on generating an initial 
+      config.
+    - **TODO**: Thomas will open PR with discovery code in 
+      OpenColorIO-Config-ACES repo.
+    - Mark: I Want to help once OpenColorMath is ready. It could help a lot 
+      with generating the ACES configs.
+    - Thomas: Mark's code could be leveraged to make the config studio grade. 
+      All the added transforms to be finishing for the remaining part of the 
+      config.
+    - Kevin: There are currently multiple Sony S-Gamuts, depending on which 
+      camera an image is coming from. How would this be implemented. Different 
+      name for each?
+    - Thomas: Need to determine how to name things. 
+    - Doug: Could use naming from ACES.
+    - Carol: How can we get more help? We should reach out to Slack, ocio-dev, 
+      ocio-user for new input, since this work is Python, it is more accessible.
+    - Thomas: Agree. Let's just wait till the project is rolling. Once there 
+      is a plan. The code is Python, but the config is non-trivial to develop; 
+      but simpler than C.
+    - Sean: How much automation is intended for building the config?
+    - Thomas: Full automation for reference config. 
+    - Doug: Anyone want to help with adding missing ACES components in BuiltIn 
+      transforms? Work is pretty straightforward. ODT part should be 
+      facilitated by another in-progress PR. Could start with input transforms 
+      first, and in a few weeks go to output transforms.
+    - Thomas: Could there be mock transforms? To at least test the config? 
+      Would a mock config break if transforms are missing? Can we have mock 
+      transforms (as an outline, TODO list of sorts).
+    - Doug: Great idea. Contributors can then fill in the blanks to help. Let's 
+      get transform IDs and fill in BuiltIns for all of those.
+    - **TODO**: Michael will create GH Issue about building out full ACES 
+      BuiltIn transform skeleton to guide contributors.
+    - Sean: The dependency chain between the config, OCIO, and ACES will be 
+      tricky. Dependent on transforms existing in OCIO core first. How to do 
+      releases? Tag? 
+    - Thomas: Work in branches to reference precise state of ACES dev.
+    - Sean: There will be cases where we want a color space in config, but 
+      there's a delay with deploying a new OCIO version. May have to deliver 
+      LUT temporarily.
+    - Mark: Or write an expression via OpenColorMath.
+    - Sean: Since there will be multiple config flavors, users will need to 
+      reference specific config versions. Problem of sharing between studios 
+      since it won't just be "the ACES config". Which ACES config?
+    - Michael: In the last meeting we discussed having two flavors; an ACES 
+      reference config, and the "studio in a box" config, which would be 
+      created later, on top of the ACES reference config code.
+    - Thomas: The config generator needs to be easy to use. That will be 
+      important.
+    - **TODO**: Determine branch, release and versioning strategy.
+    - Sean: Missed Thomas' issue with the graph. Is the repo integrated with 
+      Slack yet?
+    - Doug: Slack connection would be good.
+    - **TODO**: Michael will request Slack integration for the 
+      OpenColorIO-Config-ACES repo (from LF releng).
@@ -0,0 +1,72 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+July 28, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Troy Sobotka
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* License, copyright choice:
+    - Need to decide whether to use OpenColorIO's statement, or make a 
+      project-specific copyright ("Contributers to the 
+      OpenColorIO-Config-ACES project"). John Mertic suggested reusing
+      OpenColorIO statement unless this project will have its own 
+      governance, different from OCIO.
+    - Group agrees to use same OpenColorIO governance and statement, 
+      operating as a sub-project.
+    - **TODO**: Thomas will update PR #4 with revised statements.
+
+* Feature complete state of BuiltinTransform:
+    - Michael: OCIO v2 being feature complete does not include all ACES 
+      transforms, correct?
+    - Doug: Correct, not needed to have all transform initially. Key thing it 
+      to have examples which can be built upon. This is a feature more useful 
+      to config authors than application integrators. Anticipated working on 
+      this after feature complete.
+    - Thomas: Makes sense to have skeleton generated by then. People can then 
+      write transforms, and work incrementally.
+    - Michael: Really just need to modify output to build config instead of 
+      graph.
+    - Thomas: Transforms already are there - graph is built on it. Could 
+      possibly use graph to generate config.
+    - Mark: Been writing CTL parser that can compile and eval CTL differently. 
+      Have interpreter, which can live compile and run CTL code.
+    - Thomas: There's an ACES central thread on future of CTL, discussing 
+      similar points. Would be great to share this work there.
+    - Mark: Expression transform can then work with CTL directly, and emit 
+      glsl, etc to support different renderers.
+
+* Next steps:
+    - Use ACES discovery code to generate skeleton OCIO config. Transforms can
+      be omitted to start, unless just using a ColorSpaceTransform to convert
+      between other color spaces.
+    - Skeleton will be used to outline missing BuiltinTransform algorithms 
+      needed to complete reference config.
+    - Reference config will NOT be ready for SIGGRAPH.
+
+* ASWF contributions?
+    - Thomas: If time is issue to contribute, could ASWF provide resources to 
+      help complete the work. ACES contracted the creation of the original 
+      ACES OCIO config for example.
+    - Michael: There was some early discussion following GSoC as to whether the 
+      ASWF could hire students or developers for a similar dedicated program, 
+      but it hasn't been discussed further. ASWF premier members do commit to 
+      providing the equivalent of one full time engineer (FTE) to ASWF project 
+      contributions each year, so it's possible we could get some help through 
+      that.
+    - Thomas: Good to have something formalized. 
+    - Carol: As we get past launch, we might have more time. We're likely to 
+      attract new people to the community. We’re all swamped.
@@ -0,0 +1,144 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+August 25, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Update on config skeleton generation work:
+    - Thomas: Started working on config generation code. Dove into OCIO v2. 
+      Have some of it working, but difficult to go through new things without 
+      complete documentation. One missing piece was the new viewing rules.
+    - Michael: Maybe be more brute force for now with views. Could refine with 
+      viewing rules later.
+    - Thomas: Hoping I could generate OCIO v1 or v2 configs for wider use too.
+    - Doug: Looked at the feedback that was posted to Slack.
+    - Michael: Yes, great feedback for working on docs.
+    - Thomas: As many examples as we can get would help. Help to wrap head 
+      around new features. It is easier to build OCIO now. More docs are 
+      needed; viewing rules in particular.
+    - Carol: Lots of stuff in doc working group around using the ACES ref 
+      config to document new features.
+
+* Community feedback on current ACES (studio) config:
+    - Thomas: Thread on 3d pro about this. Complaining of complexity. Too large 
+      to be useful. Want simple. System has to increase in complexity, but 
+      interface needs to be simpler. Too many color spaces in Nuke, DCCs, etc. 
+    - Michael: Might need to do without aliases.
+    - Thomas: Aliases are option when building config. Should look at docker 
+      container for building config.
+    - Mark: A lot of the complaints of multiple color spaces are issues with 
+      not approaching things correctly. Someone should convert inputs to ACES 
+      2065-1 for them to be consistent. Don't need to see other complexities in 
+      pipeline
+    - Thomas: Studios without color scientist will take what is available for 
+      working with ACES, and what’s available is giant and requires someone to 
+      be color savvy. Someone else commented that the biggest issue is lack of 
+      guidance on how to use it, and to work with wide gamut color spaces.
+    - Carol: Majority of use cases the ACES reference config will solve some of 
+      that since it’s just ACES. What’s our role in supporting non-ACES 
+      workflows in the studio config.
+    - Kevin: If people are expected to take config and use it as is, the config 
+      won't contain the LMTs. Some shows hand over LMTs so then they need to 
+      roll their own config. What I do internally is build a simple config for 
+      the specific show, but not put too many camera color spaces in there. We 
+      take the ACES config, trim it down to needs. Most people would be better 
+      to have a tool.
+    - Carol: That and the education around that would be great. But small shops 
+      don't have the knowledge to edit the config, so take it as it ships and 
+      use that. If we can make it easy for that use case, would be great.
+    - Mark: Some ACES shows use an LMT process that splits into multiple parts 
+      that can't be slotted into a standard config. We use a config generator 
+      at ILM based on requirements. We still generally make all the color 
+      spaces available. We have less obscure color spaces that tend to be in 
+      there. Have to manually edit to deal with coroner cases. Only way out of 
+      it is to put pressure on DI facilities and production companies on 
+      working the correct way, so LMTs and CDLs can be slotted in easily. 
+    - Doug: Technically LMT is supposed to have ACES 2065-1 as working space, 
+      but doesn’t seem like that happens. CLF will allow easier way to package 
+      more complex looks.
+    - Mark: Would need to be per-shot like it is with CDL. Would like to avoid 
+      3D LUT per shot.
+    - Kevin: We often throw away CDLs and replace them, so keep them separate 
+      from LMT. CDLs are useless after VFX integration starts to happen.
+    - Michael: It will be a UX challenge to know how to allow building custom 
+      versions simply.
+    - Mark: Could be trailblazer and enforce proper ACES workflows. Force 
+      fitting in with blocks we give them.
+    - Doug: Academy is also pushing ACES metadata file which defines a 
+      pipeline. Positioning that as the way to figure out the look. An open 
+      question - need to apply AMF for with plate with OCIO. No proposal for 
+      how that will work yet.
+    - Carol: May need script to build OCIO config from AMF.
+    - Doug: The AMF could refer to the OCIO standard transforms, and bake a CLF 
+      from that pipeline. One possible answer.
+    - Mark: AMF file describes pipeline from camera source to display. 
+      Somewhere in there need to wedge those pieces apart.
+    - Carol: Pipelines can layer on each other, and they are loosely defined.
+    - Mark: AMF file seems to be its own implementation of a color pipeline, 
+      conflicts with OCIO config. Would need editing or changing.
+    - Carol: AMF meant to replicate the version of ACES a project is using.
+    - Kevin: One thing people complain about is the number of color spaces. 
+      There are features to limit that exposure. Tagging etc. Is part of the 
+      problem that that doesn't exist today? That might help solve some of the 
+      problems.
+    - Thomas: More complaints: need stripped down config for rendering (i.e. no 
+      camera spaces). Education. Productions had honeymoon period with ACES, 
+      but it didn’t solve some problems - topics being solved by the gamut 
+      mapping working group. Good point that people thought ACES would solve 
+      all their problems and in the end it didn’t.
+    - Doug: ACES has been promoted heavily, but there are gaps and roadblocks 
+      people run into along the way.
+    - Kevin: Sounds like people are assuming ACES is what brought along these 
+      problems, but you have the same problems with other cases of blending 
+      cameras together. Not ACES that brought these problems. All the cameras 
+      brought them.
+    - Michael: Are the filtering/categorization features enough to provide a 
+      simpler interface as they are now? 
+    - Thomas: Good point. Going to come down to DCC integration, and how it is 
+      presented to user.
+    - Kevin: In Baselight it presents groups of color spaces based on what you 
+      are doing and allows a modifier key to show everything when needed. 
+      Ability to enable hidden color spaces.
+    - Michael: OCIO v2 adds inactive color spaces.
+    - Doug: Inactive color space are for deprecated spaces. Filtering would use 
+      categories instead. Context based.
+    - Mark: At some point you have to know what the config author has decided 
+      and per DCC need a preference file to say what in a config should be 
+      displayed. Either need an API call, or some other configuration outside 
+      of OCIO.
+    - Doug: Inactive (env var controllable) color spaces could be used, but a 
+      bit brute force. The categories and encoding are attributes of a color 
+      space, more for config author, and application driven how that is used.
+    - Mark: Might be good for docs team to do a style guide showing DCCs how to 
+      design interfaces for working with OCIO, and what API calls to use.
+    - Thomas: Or write a PyQt app to demonstrate the interfaces. Good to show 
+      vendors how we're intending the config to be exposed.
+    - Doug: That’s what the app helpers were intended to do. Would be nice to 
+      have python thing on top of that.
+    - Kevin: Other way of filtering is with tasks/departments. In rendering 
+      they don't care about camera spaces, for example. DCC/context based.
+    - Michael: That can be facilitated by categories.
+    - Mark: Needs to be set with env vars which categories the DCC should 
+      display.
+    - Doug: On our todo list. Come up with list of categories and tell people 
+      how to use them.
+    - Kevin: How do we get people to use these categories when writing configs. 
+      Might need to be opinionated.
+    - Mark: I'm interested in how to generate config, but not able to give the 
+      time. Might be able to show how internal tools work that generate configs. 
+      Generates config from scratch. Could possibly contribute.
+    - Michael: We might be able to find a UX person to contribute as well.
+    - Mark: Be nice to have builtin implementation finished first.
@@ -0,0 +1,192 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 8, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+
+Apologies:
+  * Sean Cooper
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* PR #5 - “aces-dev” Reference Config Generator:
+    - Thomas: In progress. Big missing piece is transforms, which are not 
+      mapped yet, but color spaces should all be there.
+    - Michael: Question about "undefined" display. Can that be named?
+    - Thomas: Trying to massage CTL to get names. aces-dev not ready to be 
+      ingested like this. Transform IDs are busted. Display is "undefined" 
+      since it contains transforms that are not categorized. Scott will 
+      classify these.
+    - Michael: HDR most likely?
+    - Doug: Ideally classified as P3-D65, ST2084, etc.
+    - Thomas: BuiltinTransform next piece. Then talk about what to do for 
+      displays, display reference space, etc. Doing some string massaging, 
+      which prevents matching old ACES config. Should keep names consistent 
+      where possible.
+    - Doug: There is an issue in OCIO GH talking about improved way to deal 
+      with aliases. Current ACES config  has many aliases for including in 
+      file paths, but it’s a maintenance problem since the color spaces are 
+      duplicated. Could add an alias feature to color space in core OCIO.
+    - Michael: Have written code to alias by duplicating color spaces in the 
+      past. Alias feature would be useful.
+    - Doug: Without fallback mechanism, will create unhappy users.
+    - Michael: Would create clutter trying to be backwards compatible without 
+      that.
+    - Thomas: Maybe we can create a shim, or document/tool for migration. 
+      Otherwise we're building on dirty foundation.
+    - Mark: Also missing the new color space name formatting. Had discussed 
+      move to transfer function and gamut convention. If we were to move 
+      forward, would be good to make ground truth adhere to that first.
+    - Thomas: Tried to be consistent, but we can change the way things are 
+      named.
+    - Michael: Tricky because would require scripts to edit DCC scene files. 
+      Maybe just provide data for mapping in implemented pipeline code.
+    - Thomas: It won't just be names. There is stuff that needs to go away to 
+      clean up config. Mapping doesn't cost much, can have it.
+    - Kevin: What has been generated makes sense for core ACES, since it 
+      follows CTL. The more encompassing config could follow the old naming to 
+      help with migration. Could be fit into generator. Color space names 
+      issues should be fixed on ACES side, if users want to adhere to ACES.
+    - Thomas: Problem is if we allow users to stick to old naming it will 
+      prevent migration. Maybe provide method, but not direct support.
+    - Doug: If we had ability to define alias with color space, a DCC would use 
+      the official name, so if someone opens something that uses the old name, 
+      the DCC could do conversion automatically through alias system.
+    - Mark: Don’t think it will matter much. Not great when DCC writes color 
+      space name to file. Can use roles now to accomplish this.
+    - Matthias: Roles would perpetuate the old names.
+    - Mark: Don’t think DCC needs to be considered as long as names resolve to 
+      the correct color space.
+    - Doug: Our DCCs do need to store color space names to save color 
+      management behavior. Could be manageable to convert names though.
+    - Matthias: Would this lookup be provided as a separate file? Or would this 
+      be provided as part of a color space definition? And DCC would see that 
+      it’s an alias and update the string value to the actual color space?
+    - Doug: The proposal on GH is just to add alias attribute with list of 
+      strings. Haven't figured out details, but an API call could be added to 
+      check if a name is an alias or not, to get the canonical name.
+    - Mark: That would help the DCC but not the user. If the old name had a 
+      different family for example, would that require family aliases, etc?
+    - Matthias: Trying to avoid users perpetuating old names. Can put that in 
+      documentation somewhere. 
+    - Mark: How to handle the months during transition. Is it worth the effort, 
+      or do we encourage starting fresh?
+    - Doug: Wasn’t clear to me that aliases need to show up in UI at all. 
+      Internal convention.
+    - All: Agree that aliases don't need to show up in UI.
+    - Mark: It’s mostly so that a DCC that saved with the old name can continue 
+      to work with the new name.
+    - Carol: People will want to know what the changed color space names mean.
+    - Mark: Only way to describe is with description string, or in name.
+    - Doug: Was thinking most of these changes would be fairly clear, subtle 
+      renames. Different, but similar. Names are informed from string. Previous 
+      aliases were for convenience for filename and commandline tools.
+    - Carol: Yes, would be cool to have that as alias, but not color space 
+      name.
+    - Mark: Think all color space names should be clear, short names, and put 
+      more data in description.
+    - Kevin: Also issue of AMF files referring to color spaces by name from 
+      ACES. 
+    - Thomas: We could also store full ACES transform ID as alias. Ground 
+      truth.
+    - Mark: That’s AMF consideration though. Nothing to do with us.
+    - Carol: Has to do with us if we need to relate AMF to OCIO config. 
+    - Mark: There’s been little coordination from AMF team about how that 
+      information is supposed to flow into VFX world. Will be responsibility 
+      of AMF reading tool and authors to handle these details.
+    - Carol: If we’re designing an ACES reference config, AMF is part of ACES, 
+      so we need to consider how the whole ACES pipeline works together.
+    - Kevin: Agree with Mark that we won't use this internally, but we will 
+      have to deal with it with vendors who we need to hand files off to.
+    - Mark: We’re supposed to represent ACES in a way that works well for OCIO, 
+      which may not be perfectly inline with how ACES community names and 
+      structures their files. Much more concerned with how this config will 
+      work as OCIO config. Less about AMF and Academy structure decisions. 
+    - Thomas: It is an ACES config though.
+    - Carol: Be better if we worked together rather than working in silo. We 
+      can work with ACES to make a better OCIO config.
+    - Doug: at the end of day, naming discussions are contentious. The 
+      transform ID strings are a bit missed up, but Scott will probably fix 
+      that. This may be a logo requirement too. To be product partner we’ll 
+      need to follow logo guidelines. The name that shows up in UI is under 
+      their purview. Open to our participation, but not realistic to sway 
+      their naming based on our limitations (i.e. name in filename).
+    - Carol: Think the alias solution is a good solution. Pretty elegant and 
+      don't think people would have a lot of issue with it.
+    - Thomas. Yeah, at end of the day its a UI issue. DCC can choose to switch 
+      the display of color space on their end.
+    - Doug: From a DCC perspective, we’re trying to let the config author 
+      decide that. At the end of the day the config should define the names in 
+      menus, but maybe DCC could add option to see aliases for canonical name. 
+      More a DCC specific choice based on requests from user base.
+    - Mark: If we make blanket statement that alias never shows up in DCC, then 
+      they have to be entered as separate color spaces with duplicate entries 
+      in config.
+    - Doug: Would be possible to get alias reference from API.
+    - Mark: Think it would be better for aliases to be only for backwards 
+      compatibility.
+    - Doug: Yes agree. If you need something to show up in menu, should be 
+      added as duplicate color space.
+    - Carol: From a user perspective, the general user may not understand that 
+      the canonical and alias names are the same and can be used 
+      interchangeably. That’s a concern we hear a lot.
+    - Matthias: Could aliases show up in description string in tooltip in DCC?
+    - Dennis: Is there a recommendation on creating hierarchy based on 
+      separators?
+    - Doug: Family can be used for that and some code in OCIO helpers will help 
+      do that. Now a 'family_separator' property to help standardize.
+
+* BuiltinTransform skeleton, implementations:
+    - Michael: Now that the config skeleton is created, will need to create 
+      skeletons for BuiltinTransform in core OCIO. Thoughts on how to proceed?
+    - Doug: Builtin transform accessed with a name string. Ideally with this 
+      mechanism in place to pull names from ACES, would be cool if those 
+      strings could match up in core OCIO to avoid manual interventions.
+    - Thomas: All the strings you see here are programmatically generated from 
+      CTL transform ID. Can be used to call transform. Could use CTL transform 
+      ID. Will try adding transforms next week to see how config generates. 
+    - Michael: Wait for config update to touch C++?
+    - Thomas: Yes, in next two weeks will find some time.
+    - Michael: Will all builtin transforms use existing ops? Is anything 
+      missing algorithm-wise needed to support ACES?
+    - Doug: Some, like PQ will be represented with LUT, but can be generated 
+      internally.
+    - Thomas: Maybe the current generator could generate core skeleton from 
+      aces-dev. Instead of manually going through and adding everything. Maybe 
+      could generate the files. Just a suggestion.
+    - Mark: Think we want to keep those things separate. Be human added.
+    - Thomas: Could be a lot of files.
+    - Mark: Want someone to vet them.
+    - Thomas: Agree. Generation code could just generate them, and then review 
+      that code manually. Think will need a discreet file per edge in the 
+      graph, and there are a ton of edges in graph. If you want to reference 
+      implementation, we need a transform for each edge.
+    - Mark: Your current PR is more than we would consider in the library. 
+      Current config has camera transforms.
+    - Thomas: Yes, IDTs can be removed. Let’s talk just about output 
+      transforms. Think we need a builtin transform for each discreet ODT.
+    - Doug: For output transforms, it’s a bit of a separate case. Will make 
+      proposal of how to use display reference space and view transforms to 
+      reduce the builtin transform requirement.
+    - Kevin: Could write a parser for CTL to generate OCIO properly. Detect 
+      matrix operator, etc.
+    - Mark: Working on CTL parser for OpenColorMath, which was hoping could be 
+      used here. Then could reference CTL directly.
+    - Michael: Can always update implementation later.
+    - Doug: Want something in near term to help people use new OCIO. Going to 
+      update config writing to not write default values, which will reduce 
+      config size.
+    - Mark: If no equality groups, entire config is a no-op. That will need to 
+      be addressed.
@@ -0,0 +1,180 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+September 29, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Christophe Brejon
+
+Apologies:
+  * Kevin Wheatley
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Update on config skeleton generation work:
+    - Thomas: For practical purposes it's in a state where it should work with 
+      builtin transforms. Most concerning issue right now is the ACEScc builtin 
+      transform is not serialized. The transform is created correctly, but when 
+      the config is written, nothing is in the config. Good that it doesn't 
+      support non-existent style. Also CDL transform methods not working.
+    - Doug: We have unit tests for CDLTransform, so not sure. May be untested 
+      issue.
+    - Thomas: Serialization issue is just this one transform. Others are fine.
+    - Michael: Should we auto generate builtin transform cpp code or do the 
+      work manually?
+    - Doug: Depends which transforms, but if we at least agree on names, that's 
+      a good step forward. If we agree to take them from CTL, as Thomas is 
+      doing, that makes sense. Going to come down to manually writing the code.
+    - Michael: Agree on manual approach, to have comments, etc.
+    - Thomas: More thinking to generate stub files to be filled, since the data 
+      is there.
+    - Mark: From current config, FileTransform in there now. Will there be 
+      external files?
+    - Thomas: Just a placeholder until builtin transform styles are supported.
+    - Michael: Thomas raised a question about direction in PR. As to whether we 
+      should follow typical transform forward/inverse behavior, or have 
+      separate named transform per direction?
+    - Thomas: Either approach is fine with me, but prefer small things which 
+      are easier to test and maintain.
+    - Doug: all transform have direction attribute, so needed, but nothing 
+      prevents us from having both directions as transform names.
+    - Mark: Prefer log-to-lin since the inverse order has precision loss in a 
+      LUT, but for the facade that the builtin transform has it shouldn't 
+      matter. Use most optimal and have both in interface. If people don't need 
+      to read docs and just use transforms, having both directions would make 
+      it easier.
+    - Matthias: From config author standpoint, good to have both.
+    - Thomas: Make it clearer when going from reference. More explicit is better.
+    - Mark: not sure how helpful to have every transform in both directions. 
+      Do we need to do output transforms in both directions For example?
+    - Doug: We don't have to explicitly put them in config if no reason to. If 
+      OCIO can generate the other direction. Was that the questions, needing 
+      both from_ref and to_ref?
+    - Thomas: Since it's from CTL, will get both sides from some transforms. 
+    - Doug: In general there is a need to combine two CTL files in repo to 
+      generate a single color space. Need some logic for that. Sounds like we 
+      agree that builtin transform should define strings in both directions, 
+      but then there's the question of the aces repo that has CTL in both 
+      directions (no inverse argument). Thomas' generator looks at CTL and 
+      builds color spaces. Most of the time there are two CTLs but don't want 
+      two color spaces.
+    - Thomas: In aces-dev if both directions are defined, you’ll get from and 
+      to reference transform in color space in the config.
+    - Mark: Think that’s fine. OCIO generated in reverse not as good as manmade 
+      inverse. Don't think thats a problem.
+    - Thomas: Think it should stay as close to metal as possible, to aces-dev. 
+      The studio config can be massaged differently, but this one as a base 
+      should be close to CTL. Could be good for Scott and Alex to be able to 
+      see it as a test bed.
+    - Mark: Only new feature in OCIO v2 in this regard is 3D LUT inversion and 
+      don't want to rely on that vs. using the actual inverse.
+    - Doug: shouldn't be 3D LUTs in aces config unless there is camera vendor 
+      spaces. Under the hood the builtin transforms we will just write one and 
+      the other will be implemented with direction flag. CTL not ideal in this 
+      regard. OCIO generated inverse will be at least as good as CTL.
+    - Carol: Think an explicit definition for any 3D LUT in CTL would be a case 
+      for that. If we all trust and use the inverse calculated by OCIO, that 
+      should be what we use in the config.
+    - Mark: The builtin transform won't show you that they need a 
+      from_reference. Each has it's own implicit from_reference. If you use 
+      builtin transform you can assume an inverse exists. Should guarantee that 
+      all builtin transforms are invertible.
+    - Carol: Should not need to define both from or to reference. Since it is 
+      mathematically high precision and invertible, defining both not needed.
+    - Thomas: An interesting case is the IDT going to reference and ODT from 
+      reference. We could do one or other, but could do it the way CTL is 
+      implemented. If we want to impose a direction we can, but think there is 
+      value for Scott and Alex and AMPAS people to represent how they are 
+      implemented on CTL side as faithfully as possible.
+    - All: Agree that is fine.
+    - Matthias: Could also serve as a guideline for how to build an OCIO 
+      config. Helps see where it's good practice to have transform from and/or 
+      to reference, that don't need both always defined.
+    - Thomas: Yes, it's logical, that's how it flows in ACES, so good to follow 
+      that.
+    - Mark: Might end up having to use builtin transform with opposite name as 
+      a result, but that's fine.
+    - Michael: Any interest in starting work on builtin transform 
+      implementation on the cpp side?
+    - Mark: I am interested, but hoping to replace it eventually.
+    - Michael: Good to see current implementation to understand the needs, even 
+      if it changes later.
+    - Mark: Will look at what Thomas has and give one of them a try.
+    - Doug: Recommend not starting with ODTs. Would be better to use spline 
+      operator for tonecurve, so I should provide an example of an output 
+      transform first. Good to start with input transforms. Already some 
+      examples in there for reference. A basic starter set, all of the ACES 
+      color space conversions are done.
+    - Mark: Is a LUT built at runtime?
+    - Doug: In some cases no LUT is needed, when CameraLog transform can be 
+      used, but we did include some examples where Lut1D is needed. A lot of 
+      the curves use the same formula with different constants, so that can be 
+      used when the formula is similar. ACEScc transform needs an update, but 
+      there are examples of 1D LUTs in there.
+    - Mark: Skeptical that they match. Had problems where formula didn't match 
+      official spec at bottom of significant digits, so mixing official LUT and 
+      parametric formula, not sure they will match and roundtrip.
+    - Doug: Fair amount of discussion in CLF working group around this. Scott 
+      and Alex signed off on this approach. Sometimes manufacturers don't do 
+      good documenting for implementation because of included significant digits.
+    - Matthias: Has anyone come across anything that doesn't work with this?
+    - Doug: There are some examples. ACEScc needs Lut1D and some camera 
+      examples (Cannon) wen their own way.
+    - Michael: OCIO follows the CLF implementation, so ops should adhere to that.
+    - Doug: Yes, but CTL doesn't.
+    - Mark: Disappointed we're not generating these at build time, but probably 
+      not expensive to build at runtime.
+    - Doug: Faster than parsing LUT file.
+    - Matthias: Reasoning behind maintaining color space naming from previous 
+      ACES config? Where family name duplicates color space name and makes long 
+      color space names. Can break combo boxes.
+    - Carol: It’s the academy’s names, matching CTL transforms.
+    - Matthias: Do we want to keep family name in front of everything?
+    - Thomas: Can trim it.
+    - Matthias: Already condensing names in builtin transforms. Would prefer 
+      those names to the color space names.
+    - Thomas: The current naming trying to stick to original naming, but easy 
+      to change. Would be good for people to pull down the code and start to 
+      play with it. Might give some ideas. One of next steps was going to do was 
+      dockerize the generation. Will work with OCIO containers.
+    - Michael: Aloys is working on ASWF docker images for production. Beyond 
+      the current CI images, which will have full builds with tools, etc.
+    - Thomas: Anything we can do to streamline the work for people would be 
+      good. Docker is a good solution.
+    - Doug: Agree that sounds useful.
+    - Thomas: Will work on that to make the setup one click.
+    - Michael: Do we have a decision on color space naming changes?
+    - Mark: Once we can get a config to play with we can play with and suggest 
+      changes.
+    - Thomas: Can be parameterized too.
+    - Mark: Could get in touch with Academy to get their blessing on improved 
+      naming.
+    - Thomas: Yes, need to follow up with Scott on that. Would like to have 
+      official conversation with them. Work for consistent names in the future. 
+      Should start official conversation.
+    - Mark: Once we get something we can generate and play with that would be a 
+      good point for that conversation.
+    - Thomas: They can build it to look at on ACES side too.
+    - Mark: Would argue away from using docker. Just a python script to run 
+      would work.
+    - Thomas: If it was pure python no problem, but with OCIO, etc. it gets 
+      complicated.
+    - Mark: Should just need pure python to build graph. Do we need all these 
+      dependencies? NetworkX, etc?
+    - Thomas: You could, but good to utilize libraries that are there. You can 
+      replace, but more maintenance on our side.
+    - Mark: Every dependency has a cost. Gets passed on to users. Having to 
+      download lots of libraries to build a config not ideal.
+    - Thomas: Matter of balancing cost. If you have something available that 
+      works well, why reinvent the wheel? Just use that.
+    - Mark: Gets hard for build engineer in studio.
+    - Thomas: Is work, but helpful.
@@ -0,0 +1,148 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 3, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Dennis Adams - Sony
+  * [X] Alessandra Tomassi - Industrial Light & Magic
+  * [X] J Schulte - Industrial Light & Magic
+
+Apologies:
+  * Carol Payne
+  * Thomas Mansencal
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Time change:
+    - Michael: All daylight savings shifts are now done and Thomas is unable to 
+      attend. Can we shift one hour earlier next time?
+    - All ok with this. We will try to not change time mid-daylight savings 
+      shift in future to reduce confusion.
+
+* Projects status:
+    - Michael: If there is needed discussion around the current generator, 
+      let's move that to Slack for now. Other code can be shared via a 
+      draft PR to share if needed.
+    - Mark: Still need to talk to ACES about naming goals, to get on same page. 
+      Alex was at last meeting. We should reach out to him. Since we're pulling 
+      naming from CTL, ideally correct in aces-dev. CTL in flux - some PRs that 
+      when merged will remove a lot of complexity. We can influence change 
+      there similarly to how ACES influences OCIO change.
+    - Michael: Last meeting we discussed that the input BuiltinTransforms were 
+      largely present, but needed output transforms to proceed. Is there an 
+      expected timeline for that work Doug?
+    - Doug: Will try to get something before next meeting.
+    - Mark: OCIO v2 has display transforms. Are we making use of that? Some 
+      transforms have OCES space, but PQ goes straight from scene linear. This 
+      config is supposed to represent all the features of OCIO v2. should we 
+      make use of both?
+    - Doug: Yes, will include this in proposal, but think will make use of 
+      display color spaces, so output transforms will be view transform plus 
+      display transform. OCES wouldn't have an interface. More recent ACES 
+      transforms have moved away from it. OCES was interesting theoretical 
+      idea, providing a break point between points of transform that proved to 
+      be more confusing. Would not use OCES.
+    - Mark: What would become the display space? The generator draws 
+      connections between the ACES blobs and the newer transforms skip the OCES 
+      step.
+    - Doug: Display colorimetry. All the Output Transforms go through that but 
+      don't break it out as external interface in CTL, for historical reasons.
+    - Mark: That will make it difficult to make generator which looks at CTL to 
+      generate. Not married to that plan but seems sensible for tracking 
+      upstream. Also happy to abandon it for config expressed in code if that's 
+      more useful.
+    - Doug: Was thinking could use generator to identify the ACES end and 
+      display code value end, but not necessarily use the OCES interface. For 
+      output transforms, some go direct from ACES and others through OCES, but 
+      we could handle them as if they went from ACES to device.
+    - Mark: At moment, generator doesn't parse CTL code, just looks at URN in 
+      header of files, so no way to track transforms or chains between functions.
+    - Doug: We know anything that expects OCES as input wants to include RRT.
+    - Mark: So use RRT as point?
+    - Doug: Part of problem is the RRT does not produce display referred 
+      imagery, which has caused confusion. Produces idealized output referred 
+      intermediate. Actual display referred colorimetry requires first part of 
+      ODT. RRT doesn't provide technical benefit. Think we can ignore RRT, and 
+      for transforms with OCES input, go from ACES to OCES.
+    - Mark: Not sure benefit to tracking CTL to get these relationships if we 
+      need to implement transforms. Maybe skip checking of CTL and 
+      programmatically build transforms.
+    - Michael: Could use generator for testing if not for config generation. To 
+      do image comparison etc.
+    - Doug: Thomas' generator found issues which have value to go through and 
+      report the problems. Agree it may not make sense to follow it strictly 
+      from built graph. Needs to be manual intervention at some point. Agree 
+      with treating it more as CI process.
+    - Mark: Yeah, to get the names from it and try to call those transforms. 
+      Will wait until display referred spaces are setup in ACES context.
+    - Doug: Yes, will help for me to take one transform and show how it works 
+      in OCIO. Will also reduce amount of code. The way I'm proposing it is 
+      removing a lot of the redundancy in the current CTL code. If you look at 
+      ODTs there are lots of commonalities, so my proposal takes that common 
+      part and factors it into the view transform. Will make the overall 
+      structure easier to follow.
+    - Michael: That would then be a point of divergence in the code. The 
+      current code for testing against upstream ACES, and a new generator for
+      a config itself.
+    - Mark: Will be more similar to other generators.
+    - Doug: With input transforms, ones implemented already are CSC transforms. 
+      Bunch of those are also IDTs, or the code is similar. Some slight 
+      differences between CSCs and IDTs, which were called out and not sure 
+      those have been harmonized. Need to investigate that. Should lookout for 
+      that issue. Also need to decide if we want to do all the IDTs. ARRI has 
+      one per ISO for example, and multiple versions. Tons of IDTs. Do we want 
+      to implement them all? Most can be implemented compactly with 
+      LogCameraTransform, but at the extreme ISOs ARRI introduces hermite 
+      spline to keep from running off edge of LUT, so those would need a Lut1D.
+    - Mark: Talked before about making multiple configs, with customizable 
+      generators. Think some IDTs would not make the cut, but could be in 
+      another version. ARRI could be in there since it's common.
+    - J: EI 800 would make sense, but not sure all are needed.
+    - Doug: Current ACES config has a bunch of these color spaces so need to 
+      decide about compatibility.
+    - J: Need to figure out which flavor we publish. One complaint we have 
+      heard is the config is unwieldy because of so many color spaces.
+    - Mark: Not sure how many need to be builtin transforms as well. Could 
+      include LUTs and matrices in some. Could be example for implementation.
+    - Michael: We'll need the transforms that make ACES ACES for the reference 
+      config. Others can be for the studio config.
+    - J: What determines which are included?
+    - Mark: We decide with community feedback.
+    - Doug: Thomas' graph will illustrate that. Another area where manual 
+      intervention is needed. Don't need all ARRI IDTs.
+    - Mark: Already filtering if not EI 800.
+    - J: EI 800 is base one anyway, so good mandate.
+    - Doug: Other thing about the IDTs. ACES repo doesn't include CTL for RED, 
+      Canon, etc. Also need to decide about those. In current ACEs config some 
+      work was done to track down that stuff and create transforms.
+    - Michael: Could cut off stuff not in aces-dev repo.
+    - Doug: Need some RED and Canon, and there are CSC transforms for those. 
+      Maybe don't go beyond that. Some needed discussion around what those 
+      transform are. Was hoping Thomas' work was to produce list of proposed 
+      transform IDs to use as builtin transform names. Think thats one of the 
+      next steps. Make spreadsheet of specific list of transforms. Which have 
+      CTL and which don't, and assign someone to figure out the latest and 
+      greatest collection.
+    - Mark: Lot of noise in output from generator, filtering through 
+      relationships with various rules. Not sure how much of that snuck into 
+      graph. Not sure how many intermediates we want in there too.
+    - Doug: Think it will help. Discussion that needs more community input. 
+      What is in the config and what are the strings.
+    - Michael: Can put all transforms in spreadsheet and show which are 
+      excluded and why.
+    - Mark: Can have column for what is included.
+    - **TODO**: Mark will use generator to create a spreadsheet for discussion
+      of which transforms are included in reference config.
+    - **TODO**: Doug will create example of builtin output transform in OCIO.
+
+* ACES reference config goal
+    - Michael: Shall we set a goal to have the reference config done by OCIO 
+      v2 (non-RC) release? Would be good to ship an example if possible.
+    - Mark: We can try for that. Might get pushed.
@@ -0,0 +1,176 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 17, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Christophe Brejon
+  * [X] Deke Kincaid - Digital Domain
+  * [X] Allie Moon - Industrial Light & Magic
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Zach Lewis - Method
+  * [X] Alex Forsythe - A.M.P.A.S.
+  * [X] J Schulte - Industrial Light & Magic
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+
+Apologies:
+  * 
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* OCIO output transform implementation:
+    - Doug: Working on PR to do something similar to ACES color space 
+      transforms. Add builtin transforms to facilitate making ACES config, etc. 
+      Involves mapping ACES output transform structure to OCIO structure.
+        - **See slides**: https://docs.google.com/presentation/d/1sLyY8Q4JVkM6TqDHbqq9OWAW0zNcwvJQnh_jCtM4JHU/edit?usp=sharing
+        - Plan is to map ACES 1.0 and 1.1 output transforms into OCIO v2 
+          structure. Reduces code and makes it clear how the ACES transforms 
+          are defined. Moving linearCV to outputCV section of CTL into its own 
+          transform. Transforms which have similar calculations would share 
+          components in OCIO.
+        - Naming can be discussed. Table is just straw-man for group 
+          discussion.
+    - Alex: So primaries don't come into play until clamping happens?
+    - Doug: Yes. Last slide has summary of all view transforms and display 
+      color spaces. display color spaces are very simple - basically matrix and 
+      gamma, or matrix and EOTF. Working on PR for this, but wanted to share 
+      high level thought process.
+    - Mark: What is the PR for?
+    - Doug: To add builtin transforms outlined in the slides. Each view 
+      transform would become a builtin transform. PR only on the OCIO repo 
+      (not configs repo).
+    - Mark: Does this mean we have multiple display referred spaces, and some 
+      outputs attached to each one? Or are they associated with specific 
+      displays?
+    - Doug: In display/view section of config. For example, "Rec. 709" 
+      display/view with "ACES 1.0 SDR-video" view transform, and "Rec. 709" 
+      display color space. Each would have name, view transform, and display 
+      color space. Down in 'view_transform' section of config would have the 
+      view transforms with a transform referencing builtin transform 
+      (see slides).
+    - Mark: Shame that so many view transforms are required, due to gamut 
+      limiting and simming. Not a nice common space for them all to go through, 
+      like OCES for example. Can limits not be done on display end after 
+      transform?
+    - Doug: Could be done that way. Depends what we think of as a display color 
+      space. Would take things from view transforms and move to display color 
+      spaces (limits, etc.). Did it the current way because it's nicer to keep 
+      display color spaces as simple matrix/gamma transform. The limiting and 
+      white poiont simulating parts are more of the view rather than part of 
+      Rec. 709/Rec. 2020, etc. Display color spaces kept as simple pure display 
+      specs.
+    - Mark: Under assumption that with separate view transforms, the graph 
+      would be simpler. But with the complexity, why even need the view 
+      transform? Rather than going direct from scene to display?
+    - Doug: This is more flexible. Allows adding other combinations not in 
+      aces-dev repo. Right now aces-dev doesn't have D60 sim on Rec. 2020 
+      monitor. If someone needs that there's no way to do it. With this, 
+      that could be done easily.
+    - Mark: That would need to be explicitly added to the config right?
+    - Doug: Need to decide what we need to do with ACES config. Could be 
+      faithful mapping of things just in aces-dev repo. And a studio config 
+      with the other parts in the current ACES configs. Would be a choice for 
+      config author to make. The building blocks are there.
+    - J: Know trying to map CTL to OCIO. There are lot of color spaces that use 
+      limited output, but we would never use the limited output. Adds a lot of 
+      extra outputs.
+    - Doug: These are convenance things for people that want to work that way. 
+      Common request that people don't want to put colors out that they can't 
+      preview on their device. Goes against original ACES design intent, which 
+      was to preserve all of the colors. In practice post production doesn't 
+      want to take risk on out of gamut colors and clamp.
+    - Kevin: Artistic intent to clamp in range sometimes, in DI.
+    - J: Yes, we master to an explicit target with no room for 
+      misinterpretation.
+    - Michael: The idea too is that the config generator would be configurable. 
+      Definitely the studio config, but we could also make the reference config
+      configurable to include/exclude certain transforms, like limited outputs.
+    - Doug: Could also make them inactive, and just turn them on, wouldn't need 
+      to re-generate. Either way fine though.
+    - Carol: Get the reasoning for adding ACES version to the naming, but also 
+      don't know how much that's going to be relevant to people. For change 
+      control mechanism?
+    - Kevin: Runs risk of comparing versions and saying one is better than 
+      other.
+    - Mark: Need it to support revisions. Very internal pieces.
+    - Carol: Would version config with transforms usually.
+    - Doug: Name of builtin transform definitely have version in it, but only 
+      seen by config author. Good point that for user facing parts, do we need 
+      the version in there?
+    - Matthias: If the SDR transform hasn't changed and we're on new version, 
+      means that the SDR transform is still same for new version. Consistent 
+      version number that matches latest version of ACES release. If all taken 
+      from same ACES version, use current name, instead of old name.
+    - Mark: Can alias them between versions and have same math if that helps 
+      people. Gives flexibility for building version specific configs.
+    - Kevin: Version number change makes sense when look changes.
+    - Mark: Would be nice if you could make a config based on specific ACES 
+      version, aliasing versions to keep them up to date.
+    - Doug: One concern on ACES side about the transform ID. Thomas pulls name 
+      from the ID, which has persistent name for things like ACES metadata 
+      file. Wouldn't want to bump the ID version unless the code changed, but 
+      not a user facing name. For ID strings, shouldn't bump version, but for 
+      user facing things we need to figure out something thats not confusing.
+    - Mark: Config authors are also users. Currently no mapping from ID strings 
+      to builtin transforms.
+    - Doug: Correct, no direct mapping. Tried to demonstrate that in slides. 
+      Thomas is filtering some of the names. Kept it simpler for presentation, 
+      but agree that builtin transform code should have full transform id string.
+    - Mark: If someone really has to understand history - the way ACES config 
+      code was structured at time. We have generator that sees both worlds. If 
+      you remove half from users, will have no idea.
+    - Doug: That's behind string proposals in slides. But need to decide as 
+      group.
+    - Michael: Could we store that in format metadata? accessible from API?
+    - Doug: Yes, could create description tags in format metadata. More human 
+      readable name and include data from CTL which has a lot of great 
+      information.
+    - Thomas: Being put in description right now.
+    - J: A UI bomb for tools that use it.
+    - Michael: Will it be 1:1 transform -> CTL?
+    - Mark: Hard to keep that link because of the view/display split. Breaks 
+      that relationship. Free then to put whatever comment you like.
+    - Doug: For input and color space conversion side, more 1:1. For output 
+      transform would need table.
+
+* ACES transform spreadsheet:
+    - Another item we previously discussed was creating a spreadsheet with all 
+      ACES transforms, where we could discuss what should be included in the 
+      reference config.
+    - Mark: Can take names from Doug's slides as well?
+    - Kevin: For lib itself, would these transforms introduce new ops? Or black 
+      boxes?
+    - Mark: Black boxes, implemented however we like. Either existing ops or on 
+      the fly 1D or 3D LUT.
+    - Doug: No 3D LUTs in builtin transforms. Goal is to move beyond 3D LUT 
+      limitations. Big limitation in current config. Have ops now (fixed 
+      function, etc.) added for this purpose, which is faithful to CTL itself.
+    - Kevin: Tradeoff between the black box and being able to understand that 
+      it is doing what the CTL is doing.
+    - Doug: Will be very clear, mapping from ops to the CTL. That will be in 
+      the PR, and I can show corresponding YAML to help. Should show this 
+      comparison in meeting at some point.
+    - Mark: Already quite a few implemented in OCIO source, under builtin 
+      transform folder.
+    - Kevin: It's a bit opaque.
+    - Mark: Its a black box by design, not having to think about how to add all 
+      the pieces to get an ACES config. Opting to have the pre-made collection 
+      of transforms.
+    - Doug: convenience for config authors. If someone looks at the internals, 
+      could manually put all the pieces in the config yourself to be more 
+      transparent. Could have a builtin transform and more exposed version 
+      which lists individual ops. Would be long and verbose, but clearer for 
+      those who want to understand each step.
+    - For next week let's get a spreadsheet populated so we can discuss config 
+      contents.
+    - Mark: Can we link empty sapreadsheet in notes?
+    - **Spreadsheet for next discussion**: https://docs.google.com/spreadsheets/d/1SXPt-USy3HlV2G2qAvh9zit6ZCINDOlfKT07yXJdWLg/edit?usp=sharing
--- a/Show More
+++ b/Show More