Re: [office] Procedural Question about Small Comments

[robert_weir@us.ibm.com]

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 08/25/2008 
03:51:53 PM:

> 
> This is probably for Rob Weir and Michael Brauer.
> 
> As I turn my attention to particular sections of the ODF 
> specifications, I continue to notice individually-small things. 
> Previously, I would have submitted them to the office-comment list.
> 
> Now that I am a member of the TC, I want to know whether (1) I 
> should continue to use office-comment when they are equivalent to 
> what's appropriate as a -comment (so others can know that these are 
> being noticed), (2) I should instead use the office list the same 
> way, or (3) I need to use the proposal mechanism.
> 

The OASIS policy on this stated in OASIS TC Process 2.8 "TC Visibility"

"The purpose of the TC?s public comment facility is to receive comments 
from the public and is not for public discussion. Comments shall be 
publicly archived, and shall be forwarded to one or more Members of the TC 
including the TC Chair. TCs shall not be required to respond to comments. 
Comments to the TC made by Members of the TC must be made via the TC 
general email list, and comments made by non-TC members, including from 
the public, must be made via the TC?s comment facility. Comments shall not 
be accepted via any other means."

http://www.oasis-open.org/committees/process.php#visibility

So TC members submit comments to the TC list, while non-members submit to 
the comment list.  This reflects the different IP obligations involved for 
members (RF with Limited Terms) versus non-members (OASIS Feedback 
Licence).

The Proposal mechanism is used for feature proposals, adding new 
functionality, features, etc.  It is not required for simple editorial 
fixes.


> Here's an example that I just stumbled upon.  The optional table:is-
> data-layout-field attribute has a default value of "false" (ODF 1.1 
> section 8.8.4, Is Data Layout Field sub-heading).  It is defined as 
> a string, not a boolean, in the schema.  There is no explanation of 
> how a value other than a boolean one has any significance, and I 
> assume this is a simple bug, but perhaps more than an erratum is 
> permitted to resolve? 
> 
> Or it might be worthwhile to make a comment to the appropriate list 
> and then wait to see if someone says a proposal is needed?
> 


My recommendation would be this:


If you, as an ODF TC member, find an error in an published version of ODF, 
then:

Ask yourself: Is it a technical error or an editorial error?  Will 
implementors reasonably be able to figure this out?  Or is it enigmatic? 
Is it a typographical error?  Or a real bug?

If it is a serious error, then check the existing errata documents, 
published as well as draft, to see if it is already fixed.  If it is not 
already fixed, then post a note to the ODF TC list, reporting the bug.  A 
proposed correction is always appreciated.  We will then add it to the 
current working draft for the next errata document.

If the problem is not serious, then check the current working draft of ODF 
1.2 to see if the error occurs there as well.  If the error is in the 
current draft, then send a note to our Editor, Patrick Durusau, so he can 
fix it there.  There is no need to discuss on the TC, or in a meeting 
simple typographical and editorial fixes. If it is obvious what the fix 
is, then sending it to Patrick is the most efficient way of handing it.

If the error is not in the current working draft, then I personally would 
drop it.   My inclination is not to expend energy on tracking down and 
fixing minor editorial errors in ODF 1.0 or ODF 1.1.  But if you 
personally have an interest in doing that, then we can certainly set up a 
mechanism, perhaps a spreadsheet similar to our Public Comment Registry, 
for you to record such defects.

But remember, in 6 months, when we can do the next Approved Errata for ODF 
1.0, ODF 1.2 will likely already be complete.  Implementors have already 
moved along to ODF 1.1, and some (like OpenOffice.org) have already 
started the move to ODF 1.2.  So the practical utility of errata for ODF 
1.0 in 2009, when it is two revisions out of date, may be quite minor. 

-Rob

-Rob