JCP.next JSR1 list of proposed changes

Updated April 12 2011

Documents to be modified

• The JSPA
  • Normative
• The Process Document
  • Normative
• The EC Members' Guide
  • Create a normative EC Standing Rules document from Appendix A of the Process Document and the currently non-normative EC Members Guide.
  • Reference this from Process Doc.
    • Meeting schedules, quorum requirements.
    • Voting procedures.
    • Publish EC meeting agenda in advance.
    • Specify whether agenda items are for discussion or for action.
• The Spec Lead Guide
  • Non-normative: referenced from Process Document

Categories

• Transparency
• Participation
• Agility
• IP flow
• Cleanup

Transparency

Expert Group transparency

• Draft language required for Process Document:
  • All significant business must be carried out on public mailing lists.
    • EG-private mailing list may be maintained for administrative matters.
  • Issues must be tracked through a publicly viewable issue tracking mechanism.
  • Expert Groups must respond publicly to all comments before JSRs can move to the next stage.
    • We have language requiring comments to be published, but not requiring responses - this must be tightened up.
• Given the existing structure of the document this new language wouldn't easily fit anywhere.
• Add Section 0/General Procedures that apply to all of the subsequently-described stages, to avoid duplication.

Executive Committee transparency

• Draft language required for EC Standing Rules:
  • Add semi-annual EC teleconferences that all JCP members are free to attend and where the agenda chosen from topics suggested by the membership.
  • Hold an annual open meeting at JavaOne.
  • Create a public alias (with archive) for members to provide feedback to the ECs.
• Draft language required for Process Document changes:
  • Need some language to address PMO/Oracle Legal review of license terms (currently Undocumented
  • Recommendation:
    • Oracle legal drafts an opinion - presents to EC before the appropriate vote.
    • What if the license is in clear violation (eg, Apache license for Spec license) and ECs vote to approve this?
      • We'll face that problem if/when it occurs.

License transparency

• Require that when the license terms associated with a JSR are significantly changed from the previous release, this is explicitly called out.
  • Recommendation - in the Process Document change:
    • definition - Change Log: An area accessible from the Spec Page that lists all changes made to the Specification after Final Release. There are three sections: PROPOSED (changes not yet made to the Specification), ACCEPTED (changes made), and DEFERRED (change items to be considered in a new JSR).
  • To:
  • definition - Change Log: An area accessible from the Spec Page that lists all changes made to the Specification and Licenses after Final Release. There are four sections: PROPOSED (changes not yet made to the Specification), ACCEPTED (changes made to the Specification), DEFERRED (changes to be considered in a new JSR) and LICENSING (changes to licensing terms.)
• We should also require change logs for the RI and TCK.
• All approved licenses must be offered "for ever." New (modified) licenses may also be offered subsequently.
• Note also that strictly speaking the change log does not list all changes "after Final Release" but only those since the previous release. We should therefore change "after Final Release" to "since the previous release."
  

TCK transparency

• Draft language required for General Requirements section of the Process Document ( Patrick TODO):
  • Recommendations
    • Publish lists of compatible implementations so users can see who's compatible and (by implication) who's not.
      • Spec Leads must submit to the PMO (quarterly, and at every Maintenance Release) a list of all devices/platforms that have been certified as compatible.
        • The PMO will publish these lists (and will publicise their existence.)
    • Emphasize the value of compatibility & the brand and the risks of using incompatible implementations.
      • This is a marketing issue - cannot be solved by Process Doc change.
    • TCK documentation must be publicly available.
      • TCK User's Guide must include Compatibility Requirements.
  • Non-recommendations (reconsider these for JSR2)
  • Do not publish lists of incompatible implementations.
    • This is legally risky, and unnecessary (the list of incompatible implementations can be derived from the list of compatible implementations.)
  • Do not (yet) publish information about optional features that are implemented.
    • This is too difficult to implement (what level of granularity would we choose?)
  • Do not strengthen the TCK quality requirements (except for requiring Compatibility Requirements)
    • Better to police what we have now.
  • Do not require more formal reporting requirements for conformance claims.
    • Would require generalizing compatibility requirements.
  • TBD
    • Permit and encourage the discussion of individual TCK test results.
      • We permit this now for OpenJDK testing - any value to generalizing to commercial testing?

Participation

• Related, but not requiring Process Document change:
  • Simple Terms Of Use for non-members who wish to comment on specs in public forums.
    • Oracle-legal have drafted a TOU document for java.net (the "default" collaboration platform.)
      • It's still long and potentially intimidating, but less so than the JSPA.
      • This will be ready for JSR1 but nowhere to reference it until we modify the JSPA itself.
• Draft language required for Process Document:
  • No barriers to participation in Expert Groups.
    • Requests to join EGs and the Spec Lead's responses, and decisions to remove or replace EG members, must be made in public.
  • 2.1.3 Uncooperative or Unresponsive Expert Group members.
    • 2/3 majority of the EG can vote out an EG member (the company, or the person representing that company.)
      • EG members should make a reasonable effort to resolve any such issues among themselves, for example by asking the member company to replace the representative.
        • NOTE: this paragraph is buggy - switches to Spec Lead in the middle. Duplicate it so we have one section dealing with Spec Leads and one with EG members..
  • 2.1.3a Uncooperative, Unresponsive, or Inactive Spec Leads
    • 2/3 of EG can vote to refer a problem to the PMO. The PMO may ask the Spec Lead organization to replace the Spec Lead (individual) or to seek an alternative Spec Lead.
      • If seeking an alternative Spec Lead, make sure this syncs with the Transfer Ballot language.
  • Individual members' votes - how to avoid ballot-stuffing?
    • Recommendation:
      • Change this language in the Process Doc: "All JCP Members are eligible to vote in a ratification ballot subject to the provision that if a Member has majority-ownership of one or more other Members, then that group of Members will collectively have 1 vote." to “...has majority-ownership of or is the employer of one or more other Members...”
        • NOTE: this doesn't deal with the JUG/JUG-member relationship. We think that's OK.
        • It might be difficult for the PMO to enforce this in practice, but we would have the authority to do so if necessary or to take corrective action after the fact.
• Draft language required for EC Standing Rules:
  • Penalties for EC members who do not attend meetings..
    • Miss two meetings in a row - lose voting privileges until you have attended two in a row.
      • Non-voting members don't count towards quorum.
        • Make sure we distinguish between voting and non-voting members elsewhere in the document.
      • EC may waive this penalty under exceptional circumstances.
    • Miss 6 meetings in a row (or in any 12-month period? or 6 out of any consecutive 10?) - lose your seat.
      • EC may waive this penalty under exceptional circumstances.

Agility

• We have draft language for Process Document:
  • Time-outs for inactive JSRs.
    • See JSR Renewal Ballot suggestion from JSR 306.
      • Reduce the numbers: 12 months to Early Draft, 2 years to Public Draft Review, 3 years to Final Release.
      • Make sure this is sync'd with the Dormant JSR language.
    • Later (JSR2) make sure we've covered issues around withdrawing contributions.
• Draft language required for Process Document:
  • Clarify the Maintenance process
    • Spec Leads want the EG to persist after Final Release. The Process Doc states that the EG must disband.
    • This was presumably to ensure that IP vests in a clean manner. Need legal confirmation
    • Recommendation:
      • The Expert Group must shut down and be re-formed at each release.
        • Spec-lead will typically recruit from the previous EG, perhaps adding some new members.
      • We need to maintain the history of which members have been on the EG between its most recent re-formation and the next release.
        • These are the members who have potentially contributed IP.
      • Need legal check on this, but hopefully we can complete this for JSR1.
• Clean up Maintenance Release requirements. Currently there's no absolute requirement for the Maintenance Lead to actually deliver an updated spec, RI, and TCK.
  • The process simply says "the maintenance changes will be considered final when the RI and TCK are synchronized with the Specification."
  • We should require a formal Maintenance Release just as we do a Final Release.
    • Maintenance Review: we get a change log, an updated (supposedly-final) Spec, an updated RI and TCK if necessary (or a statement explaining why these aren't necessary.)
    • We post these for review.
    • At the end of the review period, if no objections by EC, approval is automatic.
    • If there are objections, an exception ballot is held.
• Alternatively, should we get rid of the exception ballot process and always require an approval ballot, just as we do with Final Releases?
  • Recommendation: yes
    • We could then harmonize the two processes (JSR development/release and Maintenance)
• Clarify requirements for RI and TCK to be posted within x weeks of Final Release and Maintenance Release.
  • We post the Spec, but never the RI and TCK. We get a URL.
  • When we get a working URL the state becomes "final" - IP vests at this point.
  • What if the URL is later broken - becomes non-functional?
  • PMO gives Spec/Maintenance lead 30 days to fix.
  • If no fix, revert to Proposed Final Draft or Maintenance Review stage; must complete the process again.
    

IP flow

• Review, clarify, expand the brief reference to anti-trust compliance in the Process Doc.
  • Eduardo?
• Draft language required for Process Document:
  • Clarify Terms of Use for collaboration software used by Expert Groups
    • Should ensure sufficient IP grants, but not impose requirements more strict than the JSPA
    • Recommendation:
      • During the JSR submission process the Spec lead tells the PMO what collab software will be used.
      • Oracle legal reviews the Terms Of Use and reports to the EC.
      • EC approves, or requires an alternative.
        • If OK - add to approved list. If not, look elsewhere
      • Must deal with possible changes to terms of use over time.
        • May need to review each time, even if previously reviewed.
      • TODO: Patrick to talk to Oracle Legal about this.
      • We may need to delay to JSR2 because of the legal effort required.

Cleanup

• Draft language required for Process Document:
  • Remove Process Doc section 1.1.4 J2ME building blocks
  • Correct typos and errors in Process Document.
  • Remove the ambiguity of the term Spec Lead in the Process Doc (sometimes it refers to the Member and sometimes to the person representing the Member and leading the EG.)
    • See Wayne Carr document for explanation.

Procedural issues

• When will the changes in the Process Document take effect?
  • The JSPA currently prohibits us from applying Process Document changes to JSRs that are in progress:
    • "The Process is described on the JCP Web Site (at http:/jcp.org), and may be revised from time to time in accordance with terms set forth in the Process document, provided that no such revisions shall apply to any JSR that has already been approved for development."
  • Recommendation:
    • Modify this language (in the JSPA - JSR2) to give us the power to apply Process Doc changes to in-flight JSRs.
      • This wouldn't require us to do so, just make it possible if we wish.
    • The language should specify that at the EC's discretion the requirements of the Process Document will apply to all JSRs when they next make a formal state-change through the process
    • For in-flight JSRs, encourage Spec Leads to voluntarily upgrade to the new version of the Process.
  • Because JSR2 won't be completed for at least another year, we will need to apply moral pressure to in-flight JSRs to adopt the new procedures.

Next steps

• Draft the JSR proposal documents
  • Circulate for review by EC members with the goal of holding an EC discussion during the Seoul f2f and filing the JSRs immediately afterwards.
• Patrick and Eduardo to produce new drafts of the Process Document and the EC Standing Rules.
• Identify and formally publish the backup documents (drafts, etc.)
• Go public - blogs, speaking - encourage member feedback.