GSI Code Management Policy

NOAA-EMC/GSI supports current and planned operational NWS realizations of the GSI. Changes to NOAA-EMC/GSI must have a clear path to implementation with agreement from operational GSI application leads. This page documents the standards and procedures for managing operational changes to the authoritative NOAA-EMC/GSI repository.

The basic steps to contribute the code

1. Create a GitHub issue associated with the development. Document development in the github issue (see 3i below). Basic information about forking and cloning is available via the NOAA-EMC/GSI github wiki. An issue is considered inactive if it has not been updated within the past six months. Inactive issues will be closed by the Handling Review Team.
2. Create and prepare a Pull Request (PR) for the proposed changes.
3. Every PR request will need to be assigned & managed by a “Handling Reviewer” from a designated pool of authoritative reviewers. The actual reviews will be performed by two peers. Reviews by members of the Handling Review team do not count as peer reviews.
   1. All PRs need complete documentation in GitHub Issues.
   2. All PRs need regression tests run and documented.
   3. New capabilities should come with updates to existing regression tests or new regression tests as part of the PR. Absent this developers run the risk of having new capabilities broken in future PRs.
   4. Code updates need to follow established coding standards – this includes GSI coding standards as well as those for transition to operations (see GSI Code Standards).
   5. Once two peer reviewers approve the PR, the automated GCC/Intel build checks pass successfully on GitHub Actions, ctest results are documented, and the Handling Reviewer agrees, the PR will scheduled for merger into develop. Notification will be sent out via updates to the PR.

Developers are encouraged to submit smaller PRs. This facilitates easier reviews and allows for more agile development. A PR is considered inactive if it has not been updated within the past six weeks. Inactive PRs will be closed by the Handling Review Team.

Generally speaking, PRs will be handled in the order they are received. Prioritization may be necessary to facilitate required changes for operational implementations. Decisions on priorities and other disputes will be handled by the group of Handling Reviewers. PRs may be rejected at the discretion of the Handling Reviewer for reasons including but not limited to

• size/scope being too large
• changes not adhering to coding standards
• changes not required by current or planned operational impelemtations.

See GSI how to make changes for additional information.

The handling team responsibilities

Once the two peer reviewers approve a PR, the handling team member assigned to the PR will do the following:

1. ensure all PR steps have been followed
2. perform a quick review of the changes
3. approve the PR once satisfied with the changes
4. inform the rest of the handling review team that the PR is ready to merge & invite feedback
5. assuming no objections from the team, the handling reviewer merges the PR into develop
6. ensure all associated issues are closed