[CF-metadata] proposed rules for changes to CF conventions

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 28 Jun 2007 18:14:45 +0100

Dear John

> Perhaps you can clarify what happens in the following case: 1) Someone expresses a concern. 2) The moderator (or someone else) responds to the concern. 3) The moderator summarizes the outcome after suitable time. (Note that the person expressing the original concern has said nothing further.) 4) No one else contributes.
>
> Is this deemed to be a consensus, or not? My sense is that unless the originator of the concern in step (1) says "I accept your point of view, carry on", the initial concern should be considered an outstanding objection.

Hmmm. I think it will generally work better if the moderator tries to keep out
of it (though I'd find that hard if I were moderator :-). I tend to think that
if A proposes, B objects, C responds to B's objection (in support of A), and
then neither A nor B comment further, the proposal should be accepted. By not
responding, I think B has dropped his objection. If B was interested enough to
comment, I expect he would make time to say just "No, I am still not happy" if
nothing more. If C agrees with B's objection, and A doesn't respond, there is
an outstanding objection and hence not a consensus.

> This question might become clearer if the mechanism and timing of the 'call for a vote' was explicitly described in the procedures -- right now the voting is mentioned only in the summary of closing the track ticket.

I think the vote occurs two weeks after the moderator has summarised the
discussion, if no-one has said anything subsequently. If the summary says
there is nearly a consensus (in the judgement of the moderator), and no-one
has challenged that assessment (by commenting subsequently), the issue is
decided by a vote, and requires near-unanimity for acceptance.

> Real files can be very useful for humans to understand precisely the application and implications of the proposed change.

OK. Since you and John Caron agree, I am outvoted. :-) If the change was to
prohibit something, I suppose the test file would be something that was
deliberately erroneous under the proposed change. That is useful input to
test the CF checker. Do you agree?

> Third option: Require testing before a conclusion is reached. Provisional libcf and CF checkers are presumably within reason.

I think that is the idea. The decision to go from provisional to final depends
on the testing.

> Finally, could you briefly mention (or point to) the rationale for the standard names following a separate process? A quick review of the site didn't uncover this information, thanks.

The white paper might say something. It's basically because (a) there are two
committees representing the different sort of expertise and (b) the nature of
the changes are different. Stdname proposals are typically large collections of
small points to be discussed, conventions often larger conceptual issues. But
there is overlap, as Alison pointed out in Paris, and some issues might cover
both areas or pass from one to the other.

Best wishes

Jonathan
Received on Thu Jun 28 2007 - 11:14:45 BST