⇐ ⇒

[CF-metadata] Editing/publishing workflow (Jonathan Gregory)

From: Chris Barker <chris.barker>
Date: Fri, 14 Mar 2014 09:15:29 -0700

On Fri, Mar 14, 2014 at 1:08 AM, Schultz, Martin <m.schultz at fz-juelich.de>wrote:

> In practice I would expect few occasions where issues are
> actually re-discussed, but of course this can happen.
>

Anyone have an idea from the history of CF how often a provisional feature
has actually been removed or changed significantly?

Interesting -- this seems to map well with library software "deprecation"
policies -- often it is decided that a feature of an API should be
depreciated, but no one wants to break compatibility so those features can
linger on forever, both with or without an official deprecation warning, if
there is no clear polcity for when such features will be removed. This is
kind of the opposite -- adding, rather than removing a feature, but the
same issue hold true.

I would sugest that provisional features be mapped to a release schedule:

A new feature is provisional for either one or two releases (to be
decided), and will become "permanent" or "official", or
whatever, after that, if there have been no issues raised. I don't think
that we need to have a clear definition of "issues raised" -- the
policy/procedure for deciding that would simply be the same one as used to
add a feature in the first place.

As to the release schedule, I think an Ubuntu-style regular-in-time release
schedule would be appropriate, but that doesn't really effect the above.

-Chris



















> Best regards,
>
> Martin
>
>
>
> > Message: 3
> > Date: Thu, 13 Mar 2014 17:23:31 +0000
> > From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> > To: cf-metadata at cgd.ucar.edu
> > Subject: Re: [CF-metadata] Editing/publishing workflow
> > Message-ID: <20140313172331.GH32698 at met.reading.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Dear Jeff
> >
> > [...]
> > Yes, this is a issue. As Richard said, it doesn't matter how it is
> marked. The
> > problem is that all changes, however old, are still marked as
> provisional, as
> > you said. This is (a) a bit silly and (b) a nuisance as regards
> legibility
> > of the doc. The aim of provisional status was to allow time for people
> to try
> > out the change, in case a logical flaw was discovered which hadn't been
> fore-
> > seen at the time of the proposal. This was because of the concern that
> many
> > or
> > most proposals concern data which has not yet been written, so the
> > metadata
> > being proposed can't have been thoroughly tested. It was supposed that
> > some
> > tests, using specified software, would be used to demonstrate the new
> > feature
> > was "working", but no-one had time to work out the details for this.
> >
> > I'd like to propose changing the rules. That's something the conventions
> > committee can agree, I believe. I would suggest the simplest
> possibility, if
> > we wish to retain provisional status, is to specify a time. We could say
> that,
> > after one year from acceptance or when the next version of the
> conventions
> > document is published, whichever is later, a change becomes permanent.
> > What
> > do you think?
> >
> > Cheers
> >
> > Jonathan
>
>
>
> ------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
>
> ------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>



-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140314/8a204862/attachment.html>
Received on Fri Mar 14 2014 - 10:15:29 GMT

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

⇐ ⇒