December 16 , 2010, 8:00 am - 10:00 am Pacific time
The following EC members had previously volunteered to join the Working Group.
The following members attended this meeting of the WG.
We agreed to start by meeting weekly, for an hour. We may reduce the frequency if attendance is too low. We'll hold our next meeting during the first week in January.
We recognized that work would need to be carried on between meetings - people would be given "assignments" and would be asked to report back.
We agreed to meet face-to-face after each of the EC f2f meetings. We discussed the possibility of additional face-to-face meetings of the WG. Patrick agreed to hold a Doodle poll to figure out whether, when, and where we could meet in March.
Patrick noted that we will need legal advice for at least some of our work. He had asked Oracle's lawyer to join the group but was told that this wouldn't be possible until permission had been obtained from the lawyers of all other EC members. (This is an ethical issue - an Oracle attorney cannot represent or provide advice to others without the consent of their attorneys.) We discussed possible ways to work around this (perhaps hiring an independent counsel.) We agreed that in practice we will work the business issues and then everyone will pass this off for their own lawyers to review.
NOTE: after the meeting Patrick had additional discussions with Oracle's lawyers. Hiring independent counsel really isn't practical, so before the Oracle lawyer can participate we really will need to talk to everyone else's lawyer. He will follow up by email. (In the meantime, we can certainly continue to work.)
We need to provide a Transparency Plan with the JSR submission, to explain how we will involve the community, and allow them to see and comment on our work. Patrick explained that he wanted to use the infrastructure provided by jcp.org (the aliases, bulletin boards, etc.) for this purpose in order to gain some practical experience of how well this serves the needs of Spec Leads.
The process is started by filing a JSR. Once the JSR is posted a Click here to join this Expert Group link is created on the JSR's main page on jcp.org. Members of the Working Group (and other EC members who want to closely watch what we do) will need to register as members of the "Expert Group" through this mechanism. (Because the true Expert Group is composed of the entire membership of the ECs we will modify the text on the JSR's page to explain the situation.
Three email aliases will then be automatically generated:
After some discussion we decided to use the jsr-xxx-eg alias for administrative and (very occasional) private discussions and the jsr-xxx-observer alias for everything else. This will mean that anyone who wishes to will be able to read about and comment on our work. Until these aliases are created Patrick will circulate minutes and materials to the entire EC alias. Anything circulated in this manner will later be archived on jcp.org.
In addition, we will use either the file-upload mechanisms provided by jcp.org (there are two: one that's private to EG members and one that's visible to the public) or preferably a Wiki to publish documents and works in progress. (We can't use a Wiki until some configuration changes are made to prevent random visitors to jcp.org - those who aren't registered - from spamming us by writing to the Wiki. These changes are in the PMO's queue.)
Finally, we will request that the PMO set us up with a Bugzilla instance that we can use to formally log comments on our documents.
These transparency proposals (and indeed all decisions made at this WG meeting) should be approved by the full EC at its next meeting.
Patrick explained that it would be logistically easier to withdraw JSR 306 (the last JCP process JSR) than to modify it, because of the changes in EC membership that have taken place since it was filed. He promised to "recycle" any useful material that was developed while that JSR was active. The plan is to file two new JSRs that will be worked on simultaneously. The first will focus on "low-hanging fruit" (changes that can be made relatively easily.) In practice this probably excludes anything that would require changing the JSPA. The second JSR will tackle more complex issues, including JSR changes.
In later discussion between Patrick and members of the PMO it was pointed out that because we encourage existing members to "upgrade" to a new version of the JSPA (we cannot force them to) it would be impractical to make two revisions in a short period of time. Therefore JCP.next will necessarily have to be restricted to Process Document changes while JCP.next++ will introduce JSPA changes as well as Process Document changes.
We decided that Oracle needs to be represented on the Working Group so that members of the PMO or the Chair are not put in the difficult position of speaking for Oracle's business interests. (We recognized that Oracle will have a significant say in the kind of changes we introduce.) Patrick promised to speak to Don Deutsch about this.
In addition to the items in the JCP.next presentation the following items have been suggested for inclusion on our todo list:
We will aim to complete the first JSR by July 2011 and the second by early 2012.