About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
JCP.next JSR1 list: April 12 2011
JCP.next JSR1 list of proposed changes
Updated April 12 2011
Documents to be modified
- The JSPA
- The Process Document
- 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
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.
- 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.
|
