Re: [office] Required items for a public review

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

On 11/17/08 11:45, robert_weir@us.ibm.com wrote:
> Michael.Brauer@Sun.COM wrote on 11/14/2008 09:58:57 AM:
>> Der TC members,
>>
>> below is a list of items that in my opinion have to be addressed before
>> we can submit ODF 1.2 for a public review
>>
> 
> A) Public review is one step along the path to approval as an OASIS 
> Standard.  For the benefit of TC members who have not been through this 
> process before, the important steps are:
> 
> 1) Approval of a Committee Draft.  This can be done at any time, by Full 
> Majority Vote of the TC.  There are no other requirements.  The TC can 
> issue as many numbered Committee Drafts as it wishes.  I'd like the TC to 
> make more use of this level of approval, considering that we have some 
> stakeholders/partners, such as the accessibility SC, or JTC1/SC34 members, 
> who may want more time to review and discuss an ODF 1.2 draft than 
> provided for in a 2-month public review.
> 
> So I'd recommend that we approve a Committee Draft and notify the 
> Accessibility SC and JTC1/SC34 of it as soon as the following minimal 
> requirements are met:
> 
> 1) The draft has durable part, section and clause references.  In other 
> words, any gross reordering, restructuring of the specification is 
> complete.  In particular, the division into multiple parts has been 
> completed.  The goal is to ensure that if someone reports a defect in Part 
> X, Clause Y.Z, that we can reliably find and address it, even in future 
> drafts.

The division into multiple parts is completed. The restructuring of part
1 is nearly completed. So, at least for part 1, we are close to meet
this requirement.

> 
> 2) All public comments submitted against ODF 1.0 or ODF 1.1 or previous 
> drafts of ODF 1.2 have been addressed.   I'd prefer not to issue a draft 
> with known errors in it.  This would be look bad, especially if the errors 
> had been reported much earlier. 

That's an item we indeed should add. I think the simplest way to proceed
here is if we find a TC member that volunteers to go through all
comments that are classified as defects and checks whether they still 
occur. That's at least what we did for ODF 1.0 and 1.1.

> 
> That's it.  I wouldn't hold back a Committee Draft for incompleteness of 
> technical content.  A Draft is work-in-progress.  By making such a Draft 
> available, we make it clear that we invite and encourage early feedback.

If we add new content to the specification, then the section numbers of
items may change and there may be side effects to other parts of the
specification. For that reason, I think we should aim to integrate
outstanding proposals as soon as possible. We have about 25 of them. The
schema is already adapted, so this should be reasonable effort.

[...]

> D) Approval as OASIS Standard
> 
> Once we have a Committee Specification, the TC can vote to submit it for a 
> ballot of the OASIS membership (not just the TC, but all of OASIS) for 
> approval as an OASIS Standard.  In addition to a Committee Specification, 
> we require these additional items:
> 
> 1) Certification from the TC "that all schema and XML instances included 
> in the specification, whether by inclusion or reference, including 
> fragments of such, are well formed, and that all expressions are valid;"
> 
> Since an error here would send us back to another public review (assuming 
> changing the schema may be considered a substantive change), we should 
> verify these requirements much earlier, probably before sending the 
> Committee Draft out for public review.
> 
> Michael, we have automation to check this, right?

I have a style sheet that compares the schema with the specification and 
vice versa, and validating that the schema itself works is quite simple. 
So, these checks do exists.

I have nothing yet for examples. We should add this item. The solution
can be an automatic test (preferred), or someone has to check them manually.


>>
> 
> We need to consider how we want these three parts balloted at the OASIS 
> level.  If we want three separate ballots, for three separate standards, 
> then we would have three different public reviews.  But if we want a 
> single "OASIS ODF 1.2" that has 3 parts, then I think we want a single 
> public review.  However, approval of the parts as Committee Drafts can 
> occur in any order, as you indicate.

We may also have three individual public reviews but one OASIS ballot.
This has the advantage that we can use the time where part 1 is under
public review for the completion of part 2 and 3, and can use the time
were part 2 and 3 are reviewed to process the comments we received for
part 1. This may save us some time, because otherwise we would have to 
stop work on the specification for two months, and then would have to 
process the comments for all parts at once.

Best regards

Michael


-- 
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