[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Procedural Question about Small Comments
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]