OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Categories for Public Comment and Defect-Report Items


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/17/2009 
08:32:34 PM:
> 
> After working with the public comment register for a while, and 
> adding another 100 public comment items, I began to use an expanded 
> set of categories (beyond defect, no-defect, and editorial).
> 
> My current working list is as follows, lining up pretty well with 
> the terms used in the SC34 defect report:
> 
>  * editorial - about wording or whether a non-normative statement 
> should be a note or not, etc.
> 
>  * omission - something specific is missing (may be a particular 
> kind of editorial problem)
> 
>  * incomplete - there is insufficient information to understand what
> a feature is and/or what is normative about it
> 
>  * inconsistent - statements that appear to be contradictory or not 
> consistent with what appears elsewhere
> 
>  * unclear - a problem making sense of the statement in the 
specification
> 

This is tricky.  I'm not sure the comments necessarily lend themselves to 
any flat classification scheme.    For example, "unclear" could apply to 
editorial or technical comments, and be caused by incomplete or 
inconsistent text, etc.  Some things characterize the nature of the 
defect, while other characterize the cause of the defect, while others 
characterize the impact of the defect.  We also need to make it clear 
whether we are classifying the comment, or classifying the defect.

For classifying a comment, I think our process would lead to a 
multi-dimensional classification scheme:

A) Where did the comment come from:

1) Comment received on public comment list
2) Comment received in SC34 defect report
3) Comment received from ODF TC member

B) When was the comment received:

1) Comments received during an official public review period (these have 
mandated processing requirements under OASIS rules)
2) Comments received outside of official public review period

Then we can classify the comment as to the nature of the change requested.

C) What change is requested:

1) New feature proposed
2) Editorial correction requested
3) Technical correction requested
4) No change is suggested.

We could use the JTC1 definitions of editorial and technical here:

Editorial defect is "An error which can be assumed to have no consequences 
in the application of the IS, for example a minor printing error."

Technical defect is "A technical error or ambiguity in an IS inadvertently 
introduced either in drafting or in printing which could lead to incorrect 
or unsafe application of the IS."

(Note that the JTC1 definitions are not really binary, though they do not 
give a name to the set of defects which have consequences, so are not 
editorial, though the consequences do not lead to incorrect or unsafe 
application, so they are not technical defects.  We could introduce the 
terms "major technical" and "minor technical" to fill that semantic space 
more completely.)

We also need to consider the question of whether the change requested is 
Substantive, by OASIS definition, since that limits what can and cannot be 
changed in an Approved Errata document.

D) Is the requested change a Substantive Change?

1) Yes
2) No

OASIS TC Policy 1.aj says: "Substantive Change" is a change to a 
specification that would require a compliant application or implementation 
to be modified or rewritten in order to remain compliant. 


We also need to track our formal disposition of the comment.

E) How shall the comment be disposed:

1) No action.  Comment already addressed in XXX.
2) No action.  Comment duplicates previously received comment #XXX
3) No action.  Comment is in error.
4) Will correct in version XXX of ODF Standard
5) Will correct in version XXX of ODF version YYY Approved Errata
6) Will consider as a new feature in version XXX of ODF Standard


We've had other "actions" like referring to OpenFormula subcommittee, 
etc., but these are not really dispositions, but are more like steps on a 
workflow toward arriving at a disposition. 


> I've stopped using a no-defect category, although that can certainly
> be a disposition. 
> 
> These seem to be sufficient for all of the N1078 items that we 
> should review for a disposition report back to SC34.  I have stopped
> using the simple category "defect."
> 
> There are some additional categories that arise, but not among the 
> defect-report items:
> 
>  * proposal - a request for a feature or some specific suggestions 
> about process or content
> 
>  * comment - an expression of opinion with nothing actionable presented
> 

Non-actionable comments are tricky.  Outside of a public review period we 
do not need to process them.  No need to even transcribe them into the 
spreadsheet.  But during formal review periods we must formally track all 
comments received, since OASIS process requires that the TC: "acknowledge 
the receipt of each comment, track the comments received, and publish to 
its primary e-mail list the disposition of each comment at the end of the 
review period. "  We could certainly get into the practice of recording 
all comments regardless of whether we are in a review.  But this might be 
difficult, especially when the comment list starts to degrade into a 
discussion forum.  What is a comment versus free-ranging discussion?


>  * contribution - feedback of some kind, with suggestions, not (yet)
> classified further
> 
>  * objection - some exception taken to direction or existence of a 
> provision, often quite general (e.g., proposals to put spreadsheets 
> out of their misery) 
> 
> These are probably too many, but they seem helpful in understanding 
> the general nature of a particular submission.  Of course, any 
> applications of categories that I have used are only straw-men 
> subject to the discussion and determination of the TC. 
> 
>  - Dennis
> 
> PS: There is one kind of comment that I have not found a 
> satisfactory initial category for.  An example is many of the public
> comments from David King that suggest clarifications and corrected 
> language around aspects of OpenFormula, as well as make questions. 
> I've been calling these contributions for lack of a better term that
> may arise out of closer screening. 
> 

This probably doesn't impact the classification.  It is still editorial or 
technical defect, or feature proposal.  But how we dispose the comment 
will be difference depending on whether it pertains to an already approved 
OASIS Standards versus an in-progress  draft.

> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability 
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]