Dear CF community member,
Thank you for taking the time to consider making a contribution to the cf-conventions. The netCDF Climate and Forecasting conventions are a product by and for a broad community and your contribution is the key to their usefulness.
This set of guidelines provides a brief overview of the practices and procedures that should be used in fixing, updating, or adding to the conventions. It builds on the rules for CF Convention changes.
As a prerequisite to this guide, please review the community's code of conduct. The CF community takes great pride in respectful and collegial discourse. Any disrespectful or otherwise derogatory communication will not be tolerated.
These contribution guidelines are designed to make it easy to contribute to the CF Conventions and are tailored to the platform where they are hosted, GitHub. They are intended to support your work and not to constrict you; if at any time you find them difficult to follow, ask for help. Your contribution is valuable and the community will be happy to give a hand.
- A given proposal should be discussed as one issue. It shouldn't fork or be superseded by another one, unless that reflects what has happened to the proposal. This is so it is easy to trace the discussion that led to a given agreed proposal.
- A proposal should convey the reasoning and effect on all relevant sections of the specification. An overview of all actual changes and the impact the changes have on the specification should be clear. Depending on the length and nature of the proposal, this may require different approaches as described below.
- In general, issues should be used for discussion of proposed changes and pull requests should be used for review of agreed upon changes. In other words, if the content or concept of what is being proposed needs to be vetted by the community it should be vetted in an issue. If the proposal is non-controversial (such as a typo correction) or has been agreed to in concept in an issue, then detailed review of the text may take place in a pull request. Practically all changes should be documented and discussed in an issue fixed in a related pull request.
- Use labels on issues and pull requests. Currently this is achieved by using an appropriate issue template when creating a new issue.
- Comments in pull requests. These should be avoided, unless discussing changes to the wording of a proposal that do not impact on the agreed meaning. This is so that the scientific development of the proposal is easily found in one place, i.e. the GitHub issue.
Note that it takes a minimum of three weeks for a change to the content of the CF Conventions to be merged into the Convention's next version. As the Conventions are published once a year, this means that the de facto "feature freeze" for a given version of the CF Conventions is three weeks before that year's annual meeting.
Issues should attempt to follow the guidelines in the issue template as much as possible. All new pull requests should be submitted to the master branch of this repository. It is recommended that pull requests are created on a branch of a personal fork of this repository. Use of other branches is at the discretion of the repository administrators.
When an issue and accompanying pull request concludes with an agreed change to the conventions, the pull request is merged into the master branch according to the Rules for CF Convention Changes.
The pull request is merged by a member of the Governance Panel or the CF Conventions and Standard Names Committee. The person who merges the pull request also closes the issue.
If subsequent discussion is required after the pull request has been merged then a new issue should be raised, rather than reopening the closed issue. An issue may be closed without the merging of a pull request if the change was not accepted by the community. In this case the issue may be reopened for further discussion at a later date.