RDASApp code management policy

Developers are expected to make a personal fork, make changes on the fork, and create PRs to the authoritative repo.
DO NOT push personal branches to the authoritative repo.
To discuss any RDASApp problems/issues, developers should first make sure they can repeat the problem by starting with a fresh clone. This is because RDASApp uses lots of submodules, it is very easy for those submodules to get unsynced and inconsistent in the working copy, and then people actually discuss different things. A simple sanity check by making a fresh clone may quickly bring different parties on the same page.
(If you would like to get help syncing submodules on your local working copy, Guoqing.Ge@noaa.gov can help)
Each PR will require at least one approval before a merge. It is preferred that GSL developers' PRs get at least one approval from EMC and EMC developers' PRs get at least one approval from GSL.
Each PR involving build/code/script changes will need to pass CI tests on Hera/Jet/Hercules.
Code managers can trigger CI rrfs-tests on Hera/Jet/Hercules by adding test_hera, test_jet, and test_hercules labels to a given PR.
Developers are responsible for checking the results if CI tests fail.
Developers are encouraged to run rrfs-tests from a fresh clone using the rdas_build_test tool:
git clone https://github.com/rrfsx/rdas_build_test.git
You only need to clone rdas_build_test once. Instructions can be found here.

Provide feedback