Skip to content

Latest commit

 

History

History
116 lines (90 loc) · 5.29 KB

CONTRIBUTING.md

File metadata and controls

116 lines (90 loc) · 5.29 KB
Raw

Contributing To atmos_drivers

Thank you for taking time to contribute.

atmos_drivers should be compiled with the GFDL_atmos_cubed_sphere to create an library for atmosphere dynamics.

Contributions to this project are released to the public under the projects open source license.

What follows is a set of guidelines and how-tos for contributing to atmos_drivers. These are guidelines, not rules. Use your best judgement and feel free to propose changes to this document in a pull request.

Table of Contents

Code of Conduct

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to gfdl.climate.model.info@noaa.gov.

Quick Start Workflow

  1. Create an issue that describes the change, or feature request
  2. Fork the project
  3. Create a feature branch off an up-do-date master branch
  4. Update the tests and code
  5. Push the commits to your fork
  6. Submit a pull request to the master branch

Support

To get support, open a GitHub issue using the support issue template. Please be as descriptive as possible. See the Issues section for more details.

Support for this project is primarily accomplished via this project’s community. Additional support may be offered from related communities (e.g. MOM6 or by members of the GFDL Modeling Systems Group. The members of the Modeling Systems group are the main developers and maintainers of this project. Modeling Systems is a small group, and our ability to offer support is limited. Please be patient when requesting support.

Issues

When contributing to this project, please first open an issue using the template that best matches the change type.

Template Description
Bug Report a bug, or unexpected behavior
Feature Request A requested feature or change to the code
Support Request for support. Please see the Support section.

The issue title should be short and descriptive. The issue description should be clear and concise. Include enough information to help others reproduce the issue, or understand the change requested. Use GitHub flavored markdown to format the message, and include links to references.

Pull Requests

Submit pull requests for bug fixes, improvements, including tests, or alerts to particular problems in the code. We perform merge requests based on an internal GFDL schedule that addresses the needs of the GFDL scientists. This release schedule is better described in the Release Schedule sections. We follow the GitHub fork-pull request workflow workflow, briefly described in the Quick Start Workflow section. When creating the pull request, please select a template that best matches the type of changes.

Please keep the changes in a single pull to be as small as possible to help reviewer(s) quickly evaluate changes. If you do have a large update, try to split the update into small, logical pull requests. If the update includes code refactoring, please submit a pull request that includes just the code refactoring.

Once a pull request is created, a member of the Modeling Systems group will review the changes, and, if necessary, will work with the author of the pull request to modify their code changes. Note that merging pull requests is contingent on several factors, including the ability to support the code changes long-term, portability, and the scope of the impact on the code base. Therefore, Modeling Systems does not guarantee that all pull requests will be accepted, even if the changes pass the initial testing phases, and are otherwise correct.

Tests

Curently, this repository is tested by running a full GFDL climate model regression test. If you want to contribute, please run a regression test of a model that uses this repository.

Code Style

Code updates should follow the coding style for the project, contained in CODE_STYLE.md.

Release Schedule

Releases will be tagged using the format yyyy.rr[.pp], where yyyy is the 4-digit year, rr is the 2-digit release number, and pp is the 2-digit patch number. Preliminary releases mean for testing (i.e., code that is still under development) will be marked yyyy.rr.alpha.pp or yyyy.rr.beta.pp. Alpha tags mark code updates that are intended for developers to include in their baseline regression tests to determine whether the code contains bugs not encountered during baseline testing. Beta tags are intended for a wider audience of developers and end users to ensure that their simulations run as expected and reproduce prior results.