⇐ ⇒

[CF-metadata] Editing/publishing workflow update

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 28 Jan 2015 18:05:10 +0000

Dear John, Seth and all.

----- Forwarded message from John Graybeal <jbgraybeal at mindspring.com> -----

> On Jan 27, 2015, at 08:31, Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote:
> > ...all changes ever since the first version are still shown as provisional because we have no rule for accepting them as permanent
>
> This seems at odds with Seth's observations about when changes appear to go away (with each new release).

I haven't checked what the documents show, but the intention is that all
changes should still be provisional. I think that's Jeff's understanding too.

> I'm pretty sure the intent was also to validate the changes -- i.e., that they were not considered fully approved until they had been around long enough to inspire confidence based on use.

That's right. The rules say that two applications must have demonstrated that
they work. See http://cfconventions.org/rules.html. However we have never
organised this process so it's never happened. I agree that's unsatisfactory.
Although this thread is about document markup, it's a good time to review the
rules in this regard. In fact I think we discussed it before, a few months ago.

During the whole time CF has existed, we have never needed to reverse a change
because it turned out to be erroneous or problematic. I suppose this is because
we are always thorough in agreeing them in the first place. However it is still
sensible to have some provisional period, just in case, and perhaps we can
presume that if there is a problem, someone will raise it, rather than having
to set in place a verification process. I presume we should stick to releases
of the doc. We could update it continually with trac tickets but I think that
would be more difficult for users of the convention to keep track of.

Bearing all that in mind, my initial suggestion would be that a change is
marked as provisional in the version in which it is first made and any
subsequent versions which are released less than a year after the change is
first made. This will mean checking the history to see which provisional
changes become permanent whenever a new version is compiled, and that's a bit
of work. Since it's more than a year since we last had a new version, that
would means all changes that have previously been made would be permanent in
1.7. The only provisional changes would be those newly made in 1.7.

Changing the rules is something that the conventions committee would have to
decide about, but it'd be good if we can agree something on this email list.
What do you think?

Best wishes

Jonathan
Received on Wed Jan 28 2015 - 11:05:10 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒