Suggested changes are inline
>
> New proposals to be made on trac using the template, including verbatim changes
> proposed to the text of standard document and the conformance document
, and a test netcdf file that implements the suggested change.
>
> 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.
>
> The discussion takes place on trac.
>
> The moderator periodically summarises discussion on trac, keeps it moving
> forward and tries to achieve a consensus. It is expected that everyone with an
> interest will contribute to the discussion and consensus during this stage.
>
> After four weeks from the proposal, or two weeks of no contributions,
> whichever is longer, the moderator attempts to wind up the discussion by
> summarising the outcome. The summary should make clear which version of the
> proposal would be adopted, since several may have been discussed. After a
> further two weeks of no contributions, the discussion is concluded and the
> trac ticket closed by the moderator stating the outcome, which should follow
> these rules:
>
> No outstanding objection Accept proposal
> Near consensus Accept proposal if all, or all but one, of the
> conventions committe vote in favour of it.
> Not near consensus No change to standard
>
> (NB These rules are different from the ToRs in the white paper, which allowed
> a simple majority to decide. The discussion in Paris indicated that all
> members should vote, but should be guided by other members where they don't
> consider themselves to have the right expertise.)
>
> If a change is accepted, the standard document should be updated, the CF
> convention version number incremented, and the conformance document updated.
and a test netcdf file added that implements the final version, suitable for testing.
>
> 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 document as provisional, but it will
> not be revoked unless subsequent testing shows it to be flawed.
At least two independent software implementations that test the new feature must be performed, with positive results. In addition, it must be shown to not interfere with the current version of Unidata libcf and the NCAS CF checker. If possible, the Unidata libcf and the NCAS CF checker should be among the software implementations that actually test the new feature.
If problems are reported, the conventions committee must decide whether to proceed or revise the proposal.
>
> Once this has been done, the document should again be updated to remove the
> provisional status, and the version number incremented again.
>
> All versions of the standard and conformance document should be kept available
> online, with their trac tickets and a history of changes.
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Jun 27 2007 - 16:03:48 BST
