OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Categories for Public Comment and Defect-Report Items

    Posted 01-18-2009 01:33
    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
    
    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
    
     * 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.  
    
    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 
    
    


  • 2.  Re: Categories for Public Comment and Defect-Report Items

    Posted 01-18-2009 17:11
    "Dennis E. Hamilton" 


  • 3.  RE: [office] Re: Categories for Public Comment and Defect-Report Items

    Posted 01-18-2009 18:27
    Thanks Rob,
    
    With regard to the first part, the basic categories are with regard to what
    the submission says the problem is, taking into account both the text and
    any classification that is provided with the submission.
    
    I agree that these are not orthogonal and there is often a gray area (for
    example, between omission and incomplete, where the latter is more likely to
    be a substantive matter relating to under-specification).
    
    I think the determination of substantive in terms of whether or not an
    implementation would be impacted by resolution is a separate determination.
    Part of it has to do with whether the feature has even been implemented (as
    we have discovered) and also whether the more-or-less obvious simple case
    and/or "do whatever OO.o does" approaches have actually prevented there
    being a problem.  I don't think the provisional assignment of categories can
    or should deal with that, but rather be accounted for in the disposition and
    the actions to determine what remedy, if any, is possible. 
    
    There is now a "Source" column in the register, although most entries are
    blank and the source is the public comment list.  SC34 defect-report items
    are identified in the column already.
    
    To sharpen some of these, I think I use "omission" only when the submission
    says what the omission is or where there appears to be an omission.
    
    Incompleteness is generally a submission that claims that something is
    incompletely specified.
    
    Unclear is generally when a portion of the specification is claimed to be
    not understandable or just plain confusing.  
    
    Inconsistency is when the submission claims that there is a contradiction or
    an inconsistency with something said elsewhere.  Sometimes it may be changes
    in nomenclature that might be resolved as an editorial correction (use of
    the wrong or undefined term in place of the one introduced elsewhere) and
    sometimes it might be something more substantial.
    
    My general approach in this process is to take the submitter's word for it
    until there is a closer examination.  The important thing is I don't think
    these are dispositive.  That should be a separate item, which is what we say
    it is, as opposed to what the main thrust of the submission is.  Also, we
    might concur with the identification of a problem (and when someone says
    something is unclear, we should believe them), but not the suggested remedy,
    if any.  
    
    Other matters, such as the standing of a submission and responsibility of
    the TC to have a response of some sort is something I would like to keep
    orthogonal to characterization of the substance of a submission (as opposed
    to the import of that after review, disposition, and action).
    
     - Dennis
    
    PS: As far as I am concerned, all comments from external sources, unless
    clearly capricious, are meritorious at any time and under all conditions.  I
    think there should be a transparent process for their disposition, with the
    decision to go forward, take action, or simply let them sit made explicit.
    (Although it does not happen often, it does happen that SC34 errata point at
    something that already arose elsewhere, including within the TC or an
    earlier public comment from other submitters.)  It is one of the things that
    distinguishes open efforts such as OASIS TC, W3C comment handling, and of
    course IETF technical committee conduct.
    
    PPS: With regard to discussion on the public comment list, it is pretty
    clear when that is happening, including when the discussion is between the
    submitter and TC members.  I have not added those to the list beyond the
    original submission which was directly to the list and not any subsequent
    on-list discussion.  Sometimes the discussion may lead to retraction and
    sometimes there is a proposed disposition (e.g., some adjustment in an
    OpenFormula definition).  I would think closing out the original submission
    involves finding out what has actually been done in the specification, just
    as we need to regression-check 1.2 against previously-accepted comments and
    any errata based on them.