| CARVIEW |
Select Language
HTTP/2 200
date: Tue, 14 Oct 2025 09:20:29 GMT
content-type: text/html; charset=utf-8
vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With,Accept-Encoding, Accept, X-Requested-With
x-robots-tag: none
etag: W/"030911fdf455289b24ed1423f0bd46a5"
cache-control: max-age=0, private, must-revalidate
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com github.com/assets-cdn/worker/ github.com/assets/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com *.rel.tunnels.api.visualstudio.com wss://*.rel.tunnels.api.visualstudio.com github.githubassets.com objects-origin.githubusercontent.com copilot-proxy.githubusercontent.com proxy.individual.githubcopilot.com proxy.business.githubcopilot.com proxy.enterprise.githubcopilot.com *.actions.githubusercontent.com wss://*.actions.githubusercontent.com productionresultssa0.blob.core.windows.net/ productionresultssa1.blob.core.windows.net/ productionresultssa2.blob.core.windows.net/ productionresultssa3.blob.core.windows.net/ productionresultssa4.blob.core.windows.net/ productionresultssa5.blob.core.windows.net/ productionresultssa6.blob.core.windows.net/ productionresultssa7.blob.core.windows.net/ productionresultssa8.blob.core.windows.net/ productionresultssa9.blob.core.windows.net/ productionresultssa10.blob.core.windows.net/ productionresultssa11.blob.core.windows.net/ productionresultssa12.blob.core.windows.net/ productionresultssa13.blob.core.windows.net/ productionresultssa14.blob.core.windows.net/ productionresultssa15.blob.core.windows.net/ productionresultssa16.blob.core.windows.net/ productionresultssa17.blob.core.windows.net/ productionresultssa18.blob.core.windows.net/ productionresultssa19.blob.core.windows.net/ github-production-repository-image-32fea6.s3.amazonaws.com github-production-release-asset-2e65be.s3.amazonaws.com insights.github.com wss://alive.github.com wss://alive-staging.github.com api.githubcopilot.com api.individual.githubcopilot.com api.business.githubcopilot.com api.enterprise.githubcopilot.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com copilot-workspace.githubnext.com objects-origin.githubusercontent.com; frame-ancestors 'none'; frame-src viewscreen.githubusercontent.com notebooks.githubusercontent.com; img-src 'self' data: blob: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com identicons.github.com avatars.githubusercontent.com private-avatars.githubusercontent.com github-cloud.s3.amazonaws.com objects.githubusercontent.com release-assets.githubusercontent.com secured-user-images.githubusercontent.com/ user-images.githubusercontent.com/ private-user-images.githubusercontent.com opengraph.githubassets.com marketplace-screenshots.githubusercontent.com/ copilotprodattachments.blob.core.windows.net/github-production-copilot-attachments/ github-production-user-asset-6210df.s3.amazonaws.com customer-stories-feed.github.com spotlights-feed.github.com objects-origin.githubusercontent.com *.githubusercontent.com; manifest-src 'self'; media-src github.com user-images.githubusercontent.com/ secured-user-images.githubusercontent.com/ private-user-images.githubusercontent.com github-production-user-asset-6210df.s3.amazonaws.com gist.github.com; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; upgrade-insecure-requests; worker-src github.githubassets.com github.com/assets-cdn/worker/ github.com/assets/ gist.github.com/assets-cdn/worker/
server: github.com
content-encoding: gzip
accept-ranges: bytes
set-cookie: _gh_sess=Bxy5GZ58jumG7yfVfl5vOltpHADqwBRmzUme5QX%2F8sV0FgOHKaKEd4j2pzf%2BqLWvhH67ApfO6api34Jh6VrbF6RiW9RCTZ8VmBZBrJLMAWyU0FbVrPsz31ydv9WGnw4YwiM4DX4Iqu1PgZTvXq0xq%2B%2B8l5U6qSG5Hoz6eWBHjkkoDaDqv87wo%2F1RXljuUZnkdwyFNAj7jLVXdCgOKpOL8eSsG%2BP5WVKRVN14rtdZERcvNINcDrOK%2Bt8zTUwCBqtbI%2FjA2cYv8z%2BD1LRK80eM4w%3D%3D--yvf2e%2Ff0W9lGDqto--jhrMTo5ztNqZcBPUQ7MKLA%3D%3D; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: _octo=GH1.1.1761918740.1760433628; Path=/; Domain=github.com; Expires=Wed, 14 Oct 2026 09:20:28 GMT; Secure; SameSite=Lax
set-cookie: logged_in=no; Path=/; Domain=github.com; Expires=Wed, 14 Oct 2026 09:20:28 GMT; HttpOnly; Secure; SameSite=Lax
x-github-request-id: 9438:3AF5F8:79159F:92B5CF:68EE15DC
HAFS Code Repository Governance · hafs-community/HAFS Wiki · GitHub
Skip to content
Navigation Menu
{{ message }}
-
Notifications
You must be signed in to change notification settings - Fork 69
HAFS Code Repository Governance
KathrynNewman edited this page Jan 25, 2023
·
2 revisions
- Developers are strongly encouraged to discuss their plans with the HAFS Developers committee before starting work.
- The group meets on a roughly biweekly basis and includes EMC, DTC, and other community members. They will provide feedback on the proposed development and ensure that it is well coordinated with other efforts.
- Developers should contact Kathryn Newman (knewmanATucarDOTedu) to be added to the agenda for a future meeting.
- Developers are encouraged to perform their work in the HAFS community repositories on GitHub (e.g., https://github.com/hafs-community/HAFS). However, a developer may choose to use personal forks for their development instead.
- Personal forks are appropriate when the development does not involve much collaboration with other HAFS developers and/or when the developer does not have write access to the hafs-community repositories.
- Within the hafs-community/HAFS repository, developers should create a new GitHub issue with a short description of the planned work to make the community aware of it.
- All developers should create a branch at the HAFS application level that begins with “feature/” and ends with a short name that describes the planned work (e.g., feature/hafs_ensda or feature/moving_nest).
- The branch should generally be based on the develop branch, unless there is a good reason to start from a different branch.
- If a developer plans to modify one or more submodules, they should make branches in each submodule repository (within HAFS community) that they plan to modify.
- Use the same branch name as the one used above.
- Branches should generally be based on the support/HAFS branch of each submodule, unless there is a good reason to start from a different branch.
- Push your new branch(es) to the remote repository and begin your development work.
- All development should take place within a branch as discussed above.
- Developers are strongly encouraged to sync with the develop branch (at the application level) and the support/HAFS branches for submodules on a regular basis.
- Developers should commit work to their branch on a regular basis and provide commit messages that accurately reflect the changes made.
- When development is complete and it is time to submit a pull request, developers should ensure their branch is up to date with the latest commits from the develop branch at the application level and from the support/HAFS branches for each submodule.
- After merging in any new commits, developers should retest their code and ensure that it is working as expected.
- Once all testing is complete, developers should submit a pull request on GitHub. Separate pull requests are needed for each submodule that the developer changes, including all nested submodules down to the level of the change.
- The pull request should include a concise message that explains the purpose of the changes. If the developer created an issue to describe their development, the pull request should reference the issue number.
- The HAFS repository code owners will be tagged automatically as reviewers. The developer may also designate additional reviewers for their work.
- The developer should tag BinLiu-NOAA, ZhanZhang-NOAA, KathrynNewman, and panll as the approvers.
- Reviewers are encouraged to either approve or suggest changes to the pull request within five working days when the pull request is next in line for review.
- If changes are requested, developers should either implement them (and retest) or explain why they think the changes are not necessary by engaging in a dialogue with the reviewers in the pull request.
- When, after five days, two or more reviewers have approved the pull request and all reviewer comments have been addressed or resolved, the pull request will be merged by the approver.
- The approver has the discretion to either use a squash merge or a regular merge depending on the nature of the changes.
- After merging, unless further development related to the original work is anticipated, the developer should delete any branches that they created. Unrelated additional development should take place in new branches.
Clone this wiki locally
You can’t perform that action at this time.