Re-baselining Dex1 capabilities

["Tim Turner" <timturner11@bellsouth.net>]

Dear All,

subject to the last meeting in Lillehammer, I have been looking into
re-baselining Dex1 and the capabilities therein. This was an action for
Trine & myself to execute, which I have assumed responsiblility after
discussion with Trine. I note that with some incredulity that this was not
actually logged as an action in the minutes (with me as the action noter)!

I attach a table indicating the current versions of the capabilities that
exist, those which I consider to be relevant for the baseline prior to the
additions from the pilot & the proposed revision number for the baseline
itself.  The work of the pilot has been a useful learning exercise and has
helped to provide better direction for our work & the (capability) versions
created during this work are of course logged within sourceforge for
reference & will not be lost.

I seek a recommendation from the Dexlib administrator (Rob) whether to
create branch points for these prior revisions or to create a new revision
based upon that selected for the baseline. I assume that we should do the
latter but I am open to use of branches though I don't know if our toolset
is sophisticated enough at present to use these.

I have editorship for 8 or 9 of the affected capabilties, but not for the
other ones. If you are an editor for one of the capabilities identified in
the attached, then please let me know if you agree to this baseline version
or whether you have an alternative suggestion to achieve this. If I get no
response then I will ask the administrator to make the changes by the end of
this coming week. I will act on those I am responsble for as soon as I hear
back on the branching issue above.

My only other question is to other Dex leaders - do you have a baseline for
your Dex & how has it been defined (other than by date)?

regards,
Tim

NB - I'd like to make 3 comments & recommendations based upon my experience
in re-baselining Dex1 & its capabilities;

1. The versioning system of cvs has proved very useful. However, because the
commenting by the various editing team members has been so sparten I have
had to compare each version back to the point where I believe the baseline
existed. This was an arduous, time consuming task. Comments such as
"update", "revised", "upload" etc., are NOT useful to anyone attempting to
understand changes that have been made. I therefore, recommend that we seek
to have more MEANINGFUL documentation of changes effected by editors (or
ANYONE making changes). I, as well as many others have been guilty of this
sort of sparten documentation.

2. Some versions of capabilities were apparently worked on in isolation from
the cvs repository and as a consequence updates were made in parallel. This
is NOT an acceptable approach! In this case the main changes between these
versions were an adjustment of the reference data being used by the
capability (e.g. C079 - rep.props.numerically). However, when the edits from
the pilot were "uploaded" - those references appear to have been lost in the
current edition. I therefore, recommend that current editors either "lock"
their capabilities or, as I think was suggested in Lillehammer, that changes
be sent to the editor for updating. Personally, I would suggest that we do
BOTH.

3. There is DEFINATELY a need to be able to baseline (freeze) a version of a
Dex. This is not a wish - it has to happen & soon. This should be done
though a recording of each version of the capability used by a Dex. In
practice, this should extend deeper, such that each capability even records
the versions of the modules that it uses. Without this we are going to end
in a real pickle & soon. If we haven't reached this point already I think we
are fast approaching it. In my mind this should be a PRIORITY on the toolset
development. It need not freeze development of capabilties but will provide
a tool for establishing credible versions of the Dex for review, comparison
and management.

kind regards,
Tim

Dex1CapVersions.xls