JCP version 2.6 (JSR 215) Open for Review--Please Comment
By Heather VanCura on May 05, 2009
JSR 215, JCP version 2.6, is open for Maintenance Review until 25 May. As previously mentioned, the JCP Executive Committee (as the Expert Group) and the JCP Chair (as the Spec Lead) have been working and discussing these changes for many months. Once accepted, JCP version 2.7 will take effect in June 2009. All community spec leads, expert group members, participants, observers, etc are encouraged to review and comment on the proposed maintenance changes. Send comments to jsr-215-comments at jcp dot org.
You can use the following list to track the changes--it indicates where in the Process document there are edits for each proposal. This is intended to be read along with the edited version of the Process document (see link above).
1. Transparency – JSR EGs must publish and respond to public comments and EC sees it before EC Ballots.
Section 1.2 – there already is a requirement for making JSR initiation comments publicly available and also available to the EC (it's currently ignored). Changed text to allow consolidating similar comments.
Section 2.3 – add words to make same requirement for making comments public in Early Draft
Review as already required in JSR Initiation. Added wording to require publicly viewable response before moving to next stage (Public Draft).
Section 3.1 – add words to make same requirement for making comments public in Public Draft
Review as already required in JSR Initiation. Added wording to require publicly viewable response before moving to next stage (Proposed Final Draft).
2. Transparency - Require publication of full public spec, TCK and RI licenses starting at JSR initiation Section 1.2.1 already says “The Spec Lead will provide the EC with the terms under which the RI and TCK will be licensed no later than the start of JSR Review.” (currently ignored – spec leads often provide a sketch of some terms and sometimes virtually no useful information). Added clarification to require publicly viewable licenses.
Section 2.2.1 same wording as 1.2.1 in section on updates to the information at later stages.
3. Transparency – JSR EGs must publicly state what transparency techniques are used in JSR EG on public JSR status page.
Section 2.2.1 remove words “are free to operate Expert Groups in whatever style they feel is most appropriate”. There are restrictions in the Process doc on how the EGs operate – not useful or accurate to have a statement like this – they can operate according to what the Process document says.
Section 2.2.1 added words requiring that JSR EG must publicly state which transparency techniques are used in the JSR EG. It already says “the EC members expect Spec Leads to carefully choose which tools are best for their Expert Groups and commit to using them” This clarifies that to provide specific information that must be provided about what methods are being used.
4. Transparency – JSR EGs discouraged from using JCP Confidential information in their drafts or final output.
Section 2.1.1 added words to discourage use of information that falls under the JCP Confidential
definition in any EG drafts or output. Using confidential information in EGs prevents use of the other transparency methods. e.g. read only mail lists for EG work, open source groups able to keep up with drafts in implementations.
5. Agility - Clarify process to remove uncooperative spec lead to deal with issues like bankruptcy or other issues that stall the JSR.
Section 2.1.3 added words to allow changing to different JCP Member, not just different person within the same JCP Member organization. The current wording says “the EC may direct the PMO to ask the Member who provided the Spec Lead to provide a replacement”. What does that mean when the Member is an individual? What does it mean when the Member is in bankruptcy and has no ability to act on it? What does it mean when the objectionable behavior from the Spec Lead is a reflection of the lack of interest of the Member or where the Spec Lead wants to stall the JSR?
6. Agility - Clarify role of EG members during Maintenance phase.
Section 3.5 – added words to clarify that Maintenance Lead can call upon members of the EG for aid in the Maintenance role. Did not remove words “and disbands”. The change reflects what actually is the practice now without removing the words. The EG disbands but the Maintenance Lead can continue to call on those members for help (e.g. in preparing a new JSR for a new EG or for Maintenance Reviews).
7. Agility – Allow EC Members to call for a Maintenance Review Item Exception Ballot up until the end of the Maintenance Review. Current rules require any EC objections to be stated more than 7 days before the end of the review – so the last 7 days of the current review are meaningless and reviews can be functionally as short as 23 days.
Section 4.2.2 added words to move any Item Exception Ballot until after the end of the Maintenance Review. The way it is now if there is a 30 day Maintenance Review, the EC has to raise any objections more than 7 days before the end of the review. So the review time effectively is only 23 days. The easy fix for this is to move the very rare Item Exception Ballots to after the end of the regular review period. This has no impact on JSRs that don't have objections from the EC and allows the complete 30 day review in the by far most common case. This doesn't slow down the vast majority of Maintenance Reviews where formal objections are not raised by an EC Member.
8. Agility - Require that an updated Spec be posted after a Maintenance Review completes successfully.
Section 4.2.2 added words to require posting an updated spec after changes are approved in a
Maintenance Review. There have been JSRs where updated specs are not published after successful Maintenance Reviews. Implementers are expected to read the spec, knowing some of it may be replaced by Maintenance changes and then read each change list in each Maintenance Review and try to figure out what the Spec should actually say. That should not be allowed. If the Spec Lead doesn't know how the Spec changes to the extent that they can update the spec, the change should not be permitted.
9. Agility – Change deadline for requiring special election for EC vacancy to avoid special election occurring too close before the regular election. The current rules call for a special election to fill a vacant EC seat if the vacancy occurs more than 3 months before the next regular election, but given how long it takes to prepare and conduct elections, that could lead to a special election very soon before a regular election, causing confusion. Make that a longer time.
Section A.4.2 changed so no special election if ratified seat is vacated within 6 months of regular
election. With the current 3 months a special election could happen right before the regular election (given the delays in starting and running an election).
Section A.4.3 same change for openly elected EC seat. See immediately above.
10. Transparency – Ensure transparency in Maintenance process by publishing requests for
maintenance changes publicly (e.g on an archived mail list). When a Maintenance Review occurs both these requests for changes and the disposition must be publicly viewable (e.g. deferred with brief comment why, rejected, with brief comment why, included in Maintenance Review).
Section 4.2 Added text requiring a publicly archived Maintenance email feedback address for public comments.
Section 4.2.1 Added text requiring summarizing comments with disposition and making that public along with change log when Maintenance Review starts.
11. Agility - Final Release must be published promptly after Final Ballot Approval. (one JSR was approved nearly 5 years ago and still has not published a final spec.)
Section 3.4. changed to require all materials needed to publish final release are given to the PMO
before the start of the Final Ballot. If they don't have this material, they are not ready for Final Ballot. Otherwise, what is the EC approving?
12. Agility - Deal with dormant JSRs that are no longer functioning.
Section 2.1.3 changed to say that if group no longer functioning at all EC can vote to replace spec lead (if group not functional enough to vote itself). The new spec lead can either continue or decide to terminate the group.
13. Transparency - Include URL for additional licensing obligations for EG members from 3rd party hosting services (for mail lists, code repositories) in Initial JSR Request. Update with EC if changed. Some 3rd party services require licensing that is different than JSPA (e.g. host site gets patent grants).
Section 1.2.1 – added text to do the above
14. Elections - Elections voting takes place over a period of 6 weeks from when voting starts to when it completes, making it difficult to focus JCP Member attention on the election process. Change timing of ratified election and open election to improve participation.
Section A.4.3 – rearranged wording to make it a one word change to determine the relative start times of the ratified and open elections. Changed to make ratified and open election voting in same 2 week period. Also requirement to notify on JCP website 4 weeks before start of voting what materials are needed to run in election.
15. Duties of EC - Clarify that duties of the EC in providing guidance to the PMO includes developing and publishing white papers, reports or comments if either one or both of the EC's finds that appropriate.
Section A.3 Duties and Responsibilities item “Provide Guidance to the PMO” - added a couple of sentences. Provide guidance to the PMO <addition>.and JCP Community to promote the
efficient operations of the organization and to guide the evolution of Java platforms and
technologies. Such guidance may be provided by mechanisms such as publishing white
papers, reports, or comments as the EC deems appropriate to express the opinions of one or
both Executive Committees.</addition>.