Tuesday Oct 18, 2011

No more smoke-filled rooms

Smoke-filled roomThe Executive Committees of the JCP have been busy for the past several months on some significant revisions to the Process. These changes have been specified through JSR 348: Towards a new version of the Java Community Process, which has just completed the Final Approval Ballot process and has been overwhelmingly approved.

The principal goals of this JSR have been to improve transparency and to make it easier for people to participate. I summarized the details in a recent post, and of course you can now download the new versions of the Process Document and EC Standing Rules from the JSR's page at jcp.org.

The most significant changes concern the ways in which Expert Groups do their work. Although in the past many JSRs were run in an open and transparent manner this is now a requirement. Expert Groups must conduct all of their business through a public email alias or similar mechanism, must use a public issue-tracking mechanism to record and track their progress, and must publish their working documents for all to see. All future JSRs will be required to operate in this manner, and we expect most JSRs that are already in progress to voluntarily adopt the new requirements.

We hope that these changes will make it easier for people - even non-members - to participate in our work. Please take advantage of this opportunity and help us to ensure that future JSRs will achieve the broadest possible consensus.

Friday Aug 12, 2011

Using the Process to change the Process


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

Signing the ConstitutionThe 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!


Patrick Curran


« July 2016