⇐ ⇒

[CF-metadata] Can we please close ticket 93 and modify the latest CF document accordingly?

From: Nan Galbraith <ngalbraith>
Date: Mon, 30 Sep 2013 14:59:29 -0400

I'd just like to weigh in on the importance of a reviewer, or reviewers,
who will
devote the time to check the whole document for consistency after each
change.
This is a really big problem for a project I'm involved with, where we
rely on
Alfresco and "track changes" in Word.

So, to me, using the right technology is crucial. I admit that I'm not
familiar with
github, but I really hope that it, or whatever system is decided upon,
will provide
a VERY clear record of changes.

I understand the desire to speed up the process, I'm just hoping that it
doesn't
become chaotic.
> The advantage is that the person with responsibility for the whole
> does not have to make all the edits themselves -- yet they can easily
> see and review how the edits look

I'm also concerned that this will make it more difficult, not less, for
"the person
with responsibility for the whole". Making edits can sometimes be a lot
simpler
than understanding what someone else has done.

Cheers - Nan


On 9/30/13 1:18 PM, Hedley, Mark wrote:
> The important factor for me is the work flow and people, not the
> technology. Git and github are a bit nicer to work with than svn, the
> merging is a bit better etc but we can support collaborative editing
> either way around.
>
> I will vote for github as it has a number of useful tools and the work
> flow is a little neater and more transparent but it's not the vital
> factor. We can leave CF-Trac as is and still use either tool option.
>
> What I think is valuable is that a number of people make edits to the
> conventions document and a reviewer casts their eye of each change set
> to ensure coherence and merge this in.
>
> I think there are a number of busy people who could spare a little
> time to write up an approved trac ticket and a number of busy people
> very familiar with the CF Conventions document who could spare a
> little time to review a single merge request based on one ticket and
> merge it or return it for rework.
>
> My observation is that there is not one busy person who can spare
> enough time to do this for all the approved but unfinished trac tickets.
>
> It may be that having one reviewer, responsible for consistency, and
> multiple editors still presents a significant speed up compared to
> now, but I am not completely convinced that one person needs to be
> responsible for the whole document.
>
> *Before we get to far into technology discussions, can we agree that
> in principle that multiple editors with a 'review then merge' process
> is a good idea?
> Or are there reasons why multiple editors and reviewers is not
> preferred, accepting that this puts a large lag time on publishing? *
>
> If we agree this thought process and that we can do something about it
> then I'll engage with whatever technology is put in front of me.
> Github is a slight preference in my mind, but whatever's quickest to
> get up and running has to be a worthwhile candidate.
>
> I assume changes and new accounts to the CF SVN system are managed at
> PCMDI so I don't know how easy it is for someone with administration
> rights to engage with this.
>
> For github we can create a new 'organization' in a few minutes and put
> the conventions source in as a project. I can help with this, but it
> doesn't need me, it's easy to do.
>
> The challenge is agreeing roles and responsibilities, this is an issue
> of people, not of technology, in my mind.
>
> all the best
> mark
>
>
>
> ________________________________________
> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of
> Signell, Richard [rsignell at usgs.gov]
> Sent: 30 September 2013 15:30
> To: Gregory, Jonathan
> Cc: CF metadata
> Subject: Re: [CF-metadata] Can we please close ticket 93 and modify
> the latest CF document accordingly?
>
> Jonathan,
>
> The good thing about the git "pull request" method of updating
> CF-conventions would be that someone can fork the repository (make
> their own copy of the document, in this case), make the edits related
> to their issue, and then submit a "pull request" to the person with
> authority to update the master document.
>
> The advantage is that the person with responsibility for the whole
> does not have to make all the edits themselves -- yet they can easily
> see and review how the edits look in a revised copy, and these can be
> accepted or discussed further with the community.
>
> So basically best of both worlds: easier for the community to
> contribute, and less work for the person with responsibility to
> maintain the master.
>
> -Rich
>
> On Sun, Sep 29, 2013 at 7:52 AM, Jonathan Gregory
> <j.m.gregory at reading.ac.uk> wrote:
> > Dear Mark, Rich, Bryan et al.
> >
> > I am definitely in favour of having a new version too, but I am
> nervous about
> > involving lots of people in what is essentially the editorial task
> of updating
> > the document. When many people revise bits of a document, especially
> if they
> > have not worked on it before, there is the possibility of
> inconsistency. You
> > still need someone to take responsibility for the whole.
> >
> > The main reason for slow progress in CF discussions is the
> limitation on brain-
> > power resources, not the technology for deploying those resources, I
> think. The
> > number of people who can make time to follow our detailed and difficult
> > discussions is understandably limited. None of us has it as a day-job!
> > However it would be interesting to know more about how different
> technology
> > from trac would make the task easier.
> >
> > Best wishes
> >
> > Jonathan


-- 
*******************************************************
* Nan Galbraith        Information Systems Specialist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130930/6686a283/attachment.html>
Received on Mon Sep 30 2013 - 12:59:29 BST

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

⇐ ⇒