Dear all,
I have finally had a chance to read the lively discussion of this topic.
I vote in favor of Jonathan's modified proposal, but with
consideration given to the following:
1) The revisions proposed today by Jonathan in response to Steve
Hankin's concerns should be included.
2) Correct the inadvertently repeated phrase "in one in one".
3) Producing a netCDF file that includes a proposed change may not be
entirely trivial, and I fear it might hold up the process. Whose
responsibility will it be to do this? Some ideas might be proposed by
individuals who have never actually written any code that makes calls to
the netCDF library. I therefore suggest that the moderator could make
the summary (3 weeks after proposal, or 2 weeks after no contributions)
*before* requiring a netCDF file. [Certainly this should be allowed if
no support has been received or if little interest has been expressed in
a proposal.] I therefore recommend the following wording:
"After four weeks from the proposal, or two weeks of no contributions,
whichever is longer, the moderator attempts to move toward a decision on
the proposal by summarising the outcome. 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 summarized. If at this point a test netCDF
file does not yet exist, it must be created (unless the summary suggests
the proposal should be rejected). Once this has been done and after two
weeks of no contributions to the discussion, a decision is reached in
one of the following ways:"
4) I'm not sure why there is a desire to include the clause "although
some may be guided by the expertise of others." I would drop it. I
would guess that in nearly all decisions the committee members will
weigh both the technical arguments made and the regard they have for the
individual making the argument in deciding whether to support a
proposal. In this sense we all will be guided to some degree by the
expertise of others. Perhaps the entire sentence could be eliminated
(i.e., drop "All members must vote, although some may be guided by the
expertise of others.").
5) Perhaps we should also include a mechanism whereby a provisional
change could be withdrawn even if it were not technically flawed. It is
possible that upon further reflection or in working with the new CF
specification, the testers might realize that there is a much better way
of doing it. Wouldn't it be better to replace the provisional change
with the superior one? I suggest the following wording:
"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 objections or problems may be
identified that could lead the standards committee to decide by
unanimous opinion to revoke the provisional change."
6) Do we have any guarantees that those expected to test proposed
changes using the CF checker and libcf will have the resources (i.e.,
time) to do this in a reasonable time frame?
Hope some of this is useful in finalizing the proposed rules.
Thanks for all the work,
Karl
Jonathan Gregory wrote:
> Dear all
>
> Here's a new version of the proposed rules incorporating the results of the
> discussion in recent days. Are there any further comments? Unless they say
> otherwise, I would assume that Balaji, John Caron, Steve, Russ and Rich will
> be able to agree to this version. Tom Gross and Karl have not voted yet.
>
> Best wishes
>
> Jonathan
>
>
> 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.
>
> 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 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.
>
> 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.
>
> 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, if any, since several may have been discussed. A
> test netCDF file must exist for this version of the proposal at the time the
> moderator makes the summary. After a further two weeks of no contributions,
> the discussion is concluded in one 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 committe vote in favour of
> it. The moderator will call for votes. All members must vote, although some
> may be guided by the expertise of others.
>
> 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.
>
> 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.
> 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.
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Thu Jul 05 2007 - 13:26:16 BST
