OpenMoonRay · jlanz · May 22, 2026 · May 20, 2026 · May 20, 2026 · May 20, 2026
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -1 +1,3 @@
-All participants agree to abide by LF Projects Code of Conduct (as defined in the [charter](tsc/charter.md)) available at https://lfprojects.org/policies/code-of-conduct/
+# Code of Conduct
+
+The Code of Conduct of this repository if managed by the Code of Conduct of the overarching MoonRay project, defined in the [`OpenMoonRay/openmoonray` GitHub repository superproject](https://github.com/OpenMoonRay/openmoonray/blob/main/CODE_OF_CONDUCT.md).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,108 +1,3 @@
-# Overview
+# Contribution Policy
 
-This project aims to be governed in a transparent, accessible way for the benefit of the community. All participation in this project is open and not bound to corporate affiliation. Participants are all bound to the [Code of Conduct](CODE_OF_CONDUCT.md).
-
-# Project roles
-
-## Contributor
-
-The contributor role is the starting role for anyone participating in the project and wishing to contribute code.
-
-### Process for becoming a contributor
-
-* Review the [coding standards](https://docs.openmoonray.org/developer-reference/coding-standards/) to ensure your contribution is in line with the project's coding and styling guidelines.
-* Have a signed CLA on file ( see [below](#contributor-license-agreements) )
-* Have your submission approved by the [committer(s)](#committer) and merged into the codebase.
-
-#### License
-
-MoonRay is licensed under the [Apache, version 2.0](LICENSE.md)
-license. Contributions to MoonRay should abide by that standard
-license.
-
-#### Contributor License Agreements
-
-Developers who wish to contribute code to be considered for inclusion in MoonRay must first complete
-a **Contributor License Agreement**, and email it to MoonRay@dreamworks.com and be sure to include
-your GitHub username(s).
-
-* If you are an individual writing the code on your own time and
-  you're SURE you are the sole owner of any intellectual property you
-  contribute, you can [sign the CLA as an individual contributor](https://github.com/dreamworksanimation/openmoonray/blob/main/tsc/icla.md).
-
-* If you are writing the code as part of your job, or if there is any
-  possibility that your employers might think they own any
-  intellectual property you create, then you should use the [Corporate
-  Contributor Licence
-  Agreement](https://github.com/dreamworksanimation/openmoonray/blob/main/tsc/ccla.md).
-
-The MoonRay CLAs are in the [OpenMoonRay repo](https://github.com/dreamworksanimation/openmoonray/tree/main/tsc).
-
-#### Commit Sign-Off
-
-Every commit must be signed off.  That is, every commit log message
-must include a “`Signed-off-by`” line (generated, for example, with
-“`git commit --signoff`”), indicating that the committer wrote the
-code and has the right to release it under the
-[Apache License, version 2.0](LICENSE)
-license. See [http://developercertificate.org](http://developercertificate.org/) for more information on this requirement.
-
-## Committer
-
-The committer role enables the participant to commit code directly to the repository, but also comes with the obligation to be a responsible leader in the community.
-
-### Process for becoming a committer
-
-* Show your experience with the codebase through contributions and engagement on the community channels.
-* Request to become a committer.
-* Have the majority of committers approve you becoming a committer.
-* Your name and email is added to the [MAINTAINERS](MAINTAINERS.md) file for the project.
-
-### Committer responsibilities
-
-* Monitor email aliases.
-* Monitor Forums (delayed response is perfectly acceptable).
-* Triage GitHub issues and perform pull request reviews for other committers and the community.
-* Make sure that ongoing PRs are moving forward at the right pace or close them.
-* Remain an active contributor to the project in general and the code base in particular.
-
-### When does a committer lose committer status?
-
-If a committer is no longer interested or cannot perform the committer duties listed above, they
-should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of
-the committers per the voting process below.
-
-## Technical Steering Committee (TSC) member
-
-The Technical Steering Committee (TSC) oversees the overall technical direction of MoonRay, as defined in the [charter](charter.md).
-
-TSC voting members consist of committers that have been nominated by the committers, with a supermajority of voting members required to have a committer elected to be a TSC voting member. TSC voting members term and succession is defined in the [charter](charter.md).
-
-All meetings of the TSC are open to participation by any member of the MoonRay community. Meeting times are listed in the [MoonRay technical community calendar](https://calendar.google.com/calendar/embed?src=c_0104aeaceaad2fdc2db4264d1b1211ed56c33cb51086cd5a2a8df324158d21c5%40group.calendar.google.com&ctz=America%2FLos_Angeles).
-
-## Current TSC members
-
-* Jon Lanz, Chair / DreamWorks
-* Toshi Kato / DreamWorks
-* Rob Wilson / DreamWorks
-
-# Release Process
-
-Project releases will occur on a scheduled basis as agreed to by the TSC.
-
-# Conflict resolution and voting
-
-In general, we prefer that technical issues and committer status/TSC membership are amicably worked out
-between the persons involved. If a dispute cannot be decided independently, the TSC can be
-called in to decide an issue. If the TSC themselves cannot decide an issue, the issue will
-be resolved by voting. The voting process is a simple majority in which each TSC receives one vote.
-
-# Communication
-
-This project, just like all of open source, is a global community. In addition to the [Code of Conduct](CODE_OF_CONDUCT.md), this project will:
-
-* Keep all communication on open channels ( mailing list, forums, chat ).
-* Be respectful of time and language differences between community members ( such as scheduling meetings, email/issue responsiveness, etc ).
-* Ensure tools are able to be used by community members regardless of their region.
-
-If you have concerns about communication challenges for this project, please contact the [TSC](mailto:MoonRay_TSC@dreamworks.com).
+The Contribution Policy of this repository if managed by the Contribution Policy of the overarching MoonRay project, defined in the [`OpenMoonRay/openmoonray` GitHub repository superproject](https://github.com/OpenMoonRay/openmoonray/blob/main/CONTRIBUTING.md).
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
diff --git a/README.md b/README.md
@@ -1,4 +1,7 @@
-# RATS CTest suite
+# rats - part of the [MoonRay](https://github.com/OpenMoonRay/openmoonray) project
+Policies concerning [Governance](https://github.com/OpenMoonRay/openmoonray/blob/main/GOVERNANCE.md), [Code of Conduct](https://github.com/OpenMoonRay/openmoonray/blob/main/CODE_OF_CONDUCT.md), and [Contribution](https://github.com/OpenMoonRay/openmoonray/blob/main/CONTRIBUTING.md) are available in the overarching MoonRay project, defined in the [`OpenMoonRay/openmoonray` GitHub repository superproject](https://github.com/OpenMoonRay/openmoonray).
+
+## RATS CTest suite
 The purpose of the Render Acceptance Test Suite (RATS) is to catch visual regressions caused by changes to the codebase that may be intentional or unintentional
 before those changes are deployed into a production environment. It works by comparing canonical images rendered with a previously sanctioned version of the renderer
 to images rendered with a developmental version (i.e. built from your bug/feature branch).  RATS is built on the [CTest](https://cmake.org/cmake/help/book/mastering-cmake/chapter/Testing%20With%20CMake%20and%20CTest.html) framework.
@@ -23,7 +26,7 @@ ctest -L 'render|diff' -j $(nproc)
 
 The examples above are not complete. See the "RATS runtime environment" section below for more information on running the tests.
 
-## RATS runtime environment
+### RATS runtime environment
 You must run the RATS tests from the build directory, after sourcing the moonray runtime environment script (`setup.sh`).
 You must also specify the location of the canonical images via the RATS_CANONICAL_DIR environment variable.
 
@@ -35,7 +38,7 @@ export RATS_CANONICAL_DIR=/path/to/my/rats_canonicals
 ctest -L 'render|diff'
 ```
 
-## Test labels
+### Test labels
 To facilitate running the tests in subsets we leverage the [LABELS](https://cmake.org/cmake/help/latest/prop_test/LABELS.html) property of CTest tests as well as a naming convention (see below).  
 The `-L` and `-LE` `ctest` command-line arguments allow for selecting which tests are included or excluded by performing regular expression matching against each test's _labels_.
 
@@ -47,7 +50,7 @@ The tests in the RATS suite are named and labeled according to their purpose.
 
 The tests with the _render_ and _diff_ labels can be run together, e.g. `ctest -L 'render|diff'`.  An explicit dependency ensures that the _render_ test is executed prior to the associated _diff_ test.
 
-### _update_
+#### _update_
 The tests with the _update_ label perform the following steps:
 - the test scene is rendered 25 times, resulting in 25 sets of candidate images
 - each of these images is compared with the other images via per-pixel absolute difference
@@ -66,33 +69,33 @@ It is likely that each class of machine that is intended to run the RATS suite w
 
 These tests are considered passing if they successfully execute the steps outlined above.
 
-### _render_
+#### _render_
 The tests with the _render_ label perform the following steps:
 - the test scene is rendered once, with the resulting test images written to the build directory for that test.
 
 These tests are considered passing if they successfully render the scene.
 
-### _diff_
+#### _diff_
 The tests with the _diff_ label are meant to be run with or just after the tests with the _render_ label, and perform the following steps:
 - the test images are compared with the associated canonical images using OpenImageIO's [idiff](https://openimageio.readthedocs.io/en/latest/idiff.html) tool with the difference thresholds found in the associated diff.json file.
 
 These tests are considered passing if the differences between the test images and the canonical images are within the thresholds specified in the diff.json file.
 
-### _header_
+#### _header_
 The tests with the _header_ label are meant to be run with or just after the tests with the _render_ label, and perform the following steps:
 - the metadata found in the test image headers is compared with that in the associated canonical image headers.
 
 These tests are considered passing if the metadata is considered the same.
 
 
-## Test names
+### Test names
 The tests are named using a convention of tokens separated by hyphens in the form `<stage>-<execution_mode>-<testname>`.
 - The first token is the RATS test stage and is one of ***update***|***render***|***diff***|***header***.
 - The second token is the MoonRay execution mode, abbreviated to 3 characters and is one of ***sca***|***vec***|***xpu*** for scalar, vector and xpu execution modes.
 - The third token is the name of the test, which by convention matches the relative directory structure of the test within the rats/tests/ directory.
 - For tests belonging to the _diff_ stage a fourth token is appended corresponding to the image filename being compared with its canonical counterpart, eg. ***-scene.exr***.
 
-## Filtering which tests are run by name and label
+### Filtering which tests are run by name and label
 This test naming/labeling convention allows for control over running certain groups of tests using the `-R`, `-E`, `-L` and `-LE` command-line arguments that `ctest` accepts.
 
 The regular expression syntax and overlapping behavior is poorly documented, but luckily ctest's `-N` command-line argument will print a list of the tests that match without actually executing the tests.
@@ -122,19 +125,19 @@ ctest -L 'vector|xpu' -L 'render|diff' -R 'moonray/geometry'
 
 CTest has several other ways to choose which tests are run, such as by individual test numbers or by reading a list of tests from a file.  See the CTest documentation for more info.
 
-## The Contents of the RATS test suite
-### Assets
+### The Contents of the RATS test suite
+#### Assets
 The assets/ directory uses [Git Large File Storage](https://git-lfs.com/) (LFS) and contains some simple assets that are used by the tests.
 * models/   : a few simple models in .usdc format
 * hdri/     : a few simple HDRI images in .exr format
 * textures/ : a few simple textures in .tx format
 
-### Tests
+#### Tests
 The tests are split into two directories based on the executable used to render the images, and contain the scene files and CMakeLists.txt scripts for building the tests.
 * tests/moonray
 * tests/hd_render (currently only contains a single test)
 
-### The CMake scripts for generating the tests
+#### The CMake scripts for generating the tests
 The RATS test suite is implemented on top of CTest and this directory contains the source.
 * cmake/
 

diff --git a/tsc/ccla.md b/tsc/ccla.md