Re: [office] Required items for a public review

[robert_weir@us.ibm.com]

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.

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 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 want to, we could have staged Drafts with target dates and targeted 
milestone content.

B)Public Review.  This is required to progress a Committee Draft to the 
Committee Specification stage.  The public review is for a minimum of 60 
days.  Since a public review brings with it the requirement to track and 
acknowledge each comment received, and the TC cannot make any changes to 
the specification during the public review, we should not be going to this 
stage until we believe the specification is complete and ready for 
approval. 

I like the list here that Michael has provided:

> - The conformance clauses have to revised (already in progress for part 
1)
> - Approved proposals have to be integrated into the specification and
> the schema where this did not happen already.
> - An appendix that describes changes from ODF 1.1 has to be prepared.
> - Parts 2 and 3 (formulas and packages) have to be restructured to meet
> the structure of part 1.
> - Svante got feedback from the RDF working group regarding the metadata
> proposal. This should be analyzed (Svante is in vacation currently, so I
> have not much more information on this than the information that Svante
> has posted to the list).
> - I've heard several suggestion that it would be advantageous to use
> NVDL for ODF 1.2 to improve our validation possibilities. We need to
> decide on this. But if we want to use NVDL, then we have to prepare the
> style NVDL scripts. I have uploaded a prototype some time ago. This
> should be not too much effort.
> - References to the schema have to be added
> - The "Acknowledgments" section has to be updated.
> 


It may be good to agree to a proposal deadline.  For example, all new ODF 
1.2 proposals must be submitted by December 31st, 2008, or something like 
that.   We should give a fair opportunity for members to submit new 
proposals, but for planning purposes we need to have a clear end in site, 
so we can advance the specification through the approval process.

C) Approval of Committee Specification

This occurs after a successful public review.  If we complete a public 
review and no public comments result in substantive changes to the 
specification, then the TC can vote to approve the specification as a 
Committee Specification.  But if substantive changes are made, then we 
revise the specification and conduct another, shorter (15 day) public 
review on the changes. 

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?

2) Three "Statements of Use", where this is defined by OASIS as "a written 
statement by an OASIS Organizational Member stating that it is 
successfully using or implementing that specification in accordance with 
the conformance clauses specified in Section 2.18, and stating whether its 
use included the interoperation of multiple independent implementations."


> I believe some of you have additional items, including maybe a few 
> proposals under discussion. Please let us know them, so that we add them 

> to the list.
> 
> What I would like to suggest is that we collect all items into the Wiki 
> and add names to the items together with an estimate when the item may 
> be completed. We may then review the list in each call, and, if the most 

> essential items are resolved, determine whether we consider the open 
> items to be show stoppers for a public review or not.
> 
> My proposal regarding the public review itself is that we first
> concentrate on completion of part 1, and that we simultaneously ensure
> that part 2 and part 3 are complete in the meaning that all approved
> proposals are integrated.
> 
> We may then approve all three parts as committee drafts, but may
> submit part 1 for public review only. The two months public review
> period may be used to get part 2 and 3 into the same shape as part 1,
> and to complete open items we have there.
> 

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.

My overall preference would be to have a targeted series of 3-5 Committee 
Drafts which take us to a Draft that is technically complete, includes all 
submitted proposals, addresses all submitted public comments, and which 
meets the other requirements for ODF 1.2.  We then submit this draft for 
public review.  We will probably need to conduct at least one follow-up 
15-day review.  Then we can go for Committee Specification approval.

Regards,

-Rob

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