1. Restructuring the CCA Specification Process Gary Kumfert, LLNL

2. Outline Intro – why change it? Comparative Study of Specification Processes in SW Standards Bodies  W3C  OMG Gary’s Top 4 Changes for CCA Words of Reassurance Discussion

3. Current Specification Process Simple Majority of Votes Cast Eligible voters attend 2 out of last 3 meetings

4. Problems with current specification process Very small % of eligible voters actually vote Actual Spec is not on website Quality of the specification varies Changes have been unilaterally made for expediency No sense of shared ownership Efforts stall, aren’t transparent, aren’t engaging newcomers

5. Consider how other standards bodies operate W3C  Over 90 interoperable web technologies HTML, CSS, PNG, XML, XSLT, DOM, etc…  W3C Process Document 2005-10-14  http://www.w3c.org/Consortium/Process http://www.w3c.org/Consortium/Process OMG  UML, MDA, CORBA  OMG Hitchhicker’s Guide 7.4  www.omg.org/docs/omg/06-12-05.pdf www.omg.org/docs/omg/06-12-05.pdf

6. W3C Process: Understanding the Heirarchy W3C Team – Director, Chair, Chief Operating Officer (COO), staff, interns, W3C Fellows. Advisory Board – management, appeals, etc. Technical Architecture Group – stewards of web architecture Advisory Committee – 1 rep / organization Working Group – chartered for 6-24 months for specific technical deliverable

7. W3C Process Focuses on Consensus Maturity Levels for Recommendation Track  Candidate Recommendation (CR) – call for implementations  Proposed Recommendation (PR) – sent to advisory committee for final endorsement  W3C Recommendation (REC) – finalize document Alternate Tracks produce other documents  Work in Progress  Working Draft (WD)  Technical Report  Working Group Note  Editing a Recommendation  REC  Rescinding a Recommendation  Interest or Coordination Groups  Notes

8. W3C Process: Technical Report  Recommendation 1.First public working draft (WD) 2.Last Call Announcement  Ideally, WG will only receive support, no proposals for substantive change 3.Call for Implementations (CR)  WG lists present and expected implementations in request 4.Call for Review of Proposed Recommendation  At least two interoperable implementations expected 5.Publication of W3C Recommendation W3C may stop work, or require additional work (including repeating one or more steps).

9. OMG Process: Understanding the Heirarchy Board of Directors 3 Plenary Bodies  Architecture Board (AB) – final stamp, may charter SIG or SCs, not TF  Domain Technology Committee (DTC)  Platform Technology Committee (PTC) 3 Chartered Subgroups  Subcommittee – organizational issues  Task Force – issues RFPs and evaluates submissions  Special Interest Group – may not issue RFPs, RFIs. Typically exist for months – 1 year (or more) to demonstrate memership can sustain effort to recommend and sustain technology

10. OMG’s 15 step Technology Adoption Process 1.(opt). TF issues RFI 2.TF creates RFP 3.AB certifies consistency with existing OMG tech. 4.ParentBody votes to issue RFP 5.Submitting companies submit LOI 6.Initial Submissions to TF 7.Revised Submissions to TF (repeat as needed) 8.TF evaluates solutions and recommends one to parent body 9.AB certifies compliance with MDA & consistency with existing OMG tech 10.ParentBody votes to send to BoD 11.BoD Business Committee certifies implementations available within a year 12.BoD votes to promote to “adopted specification” 13.FTF conducts first maintenance revision 14.FTF report certified by AB and recommended by ParentBody, and at least one implementation commercially available 15.BoD votes to promote to “available specification”

11. Details that I left out Detailed min/max timelines Grievance and Arbitration processes Documentation standards IP policies Eligibility, tenure, & conflict of interest policies for various stages of the hierarchy

12. Key features from W3C’s and OMG’s Processes to consider. Specifications are STAGED Specifications are OPEN Implementations are REQUIRED for final stages Architectural Oversight (incl. veto & redo) Chartered subgroups:  Every member is not expected to vote on every proposal at every stage  Folks who want a say, must sign up for some work. Other artifacts (Technical Reports, Working Documents, etc.) are published.

13. Gary’s Top 4 Changes to CCA Spec Process Please limit discussion here to the principles. Hold off on implementation details ‘til end.

14. Change #4: Task forces w/ charters, lifespan, & named chair Why? Accountability We already have informal groups and BOFs BUT,  Some things linger too long  Others fall off radar  Outsiders have a hard time seeing what’s “in the works” The end state of every task force should result in some kind of document, even if working notes. Existing working groups, charter (even if only a paragraph), & ending state should be logged on the cca-forum website / wiki.

15. Change #3: Constitute an Architecture Review Board Why? Consistency Power to  constitute & dissolve Task Forces  Add or waive requirements for approving changes to the spec Tasked with verifying requirements are met  e.g. verifying implementations exist Create Unique Document ID#’s Board Membership and Tenure Terms?

16. Change #2: Create a Staged Specification Process Level & Scope Idea:  Inside the taskforce Draft:  Suitable for implementations Candidate:  Suitable for internal Apps Final:  Suitable for Tutorial & Outreach  Bumps the CCA specification # Transition Criteria Simple Vote within Task Force Approval by Fwks & Tools groups, with 2 implementations Test cases, documentation, Forum- wide approval Why? Ideas aren’t born mature

17. Change #1: Post the SIDL specifications on the Web!!! Why? Transparency CCA specification (draft & above) publicly posted on cca-forum.org Devise some numbering/URL scheme  www.cca-forum.org/spec/final/cca-0.8.8.sidl www.cca-forum.org/spec/final/cca-0.8.8.sidl  www.cca-forum.org/spec/candidate/EventServices-0.9.sidl www.cca-forum.org/spec/candidate/EventServices-0.9.sidl

18. Has Gary Gone off the Deep End? These changes sound like a lot of formalisms. Some formalisms are inevitable as CCA grows in people, and matures in mission. I’ve tried to stick to ones that fit existing structure and add accountability, transparency, and consistency Excessive informality is cliquish to newcomers, inhibits growth of the Forum beyond a certain level

19. How to proceed? 1.Verify agreement in principle from the floor 2.Discuss implementation details on the floor 3.Gary will integrate responses and a.(optional) repeat 2&3 in BOF tomorrow b.propose these reforms on Quorum for vote 4.If passed, will constitute Architecture Review Board first 5.ARB will likely constitute EventServices Task Force with S. Parker as chair very soon thereafter.