Hi Steve
> Bryan, you mentioned that you have some optimism that you can find support
> for 1/2 FTE.
Regrettably, possibly unlike NOAA, it'll probably have to be money spent here
at the BADC. I think what this means is that any solution for CF may consist
of (hopefully significant) parts of a number of folk in different
institutions. While piecemeal approaches like this can have problems
(especially when the pieces are too small, and/or the responsibilities not
clearly delineated), it does have the advantage of having the folk embedded
in differing communities which can only be to our advantage for something
that needs to be a community activity. (I hasten to add that this activity at
the BADC, if funded, would be half that person's job description and so it
wouldn't get squeezed out).
> * The new FTE position would support the "document editor".
If we can't get 1 FTE in one place, then we can at least have a few people who
fill this (and more) functionality.
Rich has suggested sub-committees, and sub-components, and I like that idea. I
think we do need to identify compartments of the existing standard. However,
there is a place for someone to bring it all together, and that'll be vital.
> The
> person's responsibility is to write the text that will actually appear in
> the final document and to moderate discussions. Like any editor there is a
> lot of real authority in this and it needs to be a knowledgeable,
> interested person.
Yep.
> * We are working to make some NOAA funding available
> (can be spent outside of NOAA of course) to develop the software for a web
> site to support CF standards development. I propose the name "Standards
> Forge" for this software. Functionally it would borrow a lot from Bugzilla
> -- able to open issues, indicate severities of issues, track discussions,
> indicate linkages between issues, resolve (close) issues, moderate
> membership in discussions. The user interface could look completely
> different from Bugzilla. Versioning issues need to be addressed, too
> (borrowing from CVS?). The construction of this software could be
> "contracted out". (I can think of a few groups/individuals that could do
> it well just off the top of my head.)
I too have been thinking down these lines. I think it's crucial.
> * Some organization would need to host the Standards Forge site. I'd
> like to lobby Unidata to take on this role -- as CF is a spin-off of
> netCDF. (Of course other institutions could install Standards Forge for
> their own purposes, too.) Hosting the site does not necessarily imply
> leadership in the technical discussions.
Indeed someone needs to host it, and it is important that whoever hosts it
doesn't capture the technical arguments.
> * Rich's ideas about "subcommittees" would be in this. The
> (distributed) participants in the discussions could be grouped by large
> themes -- e.g. curvilinear model grids, unstructured model grids, GIS
> compatibility, standard name dictionary. The Standards Forge concept would
> support a hierarchy of topics/subtopics/issues (in Bugzilla there is a
> similar hierarchy of Products/Components/Bugs). The membership of the
> subcommittees would be published on the site. Membership needs to be
> "open", but with some thought given to rules for participation. The
> subcommittees would have the authority to resolve technical issues by
> consensus. The document editor would be a member of every subcommittee --
> a start towards ensuring harmonization between subcommittees.
Or, there is a document editor assigned to each committee, and an overall
"bringer-together".
> * Versioning considerations need to include guidelines to ensure that
> all aspects of the standard(s) are tested in real-world code
> implementations before they become final. CF releases might remain
> "provisional" for a significant time while this occurred. They would
> nonetheless be available for use. (I'd argue that the current CF 1.0
> should be regarded as "provisional" in this sense. Much of it has never
> been tested in applications that read the data.)
Totally agree. We should also come up with some sort of guidelines on what
constitutes a minor and major version. Software vendors have this problem all
the time. We should also *resist strongly* the urge to pop out new versions
every five minutes (or so it seems sometimes with some software). If we
expect real people to build real code, and/or construct real metadata, then
these are timeconsuming activities. Moving sands underneath such activities
is difficult.
>
> - steve
>
> ==============================
>
> Rich Signell wrote:
> > Brian Eaton wrote:
> > > As any
> > > benevolent dictator in my shoes would do, I will step aside as the lead
> > > author as soon as someone else is ready to assume that role. Until
> > > that time I will continue to maintain the CF home page, making sure the
> > > links all work and so on.
> >
> > I think part of the "problem" is that CF has become much more popular,
> > and much more important in the atmospheric and oceanic communities! So
> > there are more people clamoring to include increasingly complex
> > functionality to the standard. Having a single person trying to sort
> > through all the suggestions and responses and author new revisions is a
> > daunting task, especially for a volunteer, as Brian said.
> >
> > What would the CF gang think about moving to a sort of "subcommittee"
> > approach, where different small groups could be responsible for producing
> > draft documents that address the areas that have had a lot of recent
> > discussion, for example: GIS interfacing, handling of unstructured grids,
> > handling of staggered grids. I think this could be done in the same
> > informal way that CF has used in the past, but these sub-groups might
> > result in more rapid progress, since the members would likely have a
> > special interest in seeing these proposals become reality.
> >
> > One might imagine that these different areas might be useful to identify
> > within the CF convention itself, as "modules". Thus a client that worked
> > with CF2.0 might say it supports the "core" module, but not the "gis"
> > module or the "unstructured grid" module. This would help alleviate the
> > concern that we don't want to make being "CF compliant" too complex.
> >
> > I think also that the discussion is complex enough that we could really
> > use a discussion board that has different topics identified, is
> > searchable, allows code revisioning, attachments, etc, but without too
> > much overhead. Tom Gross has suggested Sourceforge, Steve Hankin
> > Bugzilla - are their other candidates?
> >
> > -Rich
> >
> > --
> > Richard P. Signell rsignell at usgs.gov
> > U.S. Geological Survey Phone: (508) 457-2229
> > 384 Woods Hole Road Fax: (508) 457-2310
> > Woods Hole, MA 02543-1598
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
>
> Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
> 7600 Sand Point Way NE, Seattle, WA 98115-0070
> ph. (206) 526-6080, FAX (206) 526-6744
--
Bryan Lawrence, Head NCAS/British Atmospheric Data Centre
Web: badc.nerc.ac.uk Phone: +44 1235 445012
CCLRC: Rutherford Appleton Laboratory, Chilton, Didcot, OX11 0QX
Received on Fri Feb 25 2005 - 05:54:41 GMT
