diff --git a/tsc/meetings/2026/2026-07-30.md b/tsc/meetings/2026/2026-07-30.md
new file mode 100644
index 0000000..2e004f8
--- /dev/null
+++ b/tsc/meetings/2026/2026-07-30.md
@@ -0,0 +1,66 @@
+# MoonRay TSC Meeting - July 30, 2026
+
+## Quick Recap
+The meeting focused on updates and discussions around MoonRay and hdMoonRay development, including recent release issues, CI image improvements, and integration challenges
+with USD and MaterialX. Jon, Jean-Francois, Rob, and others discussed the process for identifying good first issues, CI image updates, and the best USD version to target
+for builds. Rob announced a significant upcoming update to hdMoonRay, detailing internal changes and new features, and the group discussed the best platforms for community
+discussions and collaboration, weighing the pros and cons of Slack, GitHub Discussions, and Confluence. The conversation also covered versioning schemes, the impact of
+divergent git histories, and the need for better documentation around submodules. Additionally, the team discussed executable naming conventions for Snap packages and the
+challenges of maintaining consistency across different build systems. Updates from SIGGRAPH included demos of MoonRay running in Katana and Nuke, a new Gaffer plugin, and
+the first drop of MaterialX support. The conversation ended with a brief overview of Birds of the Feather presentations and recent project highlights.
+
+## Next Steps
+Jon: Review Jean-Francois's aswf-docker PR for CI images and provide feedback by mid next week.
+Jean-Francois: Update the CI images to include fixes for OpenUSD build issues related to MaterialX and OSL integration.
+Jean-Francois: Target USD version 26.08 for the next set of CI images.
+Rob: Post an update on GitHub about the upcoming large hdMoonRay update, describing the changes and new features.
+Rob: Push the work-in-progress hdMoonRay branch to the fork for visibility and potential collaboration.
+Rob: Start a discussion (either on GitHub or Slack) for hdMoonRay design decisions and compatibility, including sub-topics like RAMP attribute support.
+Jon: Run the idea of using symlinks or wrapper scripts for Snap executable names by SnapCrafters to address the underscore issue.
+Randy: Write up a summary of the Birds of the Feather session and post it to the Slack channel.
+Jon: Create a tag for the current OpenMoonRay codebase to mark the cutoff point before the hdMoonRay changes (possibly as "hydra-1").
+Jon: Discuss and decide on a versioning scheme for tagging the individual LEAF repositories in a future TSC meeting.
+
+## Summary
+### MaterialX Submodule Build Issues:
+The team discussed an internal release that had some issues, with Paul explaining they recently added a new MaterialX submodule to OpenMoonRay and encountered build problems.
+
+### MoonRay CI Image Updates:
+Jean-Francois discussed updating the PR with changes and addressed blockers in the current CI MoonRay image. Jon explained he was building a list of issues but had
+misunderstood Jean-Francoi's message about recent updates to the MoonRay CI images. Jean-Francois mentioned that someone was working on fixing issues with OpenUSD build
+integration, particularly with MaterialX and OSL, and planned to include these fixes in the next set of images. The group discussed which USD version to target, with Matthew
+and Duncan providing insights that no DCC has yet adopted USD 26.08, but they expect adoption soon. Jon also noted he would provide JF with an update on CI, mentioning he was
+reviewing JF's PR and would provide feedback by mid-next week.
+
+### USD Version Compatibility Discussion:
+The team discussed USD version compatibility and flexibility across different tools like Katana, Nuke, Maya, and Houdini. Duncan explained that both Katana and Nuke have shims
+allowing for USD version swapping, though recent Nuke updates with Gaussian Splat augmentations have limited this flexibility. Matthew noted that vendor support and
+cross-compiling capabilities vary significantly between tools, with Houdini being very strict while Maya offers more flexibility. Duncan mentioned a specific IP issue with
+the Storm patch for Hydro rendering that requires permission from Steve Shapiro for external use.
+
+### HD MoonRay Update Release Planning:
+Rob discussed a significant update to HD MoonRay sitting on a local branch that needs to be released, containing internal changes and new features while maintaining source-level
+compatibility. The team agreed to create a discussion thread in either Slack or GitHub to facilitate collaboration and feedback from the community, particularly regarding
+Houdini RAMP attributes and color management support. Rob indicated the release would happen within one to two weeks after a successful internal release, with plans to merge it
+into the internal integration branch before making it available to the open source community.
+
+### OpenMoonRay Versioning Strategy Discussion:
+The team discussed versioning strategies for OpenMoonRay, particularly regarding the transition from hdMoonray version 7 to version 10. They agreed that while internal and
+external versioning schemes may diverge due to logistics, they should establish a tagging system to clearly mark major version cutoffs. The group decided to create a markdown
+file linking internal and external versioning schemes, and considered implementing semantic versioning at a level larger than individual repositories but smaller than the entire
+project.
+
+### SNAP Executable Naming Discussion:
+The team discussed concerns about executable naming in SNAP, with Randy opposing Ken's approach of modifying executable names for MoonRay output formats, preferring instead to
+use Snapcraft aliases or symlinks. Jon and others agreed that creating symlinks pointing to the original executable names would be a better solution than renaming the executables.
+The discussion then shifted to Ken's experience forking the MoonRay super project, where he encountered challenges with relative URLs in the git modules file and suggested moving to
+absolute paths by default.  Jon felt that the relative path scheme was more in-line with typical developer workflows where each LEAF repository is forked and cloned separately, while Ken argued that absolute paths would be more robust for developers who
+fork the super project.  The team agreed to continue using relative paths for now, but to document the workflow better for developers who only fork the super project.
+
+### Repository Submodule Path Issues:
+The team discussed issues with relative paths in repository submodules, particularly when introducing new repositories like MaterialX shaders. Matthew explained that developers
+using old URLs from DreamWorks Animation would encounter problems when pulling updates due to the relative URL. The group decided to maintain their current relative path
+approach for submodules while improving documentation around submodule workflows.
+
+### Good First Issues and Community Engagement:
+Jon mentioned plans to review good first issues from the JIRA list for MoonRay repositories, but decided to postpone this discussion after further filtering is done.