[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Work Plan for the week (and UPCOMING VOTE)
So after consulting with the official parliamentarian of OASIS Process, we the minimum time for an on-line vote is 7 days. An on-line vote is not necessary to request a public review; we need only a quorate vote at a full meeting. I plan to call for such a vote at the meeting on Friday. I have received one set of comments on last night’s publication (mislabeling of new images inserted) and fixed that. At lunch today (I am in Central Time) I will upload CD01, that so far, is different from WD12 in that it has the captions fixed, uses CD01 rather than WD12, and has today’s date. If you know of any reason to delay, or any other new error I introduced, let me know before then. This new document, the Committee Draft as directed last Friday, becomes the basis of Friday’s vote. Please be ready to vote on Friday on whether to release for public review. Benoit, you will see some UTC discussion, as well as reference to the normative and non-normative discussions of the topic. This spec now suggests that other specifications and domains that use it consider carefully, read the references, and decide which of the ways of handling this, already built in to iCalendar, meet their needs. Dave: couple rounds of feedback with Mike and I think the CalConnect stuff is now included correctly. Cyrus’s white paper went in last night as Appendix C. XSD’s were uploaded in a separate zipped document file. They were used to make the examples. I included an iCalendar XSD so I could reference it. That is, of course, non-normative. XML namespaces were changed (Thanks Robin!) CalConnect TC members are now thanked after the acknowledgements. Broken references now fixed, at least the ones that were pointed out to me. For reference: http://www.oasis-open.org/committees/process-2009-07-30.php#committeeDraft Another order of business on Friday will be submitting a list of external stakeholders. I recommend: SGIP PAP04 list NAESB Smart Grid Task Force UCAIug (best mailing address or contact?) EIS Alliance FIX Protocol Association CalConnect ASHRAE SPC201 SGIP PAP05 list SGIP PAP09 list SGIP PAP010 list SGIP General list IETF Calsify Any others? 3.1 Approval of a Committee Draft The TC may at any stage during development of a specification approve the specification as a Committee Draft. The approval of a Committee Draft shall require a Full Majority Vote of the TC. The TC may approve a specification, revise it, and re-approve it any number of times as a Committee Draft. Before the TC can approve its Committee Draft as a Committee Specification the TC must conduct a public review of the work. The decision by the TC to submit the specification for public review requires a Full Majority Vote, and must be accompanied by a recommendation from the TC of external stakeholders who should be notified of the review. The Committee Draft approved to go to review shall be called a Public Review Draft. The public review must be announced by the TC Administrator to the OASIS Membership list and optionally on other public mail lists; the TC Administrator shall at the same time issue a call for IPR disclosure. Comments from non-TC Members must be collected via the TC’s archived public comment facility; comments made through any other means shall not be accepted. 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. No changes may be made to the Public Review Draft during a review. If changes are required the specification must be withdrawn from review then resubmitted. The TC may conduct any number of review cycles (i.e. approval to send a Committee Draft to Public Review, collecting comments, making edits to the specification, etc.). The first public review of a specification must take place for a minimum of 60 days, and any subsequent reviews must be held for a minimum of 15 days. Changes made to a specification after a review must be clearly identified in any subsequent review, and the subsequent review shall be limited in scope to changes made in the previous review. Before starting another review cycle the specification must be re-approved as a Committee Draft and then approved to go to public review by the TC. If Substantive Changes are made to the specification after the public review, whether as a result of public review comments or from TC Member input, then the TC must conduct another review cycle. The specification may not be considered for approval by the TC as a Committee Specification until it has undergone a review cycle during which it has received no comments that result in Substantive Changes to the specification. "If something is not worth doing, it`s not worth doing well"
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]