Using the Process to change the Process
By Patrick Curran on Aug 12, 2011
There are two documents that define how the JCP is organized and how it does its work: the Java Specification Participation Agreement (JSPA), which is a legal contract between members and Oracle, addressing Intellectual Property grants and the terms under which the Spec, RI, and TCK should be licensed, and the Process Document, which defines the governance of the organization and the processes that we use to develop and maintain JSRs.
Since we have a well-defined process for developing technical specifications, it seemed sensible to use it to modify these constitutional documents rather than to create something new. So, we use the Process to modify the Process, by filing a special JSR. As Chair of the JCP I am the Spec Lead for these Process JSRs, while the Executive Committee members form the Expert Group.
One such JSR is in progress now: JSR 348: Towards a new version of the Java Community was filed in May and has just gone into Public Review. This JSR is focusing on relatively simple changes that can be implemented within about six months (we want to complete it before this year's JCP elections in October.) For this reason it focuses only on changes to the Process Document and to a new ancillary document that outlines the Standing Rules for the operation of the ECs.
There will be two follow-on JSRs: the first will merge the two ECs into one for greater efficiency and to encourage synergies between the Java platforms, and the second will implement more complex changes, including any that require modifying the JSPA. (Since the JSPA is a legal contract, changing it is a Big Deal, requiring input from Real Lawyers.)
The principal themes of JSR 348 are Transparency, Participation, and Agility.
The Transparency changes will require that Expert Groups conduct all of their business in public, using a public mailing-list and a public issue-tracker. Similarly, the Executive Committee, which already publishes all of its minutes and meeting materials (see here) will be required to hold some public meetings and to create a public mailing list for community feedback. Finally, there will also be some additional transparency requirements around licensing, TCK testing, and the election process.
The Participation changes will require that requests to join Expert Groups are published, will define formal processes for dealing with situations where Expert Group members or Spec Leads are not performing their duties, and will define penalties for Executive Committee members who do not attend meetings.
In the Agility area we intend to introduce time-outs for JSRs, requiring them to reach various stages of the process within a defined time or face the possibility of being shut down. We will also clarify the Final Release and Maintenance processes to ensure that Specifications, RIs, and TCKs are posted promptly.
Since JSR 348 will require that all Expert Groups conduct their work in the open, we thought we should set an example with this JSR. So, we've created a public java.net project where you can follow and participate in our work. All of our deliberations are copied to a public Observer Alias, we're tracking our issues on a public Issue Tracker, and all our documents (meeting agendas and minutes, task lists, working drafts) are published in our Document Archive.
We want your input, particularly now, during the Public Review period. Please visit us on java.net where you can learn how to participate. Subscribe to the Observers alias, review our issues, browse our meeting minutes, download the drafts of our new documents, and provide your feedback through the Issue Tracker.
See you there!