Version 2 (modified by markh, 8 years ago) (diff)


Managing Trac Tickets

The CF Metadata Trac website used for making specific proposals to amend or correct the CF Conventions.

Rules for CF Conventions Changes

  • New proposals are to be made on trac using the template, including verbatim changes proposed to the text of standard document and the conformance document.
  • A member of the conventions committee, or another suitably qualified person, volunteers to moderate the discussion. If no-one volunteers, the chairman of the committee will ask someone to do it:
    • It is the responsibility of the moderator to update the ticket description;
    • In particular the Technical Proposal and Requirement sections should reflect the latest state of discussion on the ticket.
  • The discussion takes place on trac and all may participate.
  • The moderator periodically summarises discussion on trac, updating the ticket description, keeps it moving forward and tries to achieve a consensus.
    • It is expected that everyone with an interest will contribute to the discussion and to achieving a consensus during this stage.
    • During the discussion, if an objection is raised, answered and not reasserted, the moderator will assume the objection has been dropped.
    • However, since consensus is the best outcome, it will be helpful if anyone who expresses an objection explicitly withdraws it on changing their mind or deciding to accept the majority view.
  • The moderator is encouraged to organize conference calls and/or webex-type interactions if this might help resolve a Trac item more quickly.
  • It will be helpful if a test netCDF file is provided as early as possible during the discussion. However, several variants of the proposal may be discussed, and the proposer may not be able to provide test netCDF files for all of them.
  • When three weeks have passed with no contributions being made, the moderator should attempt to move toward a decision on the proposal by summarising the discussion and indicating the outcome as consensus, near consensus, or not near consensus (see below) on making the proposed change. Since several versions of the proposal might have been discussed, the summary should make clear which one, if any, would be adopted. The moderator will then invite further comment on the proposal, as summarised. If futher comments are made i.e. the discussion restarts, this step is repeated.
  • Once the summary has been made, if the test netCDF file does not yet exist, it must be created (unless the summary suggests the proposal should be rejected). When three weeks have passed with no contributions following a summary, and providing a test file exists (if appropriate), a decision is reached in one of the following ways:
    • Consensus: Accept the proposal if there is no outstanding objection, and at least three contributors have expressed support for it, including at least two members of the conventions committee. If the moderator personally expresses support, he or she can be counted among the supporters.
    • Near consensus: If the conditions for consensus are not met but the moderator's summary is that consensus has nearly been achieved, accept the proposal if all, or all but one, of the conventions committee vote in favour of it. The moderator will call for votes and all members should vote.
    • Not near consensus: No change to standard.
  • The trac ticket is then closed by the moderator stating the outcome.
  • If the change is accepted, the standard document should be updated, the CF convention version number incremented, and the conformance document updated.
  • If the change is accepted, the standards document and conformance document need to be updated and the changes staged for the next release of the conventions
    • The author of the proposal should be added to the list of contributing authors of the CF convention.
  • At this point, the change is shown in the CF documents as provisional, but it will not be revoked unless subsequent testing shows it to be flawed. In rare circumstances, unforeseen issues may arise during testing that could lead the standards committee to decide by unanimous opinion to revoke the provisional change.
  • Provisional status lasts until at least two applications have successfully interpreted the data in the test or some other netCDF file following the new convention. The Unidata libcf and the NCAS CF checker would be sufficient to meet this requirement. If other applications are to be used, the conventions committee must be satisfied that they are suitable.
  • Once the testing is successful, the CF documents should again be updated to remove the provisional status, and the version number incremented again. If the testing is not successful, the change is revoked.
  • All versions of the standard and conformance document should be kept available online, with their trac tickets and a history of changes.

Rules for Correcting Errors in CF Documents

  • These rules apply to the CF conventions document, the conformance document, the standard name table and its guidelines.
  • Errors in these documents can be corrected under these rules if it is clear that the text as it stands isn't what was agreed, because of a typographical or some other error. These rules can't be followed for making substantive changes. Errors in the standard names can alternatively be pointed out on the CF email list, and implemented by the manager of CF standard names (Alison) as part of a regular update.
  • If someone thinks there is an error in a document, they should open a Trac ticket of type "defect" to point it out and to state what should be done to the text in order to correct the error.
  • The correction is held to have been agreed if three weeks pass without anyone disagreeing with it. After that period, the ticket should be closed by the manager of the CF conventions or the manager of CF standard names, who will make the change. No moderator is needed because there cannot be any substantive discussion under these rules.
  • If anyone disagrees that the correction should be made, because they think the document does have the intended meaning, then a correction cannot be made by these rules, the ticket should be closed, and the change should be proposed as an enhancement instead, following the rules for making changes to the CF standard, if the proposer wants to pursue the issue.