2.1 Please describe the proposed Specification:

In addition, the Executive Committee Members' Guide, which
currently has an "unofficial" status, will be formalized
and published as the EC Standing Rules, and both documents
will be cleaned up and clarified where necessary.

This JSR (JCP.next JSR1) is intended to be delivered
within approximately six months. The Expert Group will therefore
focus on items that have broad consensus and that are relatively
simple to implement. More complex changes - including any that
require modifications to the JSPA - will be deferred to a follow-on
JSR (JCP.next JSR2) which will be filed shortly after this
JSR.

During the execution of the JSR the Spec Lead and Expert Group may
decide to add additional items. In the interests of completing this
JSR within the target time-frame it is also possible that some items
will be deferred to the follow-on JSR.

When completed the resulting JCP Process Document will apply to
all new JSRs commenced after the completion of this JSR and to future
Maintenance Releases of existing JSRs. The Executive Committee
intends to strongly encourage - though it cannot require - that they
also be adopted by in-progress JSRs.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This JSR will address all Java platform editions.

2.4 Should this JSR be voted on by both Executive Committees?

Yes, as required by the JCP's rules.

2.5 What need of the Java community will be addressed by the proposed specification?

The specific examples discussed below are intended to provide
examples of the kind of changes the Expert Group will consider. They
should therefore be interpreted as goals rather than commitments.

2.5.1 Transparency

Expert Group transparency

This JSR will further increase transparency of Expert Group (EG)
operations by mandating certain practices that are currently merely
recommended (for example requiring all Expert Group business to be
carried out on public mailing lists, requiring issues and comments to
be tracked through a publicly viewable issue-tracking mechanism, and
requiring EGs to respond publicly to all comments.)

Executive Committee transparency

The JSR will increase transparency of Executive Committee (EC)
operations by formalizing procedures that are currently undocumented
(for example, the legal review of proposed licensing terms,) or where
the documentation is not available publicly (for example, the
non-normative and private EC Members' Guide will be
incorporated into a public normative EC Standing Rules
document.)

Election transparency

The Expert Group will explore ways to make the annual election
process more transparent, by encouraging Executive Committee and JCP
membership participation in the nomination process, and by ensuring
that the voting membership has the greatest possible opportunity to
"meet the candidates."

License transparency

The existing process reqiures that Spec Leads disclose
Specification, RI, and TCK terms in advance. This requirement will be
revised to ensure that changes to these terms can be tracked over
time. (The Change Log produced during Maintenance Reviews,
which currently specifies only changes to the Specification, will be
expanded to include changes to the license terms - and also changes
to the RI and TCK where applicable.) Additionally, the language will
be revised to make it clear that licenses originally offered may not
later be withdrawn (though additional licenses may be also offered.)

TCK transparency

Currently the results of the TCK testing process are often not
disclosed to the public. The EG will explore ways to increase
transparency in this area, for example by publishing lists of
compatible implementations on jcp.org and by removing any barriers to
the disclosure of test results by licensees to their customers.

IP flow transparency

Because many Expert Groups already carry out their work in a
transparent manner, and because all EGs will be required to do so in
the future, it is important that any legal Terms of Use
associated with collaboration software that EGs use in the course of
their work be verified as compatible with the JSPA. This JSR will
require the disclosure and legal review of such Terms of Use.

2.5.2 Participation

The JSR will make a variety of changes to ensure broad
participation in the activities of the Executive Committees and
Expert Groups. The EG will explore way to enable the membership of
the organization to participate in the activities of the ECs through
public teleconferences, meetings, email aliases, and discussion
forums. The process of recruiting Expert Group members will be made
more public to ensure that all applications are fairly considered. In
order to ensure that Spec Leads and EG members perform their duties
responsibly, the processes for replacing those who do not will be
improved. Similarly, Executive Committee members will be encouraged
to attend meetings and to vote on JSRs by the application of
penalties on those who fail in their duties.

2.5.3 Agility

The JSR will propose changes to improve the speed with which JSRs
can be moved through the process, primarily by the imposition of
time-outs for inactive or slow-moving JSRs. (The procedures discussed
in the Participation section above will also help in this
area.)

The Maintenance process will be improved by aligning it
more closely with the Final Release process and by changes
to ensure that updated Specifications, RIs, and TCKs are published
promptly.

2.5.4 Governance

Recognizing that Java is a single platform, the Expert Group will
explore changes that would facilitate merging the two Executive
Committees into one in the follow-on JSR (JCP.next JSR2.)

2.6 Why isn't this need met by existing specifications?

See above.

2.7 Please give a short description of the underlying technology or technologies:

Not applicable.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

Not applicable.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

Not applicable.

2.10 Are there any security issues that cannot be addressed by the current security model?

Not applicable.

2.11 Are there any internationalization or localization issues?

Not applicable.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

This JSR will produce a new version of the JCP Process document
and the Executive Committee Members' Guide, therefore replacing the
current versions of these documents.

2.13 Please describe the anticipated schedule for the development of this
specification.

JSR submittal: May 2011Early Draft
Review: July 2011Public Draft Review: August
2011Proposed Final Draft: September 2011 Final
Approval Ballot: October 2011

This is a deliberately aggressive schedule which may need to be
amended as the JSR progresses. However, the Spec Lead intends to
defer lengthy or difficult items to a follow-on JSR in order to
enable this JSR to be completed rapidly. The estimated date for the
completion of the follow-on JSR is May 2012.

2.14 Please describe the anticipated working model for the Expert Group working on developing this
specification.

The two ECs will together form the Expert Group for this JSR. The
Chair of the organization will act as Spec Lead and the PMO will
provide administrative assistance as necessary. In addition to
working on this JSR during regularly-scheduled EC meetings,
additional teleconferences will be scheduled on a weekly or bi-weekly
basis. Since it is likely that only a subset of EC members will
attend these additional meetings, their results will be reported back
to the full Executive Committees for review and approval. In addition
to teleconferences and face-to-face meetings, the Expert Group will
make extensive use of email and collaborative tools such as Wikis.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The joint ECs will form the Expert Group for this JSR and will
have therefore full insight in the progress of this JSR. All
discussions will be carried out or reported on a public mailing list,
and all materials generated by the EG will be published. The
community will be encouraged to provide feedback through a public
alias, and formal comments will be logged and publicly responded to. See this JSR's java.net project for details.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Not applicable.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

Not applicable.

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Not applicable.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.