UCD problem in SSA/SpectrumDM

[Robert Hanisch]

On 11/24/09 5:48 AM, "Keith Noddle" <ktn at star.le.ac.uk> wrote:

>> Indeed, as stated by Ray, even "minor" revisions should go through the
>> recommendation process.
> I wish to point out that I did also state this in my reply to Doug on
> 20th; there never was any doubt that even the most minor of changes
> requires full approval - I was trying to suggest that the extent of the
> change will be proportional to the time approval takes, that's all.
> 
> What doesn't seem clear to me is whether the IVOA has mandated that
> minor revisions MUST be backwards compatible with previous revisions of
> the current document (i.e. V1.6 MUST be backwards compatible with V1.1
> etc). Maybe I've missed it somewhere, but if it isn't explicitly stated
> then IMHO it should be.
Hi Keith.  This is stated explicitly in Section 1.2 of the standards process
document:

" After a document reaches Recommendation status, subsequent revisions
retrace the promotion process.  Changes that are backward compatible result
in increments in the number to the right of the decimal place (1.1, 1.2,
...).  Changes that are not backward compatible require an increment of the
number of the left of the decimal place (2.0), with subsequent backward
compatible revisions following the same pattern (2.1, 2.2, ...)."

Having been one of the architects of this review and promotion process, this
discussion makes me wonder whether we need a more expedient way to deal with
legitimate mistakes.  At the level of typos I would hope we could agree that
these could simply be fixed, e.g., with the oversight of the standing
committee on process.  A new version of the document (with date of issuance
revised) would replace the previous one and changes duly noted in the change
log part of the paper.

For mistakes such as the incorrect UCD that led to this discussion the
situation is not black-and-white.  Such a mistake causes changes to code,
which invokes the "new version" rule, but hardly seems to require engaging
the entire review machinery.  Of course, allowing things into this gray area
becomes a matter of judgment (by whom?), and risks a foray into
arbitrariness.  Maybe we need a lightweight "re-review" process for such
situations.  In any case, let's try to not get out of control with rule
making, lest we have to start hiring legal counsel into all of our teams!

Your approach of gathering things together makes sense to me.

cheers,
Bob