Re: [office] Procedural Question about Small Comments

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

I agree to Rob's explanations and suggestions.

Michael

On 08/25/08 23:45, robert_weir@us.ibm.com wrote:
> "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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering