Re: [office] ODF 1.2 Endgame Schedule (proposal for discussion)

[robert_weir@us.ibm.com]

Sorry if I wasn't clear.  Let me try again. 

Section 3.2 of the TC Process gives three requirements with regards to 
received comments:

1) Acknowledge receipt

2) Track

3) Publish dispositions

I wanted to confirm that:

A) Nothing additional is required to acknowledge receipt beyond what the 
office-comment list and JIRA already do, i.e., automatically send the 
author of the comment (along with everyone else subscribed to the list) a 
copy of the comment.

B) Tracking the issues in JIRA alone is sufficient, to the extent we can 
define a range of dates or JIRA issues that comprise those received during 
the public comment period.

C) There is no required process for approving the disposition log.   In 
particular I see nothing in the TC Process that mentions a vote to approve 
it or required majority for such a vote.  Perhaps it assumed that new CD 
and CS accurately reflects the published disposition of comments, and TC 
members approve the disposition via their approval of the CD and CS.  But 
this assumption may not be true.  I've certainly seen, in other 
organizations,  published standards that did not accurately reflect 
disposition reports, even when such reports were voted on and approved by 
the membership.

I thought it best to clarify these items now rather than risk delay later.

Thanks!

-Rob

robert_weir@us.ibm.com wrote on 09/18/2010 01:04:29 PM:


> 
> Re: [office] ODF 1.2 Endgame Schedule (proposal for discussion)
> 
> Mary,
> 
> So what exactly do you need to see to demonstrate that we've done that? 
> The TC Process is a bit vague on this.  Section 3.2 says:
> 
> "The TC must acknowledge the receipt of each comment, track the comments 

> received, and publish to its primary e-mail list the disposition of each 

> comment at the end of the review period."
> 
> In the past I think you've said that the echoing of public comments to 
the 
> comment mailing list is sufficient acknowledgement of receipt.  I assume 

> the same is true of JIRA comments.  I'm hoping we don't need to 
undertake 
> a massive audit of whether any notifications were not sent due to the 
> downtime of OASIS servers that occurred during the public review.  My 
> understanding is that some emails were delayed, but no comments were 
lost.
> 
> All issues, public and member comments, are tracked in JIRA.  When an 
> issue is resolved in JIRA the resolution is echoed via an email to the 
> TC's list.  So I believe that each comment's disposition is being 
> published per section 3.2.
> 
> Do you require more than that?  If so, what exactly?
> 
> I realize the Process was written pre-JIRA, so it may not permit the 
most 
> logical and useful way of reporting this, which would be to record in 
the 
> minutes that review comments are JIRA XXX - JIRA YYY inclusive and all 
> have been disposed per the JIRA record.
> 
> -Rob
> 
> Mary McRae <mary.mcrae@oasis-open.org> wrote on 09/17/2010 07:28:14 PM:
> 
> > 
> > Re: [office] ODF 1.2 Endgame Schedule (proposal for discussion)
> > 
> > Of course any comments submitted from TC members must be considered as 

> well ;)
> > 
> > Regards,
> > 
> > Mary
> > 
> > Mary P McRae
> > Director, Standards Development
> > Technical Committee Administrator
> > Member Section Administrator
> > OASIS: Advancing open standards for the information society
> > email: mary.mcrae@oasis-open.org 
> > web: www.oasis-open.org
> > twitter: @fiberartisan  #oasisopen
> > phone: 1.603.232.9090
> > 
> > Standards are like parachutes: they work best when they're open.
> > 
> > On Sep 17, 2010, at 4:58 PM, robert_weir@us.ibm.com wrote:
> > 
> > > Now that the 60-day public review of ODF 1.2 has been completed, I'd 

> like 
> > > to review the work remaining for the TC before we have an official 
> OASIS 
> > > Standard.
> > > 
> > > The remaining stages are (and this is my interpretation -- feel free 

> to 
> > > consult the official process documentation for the fine details, and 

> there 
> > > are many, many fine details: )
> > > 
> > > 1) Dispose the public comments received, i.e., decide what we will 
do 
> in 
> > > response to them.
> > > 
> > > 2) If this includes revising the specification, and it certainly 
> appears 
> > > this will be the case, then we must approve a new CD, which would be 

> CD 
> > > 06, and send that out for  a 15-day public review of the changes.
> > > 
> > > 3) If we receive comments on CD 06, and wish to make changes, then 
we 
> loop 
> > > back to step #1. 
> > > 
> > > 4) If we receive no additional comments, or elect to make no changes 

> in 
> > > regards to comments then we can vote on the CD as a Committee 
> > > Specification.
> > > 
> > > 5) We then submit the Committee Specification along with various 
> > > additional pieces of documentation to Mary and request a ballot. 
> > > Additional information would include:
> > > 
> > > a) TC's certification that the schemas are well formed
> > > 
> > > b) 3 statements of use from OASIS members using the Committee 
> > > Specification
> > > 
> > > c) clear English summary of the standard.  (and I wonder if we could 

> also 
> > > optionally include a clear German, Chinese, French, Portuguese, 
Dutch, 
> 
> > > etc., summary?)
> > > 
> > > d) minority reports, if there are any, from any member(s) who 
> abstained or 
> > > voted against the Committee Specification.
> > > 
> > > e) a bunch of links to ballot results, the editable version of the 
> > > specification, the public comment list, etc.
> > > 
> > > 
> > > 
> > > The OASIS Standards ballot run on a fixed monthly schedule, 
something 
> like 
> > > this:
> > > 
> > > a) We notify Mary that we're ready for a ballot in the first 2 weeks 

> of 
> > > any month
> > > 
> > > b) Mary has the last two weeks of the month to verify our materials
> > > 
> > > c) The ballot is sent out to OASIS members on the first day of the 
> > > following month, but only FYI at that point
> > > 
> > > d) The actual OASIS ballot occurs in the last two weeks of that 
month
> > > 
> > > e) Ballot results are announced at the start of the 3rd month.
> > > 
> > > If this sounds complicated, it is because it is complicated.  There 
> are a 
> > > lot details.  Luckily we have a spreadsheet that helps calculate the 

> > > dates, including logic to handle the monthly schedule for OASIS 
> ballots: 
> > > 
> > > http://docs.oasis-open.org/templates/TCHandbook/content/tcprocess/
> > standardsapprovalprocess/specificationlifecycle.htm
> > > 
> > > November 1st is a Monday.  Suppose we are ready for a CD 06 ballot 
on 
> > > November 1st, and do that via a 7-day ballot.   That results in an 
end 
> 
> > > game like this:
> > > 
> > > 2010-11-08 OASIS TC Admin notified of request for public review
> > > Mon 15 Nov 2010  TC Administrator must either post the specification 

> for 
> > > review or return with explanation for rejection
> > > Mon 15 Nov 2010 Start of 15-day public review
> > > Wed 08 Dec 2010 Request ballot for Committee Specification and OASIS 

> > > Standard ballot
> > > Wed 15 Dec 2010 TC Administrator must either start the ballot or 
> request 
> > > additional information
> > > Wed 22 Dec 2010 7-day ballot close
> > > Sat 15 Jan 2011  TC Chair must submit OASIS Standard Ballot 
submission 
> to 
> > > TC Administrator
> > > Mon 31 Jan 2011 TC Administrator must accept / reject submission
> > > Tue 01 Feb 2011 Familiarization announcement sent to OASIS 
membership
> > > Wed 16 Feb 2011 OASIS Standard Approval ballot
> > > Tue 01 Mar 2011 Announcement of Ballot results to membership
> > > 
> > > Because of the fixed monthly schedule for OASIS Standards ballots, 
> there 
> > > is some slack in the above schedule.  In fact, we could request the 
> 15-day 
> > > public review as late as December 2nd and still end up with the 
> > > announcement date of March 1st.  On the other hand, if we can bring 
> the 
> > > public review request 1 week to November 1st, we end up getting a 
> February 
> > > 1st announcement date, saving a whole month. 
> > > 
> > > In any case, please be aware, at least at a high level, that we have 

> > > approximately 2-3 months of "process stuff" we need to work through, 

> and 
> > > that this is going to be very sensitive to timing.  A slip of a day 
at 
> 
> > > critical places results in a slip of a month in the end stage.  This 

> > > doesn't mean we cut corners, but it does suggest:
> > > 
> > > 1) Raise issues early
> > > 
> > > 2) Review proposed CD's early
> > > 
> > > 3) Try to move things along via meeting votes where possible
> > > 
> > > 4) Obviously try to attend meetings regularly so we have enough 
people 
> to 
> > > do #3
> > > 
> > > 5) Resolve issues early
> > > 
> > > 6) Some items need more consideration or implementation experience. 
We 
> 
> > > shouldn't feel bad about deferring items to ODF-Next if that is what 

> is 
> > > necessary to do them well.
> > > 
> > > I'd like to aim for a November 1st date for requesting the 15-day 
> public 
> > > review.  That would mean that the final CD draft text would need to 
be 
> 
> > > posted week before, say October 25th, or better yet the Friday 
before, 
> 
> > > which is October 22nd.
> > > 
> > > That suggest that we need to aim to resolve all open issues well 
> before 
> > > that date, so there is time to apply the fixed.  Something like 
> October 
> > > 11th, e.g., 3 weeks from now.
> > > 
> > > Let's discuss this on Monday's call and see if we can agree to a 
goal.
> > > 
> > > As always, it is an honor to work with you all.  In some ways it is 
> sad it 
> > > see this come to an end.  But remember, this is only the next step 
for 
> 
> > > ODF, not the last.  There is even more interesting stuff in store 
for 
> > > ODF-Next, so let's get moving toward it!
> > > 
> > > Regards,
> > > 
> > > -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 
> 
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > 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 

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