[JSR348-156] platform comaptibility requirements for new specs unclear Created: 29/Jan/13  Updated: 29/Jan/13

Status: Open
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Bill Shannon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The process document says:

2.1.3 PROFILES AND API SPECIFICATIONS TARGET CURRENT PLATFORM EDITIONS

All new or revised Specifications must be compatible with the most recent versions
of the targeted Platform Edition Specifications.

It's not clear what this requirement really means. Our current interpretation is
that the RI and TCK for the Specification must run on the most recent version of the
targeted platform. We do not interpret this to mean that the Specification must
use any particular feature of the most recent platform version. Use or non-use of
platform features is a decision for the expert group for the Specification. For
example, a Specification may be designed to be implementable on older versions of
the targeted platform and thus choose not to use features of the most recent platform
version.






[JSR348-153] Licensor Name Space is not formally defined Created: 01/Oct/11  Updated: 01/Oct/11  Resolved: 01/Oct/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR358-4 The JSPA contains definitions - verif... Open

 Description   

"Licensor Name Space" is used in the Process Document as a defined term but is not in the list of definitions.

This is drawn from the JSPA. Here it is:

Licensor Name Space: the public class or interface declarations whose names begin with "java", "javax", "com.sun" (or com.Your name if You are the Specification Lead) or their equivalents in any subsequent naming convention adopted by Sun.

(We should change "Sun" to "Oracle.")

I'm deferring this for now, since we really need a better mechanism for cross-referencing these definitions. Maybe we should say "the definitions in version x.y of the JSPA apply here."



 Comments   
Comment by pcurran [ 01/Oct/11 ]

Since I had to make some additional edits (cleaning up wording, etc.) I also fixed this by adding the definition from the JSPA.

Comment by pcurran [ 01/Oct/11 ]

Closing now it's resolved.





[JSR348-93] Comments on the Standing Rules from Anish Karmarkar Created: 18/Aug/11  Updated: 30/Sep/11  Resolved: 30/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All line numbers reference the "clean" PR draft



 Description   

Lines 20-21

Anish points out that it's unclear whether the 14 day limit for publishing minutes is for the approved minutes or for the preliminary draft minutes.

Good point. Two weeks is a bit tight to draw up the minutes, publish them, and get them approved. We could say they must be published and approved within three weeks. (That would still be a bit tight.)

Lines 29-31

We need to deal with the case where a JSR ballot is in progress when someone loses their voting privileges. Saying "loss of future JSR ballot and EC voting privileges" fixes this, I think. We should also clarify that once a member loses their voting privileges they cannot make motions or second.

Lines 62-63

Anish says "I don't understand lines 70-71. What is it that it is trying to say? Is it saying that JSR ballot votes/comments are to be made public before the vote closes?"

I don't understand this either. Given our new transparency requirements I think we could just delete this fuzzy statement.

Appendix B

Anish suggests referencing lines 110-111, to clarify how the majorities are calculated. Now that I think about it, we don't have a similar definition for a 2/3 majority. We might want to simplify 110-111 by simply stating that only votes cast are counted and by not defining the math used to calculate a majority.(Do we really need to define "simple majority?"

Lines `105-106 "Electronic ballot periods last 7 days except where noted otherwise in this document."
Line 128 "The duration of the ballot is 14 days"

Strictly speaking, no contradiction since we say "unless where noted otherwise" but nevertheless a bug. I think we should stick to 14 days (our current practice.)

Also, note that we need a space before "Electronic ballot periods"

Finally, note that the use of the term "electronic ballot" here is the kind of thing I was talking about in issue http://java.net/jira/browse/JSR348-57 This really should be "electronic vote."



 Comments   
Comment by pcurran [ 23/Aug/11 ]

We don't have specific suggestions for all of the issues Anish raises, but I think they're simple enough. Would you please take a stab at this and then we can review?

Thanks...

Comment by eduardo [ 08/Sep/11 ]

Regarding lines 20-21, since the text itself makes it clear that there are draft minutes to be approved at the next meeting, it would not make sense to say they must be published 3 weeks after they are taken, nor does it make sense to force the publication of preliminary minutes, so I've taken the middle road and said they must be published no later than two weeks after being approved.

Regarding "Lines 62-63 – Anish says "I don't understand lines 70-71": this is confusing, which lines are not understood? As far as I can seen, neither 62-63 nor 70-71 talk about votes, so I don't understand what's not understood, nor what I'm supposed to delete.

Regarding voting, I have replaced lines 110-111 with:
For the purpose of calculating the voting result, only the votes cast are taken into account. Thus, in the case of a vote to be decided by simple majority, if there are 15 voting members and 5 vote "yes", 4 vote "no" and 6 vote "abstain", the "no"s have it, because only 5 out of the 15 votes cast indicated "yes"; however, if 5 vote "yes", 4 vote "no" and 6 do not vote at all, the "yes"s have it, because 5 out of 9 voted "yes".

Regarding the issue of "vote" vs. "ballot" I've tried to harmonize the "Electronic Voting" section by eliminating the word "ballot" completely from it.

Comment by pcurran [ 08/Sep/11 ]

Re:

Regarding "Lines 62-63 – Anish says "I don't understand lines 70-71": this is confusing, which lines are not understood? As far as I can seen, neither 62-63 nor 70-71 talk about votes, so I don't understand what's not understood, nor what I'm supposed to delete.

Anish reviewed an earlier draft. For convenience (I thought) I figured out what the line-numbers would be in the PR draft. So, he's really talking about 62-63, which say:

"The Executive Committee shall review JSRs in a manner that provides all persons affected by a proposed Specification to have an opportunity to participate in the process."

Apart from being gramatically incorrect ("that provides ... to have") it really doesn't make a lot of sense. How can "all persons affected by a proposed Specification" participate in the process of EC reviews?

Participation is enabled by the various processes we've put in place, not by how EC members review things. So - I suggeste deleting these two lines.

Comment by pcurran [ 08/Sep/11 ]

Re:

Regarding voting, I have replaced lines 110-111 with:
For the purpose of calculating the voting result, only the votes cast are taken into account. Thus, in the case of a vote to be decided by simple majority, if there are 15 voting members and 5 vote "yes", 4 vote "no" and 6 vote "abstain", the "no"s have it, because only 5 out of the 15 votes cast indicated "yes"; however, if 5 vote "yes", 4 vote "no" and 6 do not vote at all, the "yes"s have it, because 5 out of 9 voted "yes".

I still don't think we don't need provide examples. I stand by my original suggestion that "We might want to simplify 110-111 by simply stating that only votes cast are counted and by not defining the math used to calculate a majority."

Comment by eduardo [ 08/Sep/11 ]

The last comment clarified all, and it's now all resolved and fixed

Comment by eduardo [ 08/Sep/11 ]

I closed it too quickly, and there was a "last comment" I hadn't seen yet.

Comment by eduardo [ 08/Sep/11 ]

I have (reluctantly) deleted the explanation of the effect that casting abstention votes can have on calculating the results. This is the most misunderstood issue in voting in all contexts, and you're guaranteed to get protests and escalations if you declare that one side carries the vote even if it has less votes than the other side.

Comment by pcurran [ 08/Sep/11 ]

So - let's reopen this (but mark it resolved) so we can canvas other opinions...

Comment by pcurran [ 08/Sep/11 ]

Resolved, but not reviewed

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.

Comment by pcurran [ 27/Sep/11 ]

I'd prefer it if we reverted to the original position: the only votes that count are "yes" and "no." This means that the arithmetic is easy (no weird corner-cases where the no's have it even though the yes's have more votes, because there are abstentions.)

I'm OK with "abstain" meaning that "I deliberately chose not to vote" and "not voted" meaning "I don't know whether it's Tuesday or breakfast-time," but otherwise there being no difference between these actions.

Comment by eduardo [ 28/Sep/11 ]

the way to resolve this will be to change line 113 from "For the purpose of calculating the voting result, only the votes cast are taken into account." to "For the purpose of calculating the voting result, only the "yes" and "no" votes are taken into account."

Comment by pcurran [ 29/Sep/11 ]

Change agreed at September 29 WG meeting.

Comment by eduardo [ 30/Sep/11 ]

Reopening in order to change "Incomplete" to "Fixed"





[JSR348-120] Should the JSR Review period always be four weeks, or 2-4 weeks at the option of the submitter? Created: 20/Sep/11  Updated: 30/Sep/11  Resolved: 29/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Version 2.7 defined the JSR Review period as 2-4 weeks. Our current draft specifies 4 weeks. Was this deliberate?

Bill Shannon thinks 4 weeks is too long. I think it's barely long enough, and that we certainly shouldn't be launching new JSRs with only a two-week review period. (In practice we seem to get zero input from the community before JSRs are voted on. This seems wrong to me, and we should try to fix it in future.)



 Comments   
Comment by Bill Shannon [ 20/Sep/11 ]

Getting significant input from the community would require a lot more outreach
than we're likely to do. Real input is going to come from Members who join the
Expert Group.

Remember also that, while not required, the submitter of the JSR will likely have
reached out to the major players in that space before submitting the JSR and will
have gotten and incorporated their feedback. The EC should consider whether the
list of supporters of the JSR is sufficient to indicate that that was done.

People who have done a good job of this will be anxious to get the Expert Group
started as quickly as possible.

Overlapping the JSR Review period and the JSR Approval Ballot period seems sufficient.

Comment by pcurran [ 29/Sep/11 ]

At the September 29 WG meeting we agreed:

The review period should be 2 or 4 weeks at the discretion of the submitter.

This is followed by a 2-week EC vote.

Comment by pcurran [ 29/Sep/11 ]

See last comment.

Comment by eduardo [ 29/Sep/11 ]

I have modified the definition of JSR Review to: A two- to four-week period (the length to be set at the discretion of the submitter) during which the public can review and comment on a proposed new JSR before the JSR Approval Ballot.

And I have modified JSR Approval Ballot to: A two-week EC ballot to determine if the initial JSR submission should be approved

Comment by Bill Shannon [ 30/Sep/11 ]

According to the Spec Lead Guide http://jcp.org/en/resources/guide5,
the 2 week JSR Approval Ballot starts when the JSR is posted. This
is what we've been doing for years and I don't want this to change.
Adding a 2 or 4 week delay to the start of the JSR Approval Ballot
period is unacceptable.

If the 2 week JSR Approval Ballot period can run concurrently with
a 2 week JSR Review, that's fine.

Comment by pcurran [ 30/Sep/11 ]

The Spec Lead Guide is not the final authority - it simply summarizes what the current Process Document says.

We've discussed this several times in the Working Group and agreed that we prefer the 2+2 weeks formula.

Since the majority of JSRs take well over a year to complete we didn't think the extra "burden" was significant...

Comment by eduardo [ 30/Sep/11 ]

I am closing this issue based on Patrick's comment of 30/Sep/11 05:20 AM – it can of course be reopened it dissatisfaction with its resolution continued, but if it is I would suggest that if the intention is to merge review and ballot into one, then we should just drop the concept of review, which in most contexts implies study, consideration and decision making, and just have a (2 week?) ballot period. Review and ballot at the same time makes no sense.





[JSR348-147] Give PMO ability to investigate and act on voting fraud with certain conditions Created: 21/Sep/11  Updated: 30/Sep/11  Resolved: 30/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

785-789 - See comments on 54, above (filed as JSR-348-133). I thought we agreed to eliminate this in the NJ EC meeting by agreeing to give the Chair power to investigate and act on voting fraud as long as evidence is clear and this activity is put in the public record. I do not see that in this document.

PC> Good catch. Please log an issue so we don't forget this again. If you can make specific suggestions for changes in language that would be helpful too.



 Comments   
Comment by sean_sheedy [ 21/Sep/11 ]

Related:

815-817 - strike "except that Agents of JCP Members" as we decided that the PMO would be able to deal with election fraud (see 785-789 comment above.)

PC> And see my response above.

SS> Please strike this as the power to investigate as described above eliminates the need for this.

Comment by pcurran [ 27/Sep/11 ]

I deleted "or if one or more Members are Agents of another Member" from "All JCP Members are eligible to vote in ballots for Ratified and Elected Seats subject to the provision that if a Member has majority-ownership of one or more other Members, or if one or more Members are Agents of another Member, then that group of Members shall collectively have one vote"

I added the following paragraph:

"If the PMO has reason to believe that an organization is attempting to influence the outcome of an election by encouraging its Agents to vote on its behalf it should take all necessary corrective action and then report the matter to the EC for approval."

Comment by pcurran [ 29/Sep/11 ]

OK to strike the clause.

New para should read:

"If the PMO has reason to believe that an organization is attempting to influence the outcome of an election by instructing its Agents how to vote the PMO should take all necessary corrective action and then report the matter to the EC for approval."

Approved at September 29 WG meeting.

Comment by pcurran [ 29/Sep/11 ]

See last comment

Comment by pcurran [ 29/Sep/11 ]

Fixed

Comment by pcurran [ 29/Sep/11 ]

Please make the changes suggested in the last comment.

Comment by eduardo [ 30/Sep/11 ]

I have implemented it.





[JSR348-128] any member can call for a vote to clarify "agreement". Created: 21/Sep/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Standing Rules review

100 - IMPORTANT - Strike "In the absence of general agreement". With this modifier, we're back to the question of what's "general agreement" (51% - 99%?) Any EC voting Member or the Chair may request that a vote be conducted, on any matter. Otherwise, the Chair may determine that there is "general agreement" when in fact there is not, or would not be if Members were required to put their names down on a ballot that will be published.

PC> Fair comment. Please log a separate issue.

SS> Needs discussion on whether simple or 2/3 majority determines "general agreement"? Simple majority is arguably not "general agreement."



 Comments   
Comment by pcurran [ 22/Sep/11 ]

We're not openening up the whole "consensus" issue again!

See the resolution for http://java.net/jira/browse/JSR348-111

I think that addresses this.

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-119] Should a transfer ballot include the terms on which the new owner of the JSR intends to license it? Created: 20/Sep/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Bill Shannon:

Since we require license disclosure up-front and whenever there's a state change, shouldn't we require that the proposed new owner of a JSR disclose the licensing terms before we vote in a Transfer Ballot?



 Comments   
Comment by Bill Shannon [ 20/Sep/11 ]

And in that case there's no need to include any license requirements in the process
document; the EC will evaluate the proposed license terms in the usual way, rejecting
any transfer that doesn't propose acceptable license terms.

Comment by pcurran [ 22/Sep/11 ]

The Process Doc has been modified to include this requirement.

Re Bill's comment - perhaps, but it's too late now to change all of this. Besides, we really do want to draw attention to, and to encourage, the review of license terms.

Comment by Bill Shannon [ 22/Sep/11 ]

I wasn't clear on what you did and didn't change based on my comments.
Looking at the latest document available I didn't see any mention of
license requirements related to a Transfer Ballot.

Also, section 1.2.4 references section 5.1.2, which doesn't exist.

Comment by pcurran [ 22/Sep/11 ]

Hmmm... you're right. I thought I'd taken care of this but I hadn't.

I've now modified section 5.1.1 (not 5.1.2 - I corrected the reference) to read:

"If the ML decides to discontinue his or her work at any time (including discontinuing maintenance activities or declining to take on the role of Spec Lead during a significant revision initiated by a JSR) the ML, with the assistance of the PMO, should make a reasonable effort to locate another Member who is willing to take on the task. If a replacement is identified, the PMO must initiate a Transfer Ballot within 30 days to enable EC members to approve the transfer of responsibilities. The license terms that the prospective new Maintenance Lead plans to use must be disclosed prior to the ballot. If the ballot succeeds, the new ML must assume his or her responsibilities within 30 days. If no replacement can be found, or if the Transfer Ballot fails, then the PMO shall declare the Specification to be Dormant and no further maintenance can be carried out. No further Transfer Ballots will be initiated by the PMO unless a Member volunteers as ML, in which case the PMO will again have 30 days to initiate a Transfer Ballot."

I also added a footnote to clarify that this process can also be used to seek a new Spec Lead (as opposed to Maintenance Lead.)

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-129] EC votes are just advice? problem: advice can be ignored Created: 21/Sep/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

standing rules:

104 - Strike 104-105. Advice to whom? This provides a "veto" to the party to which the "advice" is directed. For example, if the EC votes for sanctions against a spec lead to remedy an wrong raised during an appeal by an EG member, the spec lead may choose to simply ignore the "advice".

PC> The original intent was "advice to the PMO" which we've agreed should stand. However, I agree that we now have ambiguities because there are other decisions that should be binding. We need to resolve this. Please file a separate issue.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

I modified the relevant section of the Standing Rules to read:

"All EC decisions are to be understood as being advisory in nature except as they pertain to formal Ballots as defined in the Process Document."

I think this clarifies things...

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-124] private session should be agreed to by EC Created: 21/Sep/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

16 - strike "(with no need for a second)". Unusual rule, and requires EC agreement anyhow, so a second is not unreasonable, especially since it is so strongly discouraged

PC> We made this choice deliberately. If one member is unable/unwilling to process a "surprise" item that should be sufficient to postpone it. EC agreement is not needed, so I agree that the wording "the EC may agree to go into private session" is confusing and should be changed. Please log an issue with a specific suggestion for change.

SS> my first suggestion (strike need for second) stands. change "may agree" above to "must agree"



 Comments   
Comment by pcurran [ 22/Sep/11 ]

SS>

strike "(with no need for a second)". Unusual rule, and requires EC agreement anyhow, so a second is not unreasonable, especially since it is so strongly discouraged

PC> We made this choice deliberately. If one member is unable/unwilling to process a "surprise" item that should be sufficient to postpone it. EC agreement is not needed, so I agree that the wording "the EC may agree to go into private session" is confusing and should be changed. Please log an issue with a specific suggestion for change.

SS> my first suggestion (strike need for second) stands. change "may agree" above to "must agree"

That doesn't work at all, since it states that the EC must always agree to the private session.

The existing wording reflects how we've been operating for at least a couple of years, and we haven't had any serious problems. So - I'm closing this.





[JSR348-111] Clarify that agenda items marked For Action cannot be modified during the meeting, and new For Action items cannot be added Created: 19/Sep/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As agreed at the September f2f meeting, agenda items that are marked For Discussion can be added or modified during the meeting. Agenda items For Action cannot.

Clarify this at the next Working Group meeting.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

After discussion at the Working Group we agreed that items that are marked For Discussion can be added or modified during the meeting while items For Action cannot.

In order to address the apparent contradiction with the statement that anyone can call for a vote at any time we agreed to clarify that if a vote is called on something that was not marked For Action any member may request that the vote be held electronically, to allow time for consultation.

I've made several changes to the language in the Standing Rules to address this issue, and more generally to clean up the language around voting.

This needs careful review by others before we close the issue.

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-94] Spec leads can end-of-life a Specification, withdraw licenses Created: 23/Aug/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JSR348-145 RI/TCK licenses permitted that allow ... Closed

 Description   

Text in section 1.1.3 Changes to Licensing Terms and 4.3 Final Release provide an opportunity for Spec Leads to end a spec's life and withdraw the license. Instances of word "lifetime" should be removed and text reworded to indicate that once released, abiilty to implement is perpetual (unless stated in original JSR filing, perhaps.)

Also, the rule for dealing with broken links can push a JSR back to its pre-release point, where it has no license, no IP assignment, etc. (section 4.3, paragraphs 548-554) Someone wishing to withdraw a license could flip this rule around, break the link, get kicked back to a pre-release state, then refuse to ever finish the JSR.



 Comments   
Comment by pcurran [ 23/Aug/11 ]

Re "Text in section 1.1.3 Changes to Licensing Terms and 4.3 Final Release provide an opportunity for Spec Leads to end a spec's life and withdraw the license. Instances of word "lifetime" should be removed and text reworded to indicate that once released, abiilty to implement is perpetual (unless stated in original JSR filing, perhaps.)"

I agree, the use of the term "lifetime" was unfortunate, and we need to rewrite that section. I'll take a stab at it.

Re: "Also, the rule for dealing with broken links can push a JSR back to its pre-release point, where it has no license, no IP assignment, etc. (section 4.3, paragraphs 548-554) Someone wishing to withdraw a license could flip this rule around, break the link, get kicked back to a pre-release state, then refuse to ever finish the JSR."

Spec Leads can (and I suspect some do) do this today. We cannot force a Spec Lead to actually offer a license to anyone - only shine a spotlight on their obligation to do so. This new wording was introduced to deal with situations where the links to the RI and TCK (or to information on how to obtain them) are broken.

In practice I doubt that this would ever be applied - unless the Spec Lead really was AWOL, in which case at least we'd be recognizing reality rather than pretending that the RI and TCK were actually available. Rather, it will allow the PMO to put some pressure on the majority of Spec Leads who want to do the right thing.

And by the way - we explicitly say that IP previously assigned is unchanged.

Bottom-line: removing this new wording won't make anything any better than it is today. I think we should keep it.

Comment by pcurran [ 14/Sep/11 ]

Notes from discussion during the September f2f meeting.

We can't fix most of this in the Process Doc - must be fixed in JSPA since that is where the obligation to license the JSR is called out, and where there are no limits on the duration of this obligation and no statement of what should happen if the Spec Lead fails to live up to these requirements.

I will add an item to the JSR2 list.

In the meantime, I think we agreed that the only thing we can/should specify in this version of the Process Document is that if the PMO fails to obtain valid links to the RI and TCK the JSR whould be "withdrawn." (We agreed that rolling it back to a pre-Final Release stage makes no sense.)

This should be clarified at the next Working Group meeting.

Comment by pcurran [ 22/Sep/11 ]

This isn't perfect, but in the absence of JSPA changes I think it's the best we can do.

I added two new definitions:

JSR Withdrawal Ballot: An EC ballot to confirm that a completed JSR that appears to have been abandoned should be withdrawn.

Maintenance Release Withdrawal Ballot: An EC ballot to confirm that a completed Maintenance Release that appears to have been abandoned should be withdrawn.

In Section 4.3 - Final Release I modified the text relating to broken links to read:

"The Maintenance Lead must ensure that the links to the RI and TCK remain valid. If the links become broken or non-functional, the Maintenance Lead will have 30 days following notification from the PMO to correct them. If the problems are not corrected within 30 days the PMO will initiate a JSR Withdrawal Ballot (if no Maintenance Release has been completed) or a Maintenance Release Withdrawal Ballot (if a Maintenance Release has been made) to determine whether the Maintenance Lead shall be judged to have abandoned the JSR. If the ballot passes the JSR itself or the relevant Maintenance Release will be marked as withdrawn."

Need feedback on this before closing...

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-89] Make the list of Definitions more like an index, with "virtual entries" pointing to others Created: 17/Aug/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Alex Buckley suggests adding index-like entries into the list of Definitions so that related terms can be grouped together, and to help people find entries by using common terms.

He had originally suggested grouping the entries rather than having one big alphabetical list but I talked him out of that

His original suggested categories were: Roles, Ballots, Artifacts, and Process. Personally I think that all of these except Ballots are too abstract, but we can discuss that.

As for index-style entries, he suggests (as examples, there must be more):

Ballots: see JSR Review Ballot, Early Draft Review Ballot...

Member: see Java Community Process Member



 Comments   
Comment by pcurran [ 22/Sep/11 ]

I've added "index" entries for Ballot, Member, and Specification.

Suggestions for others are welcome. I'll leave this issue open until the last minute in the hope that other suggestions will be forthcoming.

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-151] minor changes Created: 21/Sep/11  Updated: 29/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc, Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

following are minor changes per email correspondence from Patrick today.

standing rules:

27/28 - redundant, and discourages use of rules when they should be used. strike last sentence and replace with "In certain situations it may be necessary and appropriate to resort to formal procedure when attempts to achieving progress via informal agreement have failed."

PC> Agreed. Please add to the Minor Changes issue.

110 - Replace "in the extreme and undesirable case, an EC member may not vote at all" with "EC Members should make every attempt to vote."

PC> Sounds reasonable to me. Please add to the Minor Changes issue.

119 - add to this, words that record not only the result, but which way each EC Member voted.

PC> Agreed, and this was the intent. Please add to the Minor Changes issue.

143 - record not just totals, but who voted which way.
and from the Process Document:
828 - results must include how each member voted.

PC> Agreed, as stated above. Please add to the Minor Changes issue.

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

220-222 Strike last sentence. It appears to discuss "private information" in a paragraph about "Confidential materials". It also encourages private operation by an EG.

PC> I'm OK with striking the sentence - it doesn't add anything significant.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

I've made all of the suggested changes, though in the case of the Standing Rules not necessarily in the words suggested by the submitter.

Comment by pcurran [ 29/Sep/11 ]

Fixed





[JSR348-126] rules around missing F2F meetings Created: 21/Sep/11  Updated: 29/Sep/11  Resolved: 29/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: eduardo
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A member can miss all face-to-face meetings and still retain voting privileges. Face to face meetings provide the heart of the EC. Some of these suggestions were made back in Seoul. These address Face to Face meetings specifically.

30-39 - It is still possible for a member to skip all F2F meetings, or call into a F2F and go on mute. Solutions:

  • explicitly allow (require?) Individual Members to provide an alternate for in-person F2F meetings (member can still call in)

PC> This has always been permitted (Doug Lea had an alternate, for example.) We can certainly "encourage." Please log an issue.

  • miss two consecutive F2F meetings, lose voting privs

SS> I believe that's two meetings, not two F2F meetings.

PC> ??? This is what the document says today.

  • miss 2/3 of F2F meetings, lose EC membership

PC> Interesting. Are you suggesting that missing 2/3 of meetings cumulatively should be sufficient to lose the seat? Sounds worth discussing. However, you'd need to specify when this kicks in. (If I'm elected in October, attend November and miss December and January have I already lost my seat?) Please log an issue if you think this is important.

SS> 2/3 of F2F meetings over two years?

(SS from original comment) Note that there is really no excuse for a corporate member to not be able to find an alternate within their corporate ranks. Harder for an individual, but still possible if individual is allowed to produce an alternate from individual JCP membership.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Got it - I missed the "f2f meetings" qualifier.

Comment by pcurran [ 29/Sep/11 ]

From Eduardo:

Most other organizations do not have penalties (losing membership) for non-participation.

Agreed at September 29 WG meeting: add some words to make it clear that individual members are encouraged to nominate alternates (just as corporate members do.)

Do not go further with additional penalties for non-attendance at f2f meetings for now.

Comment by pcurran [ 29/Sep/11 ]

See last comment.





[JSR348-56] Define the the time-out periods Created: 08/Aug/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-4 Should Maintenance Leads be obliged t... Closed

 Description   

1.3 JSR DEADLINES specifies that JSRs must reach Early Draft Review within 1 year, Public Review within 2 years, and Finale Release within 3 years, or else be subject to a JSR Renewal Ballot. Are these times appropriate, or should we shorten them?

Also, we've now decided to add a similar timeout for Maintenance Releases (not yet implemented.) The current suggestion for that is 90 days. Is that the right time?



 Comments   
Comment by keilw [ 17/Aug/11 ]

EDR somewhat sooner sounds reasonable. What value, e.g. 6 or 9 months, please suggest if you feel the same. Given the other two values all seem based on the same starting point, adjusting those to something like "Public Review within another X months/year" followed by "Final Release within another X months/year" sounds like a logical consequence.

That also better deals with situations where a PR of Final Draft has to be repeated. Whether or not the original time should be granted for that, I am not sure. We should avoid stretching it too far, but I guess steps like the Reconsideration Ballot should cover that and avoid too many failed attempts of a Public or Final Draft.

Comment by pcurran [ 26/Aug/11 ]

From Bill Shannon:

90 days is too short.

We often file MRs well in advance of the final release of the RI for the
platform. Knowing that the MR is approved and all we have to do is deliver
it helps reduce risk for the platform delivery. Being forced to submit all
MRs within 90 days of the final release, when we're trying to stabilize the
release, introduces unnecessary risk.

I greatly prefer the previous suggestion of asking the ML to specify when
the final materials for an MR will be delivered, and otherwise using the
general "JSR has failed to make progress" timeout mechanisms.

90 days between FAB and FR might be reasonable, and I understand this introduces
an asymmetry between a JSR and an MR, but it reflects our desire for MRs to be
low risk lightweight events.

Comment by pcurran [ 26/Aug/11 ]

Responding to Bill Shannon's comments...

I expected you to say that 90 days was too short - that's why I asked. I also understand the complications involved in synchronizing everything for a platform JSR.

However, I'm not sure what you mean when you say:

"I greatly prefer the previous suggestion of asking the ML to specify when the final materials for an MR will be delivered, and otherwise using the general "JSR has failed to make progress" timeout mechanisms."

If you mean that MRs intended to be included in a platform JSR should be subject to the same timeouts as the platform JSR itself then that makes sense (and is what I was planning to suggest.)

However, for MRs not intended to be included in a platform we need something other than "the timeout date is whatever the ML says it is." (We'd just get a bunch of MLs telling us that they plan to deliver before the end of the century.")

How about saying that the final release must be made within 90 days or - if the MR is to be included in a platform JSR - before the platform JSR itself is completed?"

Comment by Bill Shannon [ 26/Aug/11 ]

If the ML proposes a delivery date that's ridiculously far in the future, the
EC should vote against it.

I'd be fine if the MR->final bits and FAB->final bits timeout defaults to 30
days, as long as there's a way to request a different timeout and the EC gets
to approve it.

And I'm a bit worried if missing the timeout means you automatically go back
to the previous step, without a chance to update your timeout (e.g., because
your release slips). But on the other hand, I'm not sure I want to define
another EC ballot type to handle timeout updates!

Comment by pcurran [ 26/Aug/11 ]

The balloting process is already defined (JSR Renewal Reconsideration Ballot) though this will need to be generalized to cover Maintenance Releases as well as JSR development milestones. We wouldn't cancel a JSR or bump a MR back to the previous stage without review.

So: is this a reasonable summary of your proposal?

The ML chooses the deadline (if nothing specified, it defaults to 30 days.) This would presumably be done when the materials were submitted for the Maintenance Review. If the EC feels that the deadline is unreasonable they're free to vote 'no.' I'm sure that a deadline of "whenever the platform JSR that will include this update is shipped some time next year" would be an acceptable deadline. Alternatively, "we're planning to announce this standalone JSR update at our product show six months from now, but we want to make sure we have everything ready well in advance" would also be acceptable.

If the deadline is missed we go into the JSR Renewal Reconsideration Ballot process. In practice I'm sure the PMO would remind the ML, and would be flexible if they were told "we're a few days late, but it's coming Real Soon Now."

Comment by Bill Shannon [ 26/Aug/11 ]

Yes, that seems reasonable to me.

Comment by pcurran [ 19/Sep/11 ]

Despite lengthy discussion at the September f2f meeting we failed to reach agreement.

Some argued for much shorter time-out deadlines in order to "send a message" that we expect rapid progress. Others arguing for regular "reviews."

Patrick pointed out that we can't impose too much of a burden on the PMO, and reminded everyone that the purpose of this change is to permit us to deal with JSRs that are obviously stalled or inactive rather than to encourage people to work faster.

Needs further discussion at the next Working Group meeting.

Comment by pcurran [ 22/Sep/11 ]

As agreed during the September 21 Working Group meeting, we're going with 9 months plus 12 months plus 12 months. The relevant text now reads:

"If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay.

I'm now closing this issue

Comment by Bill Shannon [ 22/Sep/11 ]

You said 9+9+9, but you wrote 9+12+12. Which did you intend?

Comment by pcurran [ 22/Sep/11 ]

Fix typos

Comment by pcurran [ 22/Sep/11 ]

Fixed the comment that Bill referred to. I meant 9+12+12





[JSR348-113] JSR Approval Ballot - definition could be clearer Created: 19/Sep/11  Updated: 22/Sep/11  Resolved: 20/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Bill Shannon Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Our informal language sometimes causes confusion. When we talk about
"approving a JSR", sometimes we mean the initial submission and sometimes
we mean the final approval ballot.

The definition of "JSR Approval Ballot" would be clearer if it said:

The EC ballot to determine if the initial JSR submission should be approved.

"JSR Reconsideration Ballot" could be improved similarly.

Also, it would be good to connect this to the "JSR Review" definition:

A 4 week period during whichthe public can review and comment on a
proposed new JSR before the JSR Approval Ballot.



 Comments   
Comment by pcurran [ 20/Sep/11 ]

I've made the changes you suggested. Please review before I close this issue.

Comment by Bill Shannon [ 22/Sep/11 ]

Yes, it looks fine, thanks.

Comment by pcurran [ 22/Sep/11 ]

Bill's OK with this, so now I'm closing it.





[JSR348-130] abstentions are embodiment of agreement to disagree Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

standing rules

109-110 - strike "Explicit abstentions are strongly discouraged" as members may choose to step aside rather than block progress; yeah, the "minimum 5 yes votes" rule may kick in, but if it does it's a strong sign that something about what's being voted on needs to be fixed.

PC> I disagree. Abstentions are strongly discouraged. This doesn't mean they are prohibited. We could soften by striking "discouraged."

SS> why strongly discouraged? permits members to respectfully disagree without blocking the process. how about "Abstentions should be avoided, but can be used, for example, by a member who objects to that being voted on, but wishes not to stand in the way of the process."



 Comments   
Comment by pcurran [ 21/Sep/11 ]

I've modified the relevant section to read:

EC voting Members may cast three types of votes: "yes", "no" and “abstain”. Abstentions are discouraged, but may be used by members who are unwilling to support the motion but who do not wish to block further progress. “No” votes are strongly discouraged.

Note that I removed the statement that abstentions are equivalent to 'no' votes since I'm not sure that they should be. They are simply not counted, which is probably different

Eduardo: do you agree?

Comment by pcurran [ 21/Sep/11 ]

Resolved as per previous comment.

Comment by pcurran [ 22/Sep/11 ]

I don't know what I was thinking when I wrote "No votes are strongly discouraged."

This is obviously wrong. I'll delete that sentence.

Comment by pcurran [ 22/Sep/11 ]

The relevant section now reads:

EC voting members may cast three types of votes: "yes", "no" and “abstain”. Abstentions are discouraged, but may be used by members who are unwilling to support the motion but who do not wish to block further progress. Abstentions should be accompanied by comments. “No” votes should be accompanied by an explanation of the changes (if any) that would permit a change of the vote to "yes". EC members are strongly discouraged from not voting at all.

Comment by pcurran [ 22/Sep/11 ]

Made yet another change - need to record it here.

Comment by eduardo [ 22/Sep/11 ]

Patrick, the sentence "For the purpose of calculating the voting result, only the votes cast are taken into account. " which follows this paragraph (I'm assuming that sentence has not been deleted, I don't have access to the absolutely latest document with total confidence) means that your conclusion may be wrong. There is a difference between abstaining from a vote by not casting a vote, in which case your voice is not counted because you have not voiced anything, and abstaining by voting "abstain". In the latter case you have cast a vote, and you have in fact modified the result because it is counted in calculating the result. So, if by saying "They [abstentions] are simply not counted" you mean "votes not cast are not counted" you are right; if you mean "votes cast as 'I abstain' are not counted", you are wrong. Consider the case of 10 possible votes; if 5 vote yes and 5 vote no, there is a tie. If 4 vote yes and 5 vote no, and one does not vote, the no votes win. But if 4 vote yes, 5 vote no and one votes "abstain", there is a tie again, because there are only 5 no votes out of 10, and that is not a majority. So in this case the "abstain" vote counts in fact as a yes vote. The reverse case would also be true (5 yes, 4 no, 1 "abstain"), so the true statement would be that by voting "abstain" one sides against the majority amongst the yes/no votes, whichever that may be.

Comment by pcurran [ 22/Sep/11 ]

I've always assumed that we treated abstentions as equivalent to not voting...





[JSR348-125] need third party not tied up in discussions to take minutes Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

20 - someone else needs to take minutes, ideally someone dedicated to the task and not participating in discussions. the chair does not have time to take accurate minutes and be the chair

PC> Please log an issue if you feel strongly about this.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

The Chair feels quite confident that he can both chair the meetings and take accurate and helpful minutes

He therefore proposes to close this issue on the grounds that the process "works as designed."

Comment by pcurran [ 22/Sep/11 ]

See previous comment.





[JSR348-134] meta-issue: lack of enforcement creates loopholes, opportunities for misuse Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

it is lack of clarity that led to years of the EC being wrapped around the axle on Harmony. that's why I feel this is very important:

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

200 - no enforcement when the EG does not behave openly, and appeals clause provides no defined remedies. Need some penalty if EC finds that EG is not acting openly.

PC> There are many places in this document where we state requirements without explicitly stating penalties for those who fail to meet them. I think this is appropriate, otherwise the document would be much longer, and more legalistic and intimidating than it already is. The ultimate penalty is for the JSR to be voted down. Perhaps we could add some language to the early statements of transparency requirements saying that EC members should take the EG's transparency record into consideration when voting. Please log an issue.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

Added this language to section 1.1 EXPERT GROUP TRANSPARENCY

"The EC should take the Expert Group's transparency record into consideration when voting on its JSR."





[JSR348-145] RI/TCK licenses permitted that allow Ri/TCK to effectively be withdrawn by spec lead Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JSR348-94 Spec leads can end-of-life a Specific... Closed

 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

623-629 - First, the RI and TCK should have a license which permits them to be hosted anywhere on the Internet, so that they cannot possibly "disappear". Second, this allows a spec lead to effectively withdraw a JSR by witholding the RI & TCK which kicks it back to "Proposed Final Draft" which is a state prior to the IP grant. Even though the text allows existing IP grants to remain, it prevents new grants, including to someone who may have contributed, now wants a license, but can't get it.

PC> I've attempted to address this in a later draft.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

I'm closing this since it's a duplicate of http://java.net/jira/browse/JSR348-94





[JSR348-150] Seats unfilled in elections can remain unfilled for a year Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

823 - rather than have a year go by, make it four months, or during an election triggered by a member resignation.

PC> This is a specific suggestion to deal with the the next year (before the October 2012 elections.) I believe that the wording in the document is simple and appropriate.

SS> If this only applies up to 2012 then please add text limiting the life of this clause to the Oct 2012 elections. But clarification is needed on how to handle seats not filled in an election. Suggestion: the process for filling resigned seats is good enough. "If a seat is not filled during an election, another election shall be held as prescribed by the rules for filling a seat vacated by a member who has resigned."

SS> I am uncertain why there is pressure to compress the EC before we as an EC formally agree to do this. The efficiency of the operation of the EC appears to be dependent on issues other than its size.



 Comments   
Comment by pcurran [ 22/Sep/11 ]

SS> rather than have a year go by, make it four months, or during an election triggered by a member resignation.

PC> This is a specific suggestion to deal with the the next year (before the October 2012 elections.) I believe that the wording in the document is simple and appropriate.

SS> If this only applies up to 2012 then please add text limiting the life of this clause to the Oct 2012 elections. But clarification is needed on how to handle seats not filled in an election. Suggestion: the process for filling resigned seats is good enough. "If a seat is not filled during an election, another election shall be held as prescribed by the rules for filling a seat vacated by a member who has resigned."

SS> I am uncertain why there is pressure to compress the EC before we as an EC formally agree to do this. The efficiency of the operation of the EC appears to be dependent on issues other than its size.

We'll be passing another JSR before the 2012 elections, so there's no need to time-limit this wording. (And if we fail to pass that JSR before October 2012 then we would not want to time-limit it.)

As for "pressure to compress the EC" there is no such pressure. We do, however have broad agreement to do so (since our discussion at the f2f.

The existing language gives us the power to do what we need to do without requiring us to do anything. It's more than good enough.





[JSR348-131] rule that ballot topics must be discussed at EC meetings raises issues Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

standing rules:

122-124 - strike, since it prevents a vote to cancel an EC meeting (see 48, above). Also prevents timely votes on appeals issues that are raised soon after an EC meeting. The 14 day electronic voting period should cover discussion.

PC> I don't understand what you're saying here., but I think I disagree We conduct our business primarily via meetings, not through email. Allowing arbitrary email votes at any time would set a bad precedent.

SS> There are some matters that come up between meetings. This prevents them from being voted on. two examples: dealing with an appeal in a timely fashion. voting to cancel an EC meeting. Even without this rule there is still 14 days to discuss the matter. One can always pass a motion to table it for a meeting, but need the ability to make votes between meetings.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Discussed at the WG meeting on Sept 21. Unanimous agreement to keep the existing language.

Comment by starksm64 [ 21/Sep/11 ]

The one point I brought up today was around a slight ambiguity in line 128 of the current JCP_EC_Standing_Rules-16SEP2011-B-Clean version of the standing rules, although there is a statement in lines 122-124 requiring discussion of the motion at an EC meeting, line 128-129 seems to relax that by saying "good practice to discuss a motion at an EC meeting, or to circulate it for comment on the EC list, before requesting a vote".

I would suggest changing the ", or to circulate it for comment.." to ", and to circulate it for comment..." so there is no ability to read the section as an alternative to discussing the motion at a meeting.

Comment by pcurran [ 22/Sep/11 ]

We discussed this at the September 21 Working Group meeting and strongly agreed that allowing arbitrary votes between meetings would be a bad idea. Our primary means of doing business is via meetings, and we don't want to undermine that.

Will not fix.





[JSR348-117] 1.2.3 vs. 1.2.4 Created: 19/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Expert Group members can be disruptive, uncooperative, or unresponsive,
but Spec Leads can be unresponsive or inactive? Shouldn't these lists
be the same? Is a Spec Lead allowed to be uncooperative or disruptive?
Is an EG member allowed to be inactive?



 Comments   
Comment by pcurran [ 22/Sep/11 ]

We discussed this at the September 21 Working Group meeting and agreed that the terms we chose were appropriate. We deliberately used different terms for the EG member and the Spec Lead.

In practice, whatever terms we use, if people are unhappy with the way that an EG member or Spec Lead is behaving they will invoke the relevant process.





[JSR348-118] profiles can be based on latest or next platform version Created: 19/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In 2.1.3, line 392, change "latest version" to "most recent Release version or
a newer version under development via an active UJSR".



 Comments   
Comment by pcurran [ 20/Sep/11 ]

This is pre-existing language (which I don't really understand) so I'm reluctant to make changes. The substitution you suggest doesn't result in anything that makes sense to me.

Please suggest the complete replacement text that you'd prefer and I'll make the change.

Comment by Bill Shannon [ 20/Sep/11 ]

That was the complete replacement text.

If Java EE 6 has been released, and I'm developing Java EE 7, and I want
to create a new Profile based on Java EE, which version is the "latest"?

If "6", that means I'm not allowed to create a new Profile to be released
coincident with or later than EE 7.

If "7", and (e.g.) EE 7 isn't due to be released for a few years, that means
I can't create a new Profile based on EE 6 to be released this year, before
EE 7.

I think both cases should be allowed, thus the suggested change.

(You can imagine other failure cases, depending on the speed of the independent
JSRs. I don't propose fixing those here.)

Comment by pcurran [ 21/Sep/11 ]

Your suggestion would change:

"all UJSRs to define new Profile Specifications or revise existing Profile Specifications must reference the latest version of the Platform Edition
Specification they are based upon."

to:

"all UJSRs to define new Profile Specifications or revise existing Profile Specifications must reference the most recent Release version or a newer version under development via an active UJSR of the Platform Edition Specification they are based upon."

which is gramatically incorrect (or at least confusing).

Does this express what you mean?

"all UJSRs to define new Profile Specifications or revise existing Profile Specifications must reference either the most recent Release version of the Platform Edition Specification they are based upon or a newer version of that Specification that is under development via an active UJSR."

Comment by Bill Shannon [ 21/Sep/11 ]

What I intended (with parentheses added to make the grouping clearer):

all UJSRs to (define new Profile Specifications) or (revise existing Profile
Specifications) must reference ( ( (the most recent Release version) or (a newer
version under development via an active UJSR) ) of (the Platform Edition Specification
they are based upon) )

Your alternate version is fine too.

Comment by pcurran [ 22/Sep/11 ]

I went with my proposed wording, since Bill's had too many parentheses

Now closed.





[JSR348-77] Sections 1.2.3 and 1.7 overlap too much and should be merged Created: 16/Aug/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Alex Buckley suggested:

1.2.3 and 1.7 overlap too much. Since EG v. Spec Lead issues are handled by 1.2.3, either limit 1.7 to EG v. PMO issues, or merge 1.7 into 1.2.3 (preferred, since the sense of 1.2.3 is general EG unhappiness).



 Comments   
Comment by pcurran [ 16/Aug/11 ]

I agree that there's some overlap, but I don't think I agree that it's too much.

1.2.3 addresses a very particular type of "EG unhappiness" - the desire to remove/replace the Spec Lead. It's appropriate that there be a well-specified process for this.

1.7 is (appropriately) much more general, and allows EG members (should we allow others?) to appeal about anything.

I'm happy to keep them separate.

Comment by pcurran [ 22/Sep/11 ]

Having received no further input from the submitter, I'm closing this issue.





[JSR348-74] Refactor the balloting requirements to reduce duplication Created: 16/Aug/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Alex Buckley says:

"Duplication is the bane of a narrative spec, so I'm delighted to see standardized language for balloting in 1.3 (2nd para) and 3.4 (2nd para). 4.2 comes close. 5.2 could come close if the will of the 348 EG is to simplify Maintenance. Propose extracting the process of balloting into a new subsection, then "invoking" that process with parameters (length, what happens if revision received, etc) in 1.3, 3.4, 4.2, 5.2."



 Comments   
Comment by Alex Buckley [ 16/Sep/11 ]

As part of extracting a common reconsideration process, please consider the paragraph of 1.3 JSR Deadlines that starts "If the JSR Renewal Ballot fails".

Does the clause "If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 5)." apply only if the EG does not submit a revision within 30 days (wherein the JSR is closed), or only if the EG does submit a revision but the Reconsideration Ballot fails, or both?

Comment by pcurran [ 19/Sep/11 ]

Re:

As part of extracting a common reconsideration process, please consider the paragraph of 1.3 JSR Deadlines that starts "If the JSR Renewal Ballot fails".

Does the clause "If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 5)." apply only if the EG does not submit a revision within 30 days (wherein the JSR is closed), or only if the EG does submit a revision but the Reconsideration Ballot fails, or both?

==================

The latter. I've fixed this by re-wording. I don't see that this demonstrates the need for "parameterizing" the balloting logic.

This was discussed at the September f2f meeting and the consensus was that such a refactoring is unnecessary.

If you'd like to pursue this, please propose specific changes, otherwise we'll close this as "will not fix."

Thanks...

Comment by pcurran [ 22/Sep/11 ]

Having received no further input from the submitter I'm closing this issue,





[JSR348-34] Permit Spec Leads to submit no quarterly certification report if nothing has changed Created: 29/Jul/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Bill Shannon said, in comments on the draft document:

"I still don't think there should be a requirement to submit
anything if nothing has changed. who's going to detect failure to
submit? the PMO? if the PMO sends the quarterly "why haven't you
submitted anything" message, we'll just use that as the reminder to
say "nothing has changed". I don't want to be required to proactively
say "nothing has changed" every quarter. who's going to sign up for
doing that forever for JSRs that are no longer being used?"

I responded:

I still think that starting out with the assumption that people need
not report unless they have something to say will lead to people
ignoring this requirement. The PMO can use its judgment about who to
remind, but I really do want the "there's nothing to report this quarter"
messages so we don't have to guess whether or not we're being ignored.



 Comments   
Comment by pcurran [ 05/Aug/11 ]

See also http://java.net/jira/browse/JSR348-32

Comment by Bill Shannon [ 05/Aug/11 ]

I say with complete confidence that Spec Leads will not reliably provide this
information quarterly.

Comment by pcurran [ 06/Aug/11 ]

I understand that (some) Spec Leads won't want to do this. Some Spec Leads don't want to do most of what the JCP requires them to do (subject their Specs to EC votes, for example.) That doesn't necessarily mean that the requirements are a bad thing, or that we should turn a blind eye to violations of the process, or that the requirements should be watered down or dropped.

Bring it on!

Comment by Bill Shannon [ 07/Aug/11 ]

Note that generally it's not the Spec Lead who is maintaining the list of
compatible implementations. More likely it's a Marketing or Product Management
person.

Comment by starksm64 [ 09/Aug/11 ]

The current http://java.net/projects/jsr348/downloads/download/Working%20documents/JCP%20NEXT%202.8-10AUG2011-Clean.pdf version states on line 302 that this is done quarterly and at every MR. Inclusion of the MR does not seem helpful as it is likely that only the RI has passed the TCK. The next quarterly report should pick up the new implementations passing any changes introduced in the MR. When MRs do exist, the compatibility report should be specifying to what MR the testing has been done.

Comment by pcurran [ 22/Sep/11 ]

As Scott Stark suggested, I've removed the requirement to report at Maintenance Release times.

Re Bill Shannon's request that it permissible not to report if there's nothing new, we've discussed this several times and agreed that we want to hold the line.

So - I'm closing this. Hopefully Bill himself won't have to do anything





[JSR348-112] Clarification of obligation to offer TCK and RI licenses "for ever" Created: 19/Sep/11  Updated: 22/Sep/11  Resolved: 19/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

John Rizzo suggests the following changes/clarifications:

1. Allow cancelation of old licenses if there are new laws that prevent the old license from being legal.
2. When a JSR changes hands the new ML must present a license with comparable terms to the existing license.



 Comments   
Comment by pcurran [ 19/Sep/11 ]

The second paragraph of 1.1.3 Changes to licensing terms now reads:

For as long as a JSR is licensed and while it is legally possible to do so the Spec Lead Member must offer the RI and TCK licenses that were published at the time of Final Release, with the exception that reasonable increases in price are permitted. At subsequent Maintenance Releases alternate RI or TCK licenses may also be offered so long as all changes are disclosed, but licensees must be free to choose the original terms if they wish. For example, existing licensees who do not wish to accept a modified license when required to adopt a newer TCK shall have the option to license the updated TCK under the previous terms. If a JSR changes hands the new Maintenance Lead Member must present a license with terms comparable to the existing license.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-110] List the names of EG members and their organisation affiliation on the JSR page Created: 15/Sep/11  Updated: 22/Sep/11  Resolved: 19/Sep/11

Status: Closed
Project: jsr348
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: karianna Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is spun off from JSR348-64 - the goal here is to help EC members and others be able to clearly identify diversity imbalances in an EG



 Comments   
Comment by pcurran [ 19/Sep/11 ]

Inserted into lines 262-264 of the September 21 draft:

"The PMO will ensure that the JSR Page lists the Members who are members of the EG together with the names of individual Member Representatives or Member Associates where appropriate."

Marking this issue Resolved pending review and approval.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-109] The current definition of consensus is too vague Created: 11/Sep/11  Updated: 22/Sep/11  Resolved: 19/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current IETF-derived definition of consensus is too vague and needs to be tightened up.

This may be a usefuls starting-point: http://www.innatenonviolence.org/old/workshops/consensus1.htm



 Comments   
Comment by pcurran [ 19/Sep/11 ]

We agreed at the September f2f meeting to strike the formal definition of the term Consensus and to replace it with the deliberately more vague term agreement.

We also agreed to add some general text in the Standing Rules document to clarify that the primary goal of reaching general agreement, and also to clarify that in the absence of agreement any member may call for a vote at any time.

These changes have been made, so I'm marking this issue as Resolved pending review and approval.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-108] Harmonize language with RFC 2119 Created: 10/Sep/11  Updated: 22/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: eduardo Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Make sure that all words covered by RFC2119 are used correctly, and that words that should be the ones covered by 2119 are used (i.e. replace will with shall where appropriate)



 Comments   
Comment by eduardo [ 10/Sep/11 ]

All instances of "will" that can be interpreted as "must" have been replaced by "shall"; instances that are simply future tense were left in place.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-107] It should be permissible to vote no in a Maintenance Review Ballot if an issue referenced in an earlier "conditional yes vote" has not been addressed Created: 09/Sep/11  Updated: 22/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

September 9 draft



 Description   

Insert another bullet item after line 614

An issue that was referenced in a "conditional yes" vote during an earlier development stage has not been addressed.



 Comments   
Comment by eduardo [ 10/Sep/11 ]

The bullet point has been added

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-106] The Maintenance Lead may submit a written statement for consideration during a Maintenance Renewal Ballot Created: 09/Sep/11  Updated: 22/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

September 9 draft



 Description   

[We already have a similar provision for JSR Renewal Ballots.]

Lines 632-635 read

"If the Maintenance Lead fails to deliver the final materials within the time-period specified at the beginning of the Maintenance Review process a Maintenance Renewal Ballot will be held to determine whether the deadline may be extended or whether the previous Maintenance Review should be rescinded and the Maintenance Lead be required to go through another Maintenance Review."

Change this to

If the Maintenance Lead fails to deliver the final materials within the time-period specified at the beginning of the Maintenance Review process the PMO will inform the Maintenance Lead of an impending Maintenance Renewal Ballot, and will request the Maintenance Lead to prepare a public statement to the EC that explains the reason for the delay and provides a new deadline. 30 days after this request the PMO will initiate a Maintenance Renewal Ballot to determine whether the deadline may be extended as requested or whether the previous Maintenance Review should be rescinded and the Maintenance Lead be required to go through another Maintenance Review."



 Comments   
Comment by eduardo [ 10/Sep/11 ]

The suggested change has been incorporated

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-105] Clean up the Unresponsive Spec Lead section Created: 09/Sep/11  Updated: 22/Sep/11  Resolved: 09/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The wording in section 1.2.4 UNRESPONSIVE OR INACTIVE SPEC LEAD should be modified to ensure that the process cannot be used to seize control of a JSR from an individual or organization that is unwilling to cede control.



 Comments   
Comment by pcurran [ 09/Sep/11 ]

Eduardo: since you suggested a wording change during this morning's WG meeting, I'm assigning this to you.

Hope that's OK

Comment by pcurran [ 09/Sep/11 ]

Close and reopen to ensure the assignment takes.

Comment by eduardo [ 09/Sep/11 ]

The second half of section 1.2.4 will now say:

If the EC agrees that there is cause, it may ask the PMO to replace the Spec Lead. In the case where the Spec Lead is a Member Representative the PMO shall ask the Member to replace the Spec Lead. If the Member refuses to do so, the PMO shall seek to put in place an alternative Spec Lead, in which case the EC must conduct a transfer ballot as specified in section 5.1.2 of this document. If no Spec Lead replacement can be found, the EC shall initiate a JSR Renewal Ballot to determine whether the JSR should be shut down.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-98] Ensure that Spec Lead has flexibility in logging and responding issues Created: 07/Sep/11  Updated: 22/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Mark Reinhold:

Ensure that the requirement to log and respond to issues gives Spec Leads the freedom to ignore blatantly off-topic or deliberately obstructive comments.



 Comments   
Comment by pcurran [ 09/Sep/11 ]

Section 1.1.2 currently reads (in the September 8 draft)

"Issues must be tracked through a publicly readable Issue Tracker. The Expert Group may choose to use a publicly writable Issue Tracker, thereby permitting the public to log issues directly, or alternatively to identify formal comments in some other manner and to enter them into the Issue Tracker on behalf of the submitter. Whenever a Spec Lead or a Maintenance Lead submits materials to the PMO for review or ballot they must also provide an Issue List indicating the disposition of all of the Issues that have been logged against the JSR. In order to enable EC members to judge whether Issues have been adequately addressed the Issue List must make a clear distinction between Issues that are still open, those that have been resolved, and those that are closed, and must indicate the reason for any change of state."

Replace this with

"Issues must be tracked through a publicly readable Issue Tracker. The Expert Group may choose to use a publicly writable Issue Tracker, thereby permitting the public to log issues directly, or alternatively to identify formal comments in some other manner and to enter them into the Issue Tracker on behalf of the submitter. Whatever mechanism is used, a publicly-readable audit trail of all comments and Issues must be maintained.

Whenever a Spec Lead or a Maintenance Lead submits materials to the PMO for review or ballot they must also provide an Issue List indicating the disposition of all of the Issues that have been logged against the JSR. It is permissible for Issues logged late in the review cycle to be deferred for later consideration, and for Issues that are blatantly off-topic or that appear to have been submitted maliciously to be ignored.

In order to enable EC members to judge whether Issues have been adequately addressed the Issue List must make a clear distinction between Issues that are still open, that have been resolved, that have been deferred, and those that are closed, and must indicate the reason for any change of state."

Comment by pcurran [ 09/Sep/11 ]

Doing the hokey-cokey...

Comment by eduardo [ 10/Sep/11 ]

The changes have been incorporated

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-97] Minor changes in anticipation of merging the two ECs Created: 01/Sep/11  Updated: 22/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In anticipation of the EC merge, and in order to enable a reduction in the size of the ECs through "natural wastage," I propose the following changes to the process:

  • At Oracle's discretion, not all ratified seats need to be re-filled.
  • If there is no candidate for an elected seat, or if an elected member resigns, the EC can decide not to hold a follow-on election to fill the vacancy or vacancies.


 Comments   
Comment by pcurran [ 08/Sep/11 ]

Please make the following changes.

Change lines 668-670 from:

Vacated seats will be filled for the remainder of their term by a special election ballot that will be held no later than two months after the resignation (unless the resignation is less than six months before the next scheduled annual election ballot).

To:

"Vacated seats will normally be filled for the remainder of their term by a special election ballot that will be held no later than two months after the resignation (unless the resignation is less than six months before the next scheduled annual election ballot). However, EC members may choose not to fill a vacated seat in order to facilitate a reduction in the size of the ECs in anticipation of a future merge into a single EC."

Insert a new bullet-item after line 705: "If there is no candidate for an elected seat, the ECs may choose to hold this seat open until the next election."

Insert a new bullet-item after line 686: "At its discretion the PMO may choose not to nominate any candidate for an ratified seat, in order to facilitate a reduction in the size of the ECs in anticipation of a future merge into a single EC."

Comment by pcurran [ 08/Sep/11 ]

Will close and reopen, trying to force assignment to Eduardo to be visible in the navigator. Sorry for the mail traffic.

Comment by pcurran [ 08/Sep/11 ]

Interesting... While this issue was closed it showed up in the list of all issues as assigned to Eduardo, but in the filtered list of "not closed" issues it was displayed as unassigned. Will this change now I've reopened it?

Comment by eduardo [ 08/Sep/11 ]

Yes, it now shows as mine

Comment by eduardo [ 08/Sep/11 ]

All changes incorporated

Comment by pcurran [ 08/Sep/11 ]

Reopening until we've reviewed the change

Comment by pcurran [ 08/Sep/11 ]

This is resolved - just not reviewed

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-86] Improve clarity of Member definition Created: 17/Aug/11  Updated: 22/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Buckley Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-8 The prohibition on employees of JCP M... Closed
is related to JSR348-63 The use of the term "representatives"... Closed

 Description   

The sentence about five individual Members is intended to prohibit any company or organization (whether a Member or not) from obtaining de facto representation via individual Members. That is, the rule is not limited to five individual Members who are Member Representatives.

The rule could be made clearer by saying "as representatives for the same company or organization" rather than "a company or organization". (In case anyone reads "a" as "any".)

One could argue that normative rules do not belong in Definitions. The five-Members rule doesn't have an obvious home in the Process doc (perhaps the JSPA?). The "Spec Lead" definition has a redundant rule as noted elsewhere. The definition of "Profile Specification" contains clauses that would be better in 2.1.3.



 Comments   
Comment by pcurran [ 17/Aug/11 ]

From another issue (now closed):

The use of the term "representatives" here may be confused with the definition of Member Representative. We need to say this differently.

Addressing both Alex's and my concerns, here's a suggested fix.

On lines 97-98 of the PR draft, replace:

"No more than five individual Members are permitted at any one time as representatives of a company or organization."

with:

"No more than five individual Members from the same company are permitted at any one time."

Note also that the words "individual Members" appear in red(line) even in the clean version of the draft.

Comment by pcurran [ 17/Aug/11 ]

Re "One could argue that normative rules do not belong in Definitions. The five-Members rule doesn't have an obvious home in the Process doc (perhaps the JSPA?)."

I agree (had a discussion with Eduardo about exactly this.) Since we're not changing the JSPA now we couldn't find anywhere else to put this requirement.

Re: "The definition of "Profile Specification" contains clauses that would be better in 2.1.3."

I'll open a new issue for this.

Comment by pcurran [ 17/Aug/11 ]

Re the use of the term "representatives"

I'm getting confused. The term was chosen deliberately, since we want to make it clear that where someone "represents" a corporation or an organization (in the sense of the term Member Representative: "A person who is an employee or agent of a Member company or a Member organization *and who has been authorized by that Member to represent its interests within the JCP." then the limit of 5 applies, but otherwise not.

This distinction is critical, since JUG members are not authorized to represent the interests of the JUG within the JCP. So, the limit of 5 would not apply to them. It would apply to employees or contractors to corporations, and also to direct employees of non-profits such as Apache, but not to individuals who are "members" of Apache or W3C projects.

I've been trying to avoid having to define Non-Member Representative, but I'm not sure we can. Maybe defining Representative and deriving the other terms from this would help?

See my next comment for a summary of what we're trying to achieve.

Comment by pcurran [ 17/Aug/11 ]

It's difficult to define this with simplicity and clarity, but here's what we're trying to achieve with all this talk of Members and Representatives:

  • An organization (corporation or non-profit) can join as an organization.
  • Such an organizational member gets one vote in elections.
  • Any number of people who are associated with that organization can participate in the JCP as if they were members in their own right, but they don't have to sign an individual JSPA.
    • They do have to sign an Exhibit B ("employer release") if they want to join an Expert Group.
  • Some people who are associated with an organization are authorized by that organization to represent its interests.
    • For example, employees of or contractors to corporations or non-profits are authorized to represent their organization.
    • Members of JUGs, or people who belong to an Eclipse or Apache project are not authorized to represent their orgaization (the JUG, Eclipse or Apache.)
  • Authorized representatives of an organization (whether or not this organization is a Member of the JCP) are subject to certain limitations:
    • No more than 5 (I think we should reduce this to 2 or 3) can join the JCP as individuals
    • They may not run for election in their own right
    • They don't get a separate vote in elections.
    • Because people who belong to JUGs, or who participate in Apache or Eclipse projets (for example) are not authorized to act on behalf of their organization, they are not subject to this restriction.
Comment by Alex Buckley [ 18/Aug/11 ]

Can a person who is associated with an organizational member join the JCP in their own right? If so, no more than five, right?

When a person who is a "member in their own right" moves into the employ of an organizational member, do they lose their individual membership? If so, is the loss immediate or only when an n'th such person moves over?

Are all persons associated with an organizational member also authorized representatives?

Proposal:

You can either have three kinds of thing (Organizational Member, Organizational Member Representative, and Private Member) or two kinds of thing (Organizational Member and Individual Member). I prefer the second since it cleanly lets you speak of "Member", a common thing to want. The cost of the second is occasionally having to partition Individual Members into those associated with an Organizational Member ("reps") and those who are not.

  • Membership

1. A JCP Member is an Organizational Member or an Individual Member.

2. An Organizational Member is an organization (corporation or non-profit) who has signed the JSPA and is abiding by its terms.

3. An Individual Member is a person who:

  • has signed the JSPA and is abiding by its terms; or
  • is associated with an Organizational Member.

4. At most five Individual Members who are associated with an organization (corporation or non-profit) that is not an Organizational Member may represent its interests in the JCP.

(I presume dozens of Individual Members can represent an organization's interests if the organization is an Organizational Member that they're associated with.)

  • Expert Group Composition

An Expert is a Member who has expert knowledge of, and is an active practitioner in, the technology covered by a JSR.

An Expert Group is a group of Experts who develop or make... An Expert who is an Individual Member associated with an Organizational Member must sign Exhibit B to join an Expert Group.

A Spec Lead is an Expert responsible for leading the effort to develop or make...

  • Voting

An Organizational Member gets one vote in elections.

An Individual Member who is not associated with an Organizational Member gets one vote in elections.

Comment by Bill Shannon [ 18/Aug/11 ]

Currently, an Individual Member is not associated with an organization.
It would be confusing to change that. Even if they're employed by an
organization (member or not), they need a signed Exhibit B and then
act as if they were not associated with any organization.

Above it says:

  • Any number of people who are associated with that organization can participate in the JCP as if they were members in their own right, but they don't have to sign an individual JSPA.
  • They do have to sign an Exhibit B ("employer release") if they want to join an Expert Group.

That's confusing. If I'm representing my company, I don't need an Exhibit B.
Exhibit B is my company's way of releasing me and saying I'm on my own.

If I'm joining as an individual, representing myself, even though employed by
a company, I do need to sign the JSPA and I need an Exhibit B. Since I'm
representing myself and not my company, I need to agree to the JSPA.

Also, if I understand correctly, only employees of a JUG or Apache or Eclipse
can represent those organizations. A JUG member can only join as an individual.
(In the past we've allowed individuals to join expert groups and represent
Apache, for instance.)

Comment by dsline [ 18/Aug/11 ]

Bill,

I'm not sure about the Apache or Eclipse membership roles, but a JUG membership is almost like an education/non profit (which is what I believe the form I used when I filled out the JCP agreements for the JUGs I've been a part of). One of the nice things about a JUG membership, is that you have the benefits of a corporate/educational/non profit membership.These memberships were free membership that started to be offered about 4 years or so ago (+/- a year or so). This membership allows the members of a particular JUG to have a voice without going through an individual JSPA.

In looking at this debate further (also in response to issue 88 which info can be merged into this issue later), maybe we take a step back and look at the types of "member categories" we are representing (my apologies if some of these have already been covered in previous posts/issues):

1. Individuals
2. Companies
3. Educational/Non Profit
4. Existing Licenses
5. JUGS (I believe we fall under the Education/Non Profit area).

Note: If the document is breaking down the member categories specificially, do we need to add a process that allows the JCP to add in more member categories later?

For each of these 5 categories, we should looking at the following questions, which may help clarify the categories more consistently.
A. Total Number of Members (including rules for automatic inclusion)
B. Total Number of named contacts (primary/secondary)
C. Observer Rules
D. Spec Lead Rules
E. Expert Group Rules
F. Executive Committee Rules
G. Voting Rules - I think we can all agree that each "member" within the 5 categories above only gets a single vote.

I think we can all agree that each "member" within the 5 categories above only gets a single vote.

I believe a person's individual membership shouldn't automatically change if they move to an employer who is a member of the JCP. They may want to have a voice that is independent of their employers. It is, however an individual member's responsibility to check with their employer to make sure there are not any conflicts or policies that would prevent them from maintaining their Individual membership. What if this individual is already a spec lead, part of an expert group for a jsr, or an EC member? What would happen in those cases, especially if their employer is already an EC member.

If we did remove their individual membership, would their membership automatically revert back to an individual membership if they left their current employer who is a JCP member?

Keep in mind, when a member is elected or ratifieid to the EC, the members vote on what "member" and the individual representing the member they would like to serve on the EC. For example when I ran earlier this year for the EC role, the member group was "Central Ohio Java Users Group", and I was the contact representing the group.

Just my two cents,
Dan Sline
JCP Liaison, Central Ohio Java Users Group and JUG-USA

Comment by Bill Shannon [ 18/Aug/11 ]

Yes, you're right, we need to tease apart all the aspects of the different types
of membership and make sure it makes sense when we're done. In addition to your
A-G, add H) Cost to join the JCP.

> I believe a person's individual membership shouldn't automatically change if
> they move to an employer who is a member of the JCP.

We could argue about "automatically", but the big issue here is IP rights.
Typically an employee of a company will be required to assign their IP rights
to the company. In that case, we would either need a signed Exhibit B for
the employee to continue to represent themselves, or they would need to be
converted to be a representative of the company. And then we need to decide
what happens if either of those events causes any of the defined limits to be
exceeded. Some of this is similar to the case of one company acquiring another
company.

Some of these rules might be easier to describe if we consider them equivalent
to the member "leaving" the JCP and reapplying.

Comment by dsline [ 18/Aug/11 ]

All,

First off, if you look at the cost to join the JCP, most JUGs that I know of in the states (even other user groups that I've been part of over the years) don't take in any money, so my request to the group and the JCP, is that the JUGS remain free since they are a great way to get community involvement with the JCP.

Second, Bill made a good point about the IP issue. Either the JSPA for an individual (where a signature is needed) needs to state when they change employers they need to get a new updated JSPA from their new employer, or we leave it up to the individual member to get the necessary permissions from their employer before continuing with the JCP as an individual member. The question for the group is which option do you prefer (either requiring the new JSPA or using the honor system). If the JCP decides to require new JSPA, how do we enforce those guidelines? I think part of the answer also depends on what the member intends to do with their JCP membership. Are they simply a silent observer who votes in the EC elections, or are they active members (Spec Leads, Expert Group members, EC members, etc) who would otherwise require a fully signed JSPA. I think part of this debate may be handled in part now, and in part when the JSPA undergoes its changes.

Dan Sline
JCP Liaison, Central Ohio Java Users Group and JUG-USA

Comment by pcurran [ 25/Aug/11 ]

Linking to http://java.net/jira/browse/JSR348-8 before closing that issue and consolidating the discussion here.

Comment by pcurran [ 30/Aug/11 ]

I've created a summary document containing a mimimal set of changes that I propose to make. See http://java.net/downloads/jsr348/Working%20documents/Membership-AUG-31-2011.html.

Note that on legal advice we will need to postpone any restrictions on individuals who wish to join the organization until JSR3, when we modify the JSPA. This means that we cannot implement the proposed restriction on the number of employees of non-member companies who may join as individuals.

In an earlier comment Dan Sline suggested that we may want to clarify the following areas for each category of member.

A. Total Number of Members (including rules for automatic inclusion)
B. Total Number of named contacts (primary/secondary)
C. Observer Rules
D. Spec Lead Rules
E. Expert Group Rules
F. Executive Committee Rules
G. Voting Rules

A is off-llimits, as discussed above. In the document I deal with G and touch on E. B is not a matter for the Process Document (we don't even specify rules for this - nor should we, I believe - in the Standing Rules. I don't believe there are any implications for C since this isn't even a formally-defined term. The rules for Executive Committee membership are already clear, and I think we've already clarified the Spec Lead situation by judicious use of the term Member Representative.

Please review the document and comment in this thread.

Thanks...
I've dealt with A and G,

Comment by pcurran [ 09/Sep/11 ]

New/changed definitions

Agent: an individual - for example an employee, a contractor, or an officer - who is authorized to act on behalf of a company or organization.

Java Community Process Member (Member): A company, organization, or individual that has signed the JSPA and is abiding by its terms.

Member Representative: An Agent of a Member company or a Member organization who represents its interests within the JCP.

Member Associate: An individual who is assoicated with a Member organization but is not an Agent of that organization.

Lines 687-690

Change:

"All JCP Members are eligible to vote in ballots for Ratified and Elected Seats subject to the provision that if a Member has majority-ownership of, or is the employer of, one or more other Members, then that group of Members will collectively have 1 vote, which will be cast by the person they designate to be their representative for the ballot in question.

To:

"All JCP Members are eligible to vote in ballots for Ratified and Elected Seats subject to the provisions that if a Member has majority-ownership of one or more other Members, or if one or more Members are Agents of another Member, then that group of Members will collectively have one vote, which will be cast by the person they designate to be their representative for the ballot in question."

Lines 715-716

Change:

"except that employees of JCP Members cannot run for Elected Seats as individuals"

To:

"except that Agents of JCP Members cannot run for Elected Seats as individuals"

Lines 262-265

Change (note that we've lost some text here - we intended to require that details of the nomination be published):

"Any JCP Member or Member Representative can request to join an Expert Group at any time by submitting their nomination via the online form provided on the JSR Page. The nomination, together with the Spec Lead's official response, substantive deliberations within the EG about this matter, and any other official decision related to EG."

To:

"Any JCP Member, Member Representative, or Member Associate may request to join an Expert Group at any time by submitting their nomination via the online form provided on the JSR Page. Member Associates, since they are not covered by the JSPA of their organization, must sign the JSPA in their own right before they will be permitted to join an Expert Group. Details of such requests, together with the Spec Lead's official response, substantive deliberations within the EG about the matter, and any other official decisions related to EG membership must be published through the EG's public communication channel."

Comment by eduardo [ 10/Sep/11 ]

Latest modifications have been incorporated

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-84] Should Mailing List be a defined term? Created: 17/Aug/11  Updated: 22/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In a comment on http://java.net/jira/browse/JSR348-59 lightguard suggested:

"would it not make more sense (and to a point future proof) to drop the mailing list requirement and term it communication, or something similar? Especially in light of new group communication mediums such as the now defunct Google Wave project do we want to mandate that communication must happen through an email list?"

One way to deal with this suggestion would be to make Mailing List a defined term, and to define it generally in terms of the features such a communication mechanism should provide (allow public subscription, provide a searchable archive, etc.)

This would be somewhat similar to the suggestion that we define Issue Tracker.



 Comments   
Comment by pcurran [ 17/Aug/11 ]

I can't think of a suitable term.

Be that as it may, if we choose to implement this suggestion the definition should probably read something like this:

Whatever: a mailing list or similar communication mechanism (for example, a discussion forum or Wiki) that allows a group of people to communicate with each other electronically."

Instead of supplying a formal definition we might simply want to say, the first time we use the term:
"mailing list (or similar mechanism such as a discussion forum or Wiki)"

Comment by starksm64 [ 25/Aug/11 ]

I do think it helps the transparency effort to define a mailing list somewhat abstractly as you have done in the "Whatever" ter, and that the definition should include that it must be archived so that history is preserved.

Comment by pcurran [ 09/Sep/11 ]

[Line numbers reference the September 9 draft]

Replace the existing section 1.1.1 with this

1.1.1 PUBLIC COMMUNICATIONS

Expert Groups may choose to keep purely administrative matters private but all substantive business must be performed in a manner that allows the public to observe their work and to respond to it. All proceedings, discussions, and working documents must be published, and a mechanism must be established to allow the public to provide feedback. One common way of meeting these requirements is through the use of one or more mailing lists, but other alternatives such as blogs, Wikis, and discussion forums may be preferred. Whatever communication mechanisms are chosen, these must include an archiving function so that a record of all communications is preserved. Archives must be readable by the public."

Line 190: change "mailing lists" to "communication mechanisms"

Lines 410-411: change "Comments on the JSR should be sent to the JSR's public feedback mailing list" to "Comments on the JSR should be sent to the EC's public feedback mailing list"

Comment by eduardo [ 10/Sep/11 ]

Latest changes have been incorporated (except that in the case of lines 410-411 the term mailing list was replaced by communication mechanism, as was obviously the intention.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-71] Issue Tracker should be a defined term Created: 11/Aug/11  Updated: 22/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File JCPIssueStates.png    
Issue Links:
Related
is related to JSR348-95 Section 1.1.2 needs a little rewordin... Closed

 Description   

Issue Tracker should be a defined term, possibly including some requirements around what
we think an acceptable Issue Tracker is.



 Comments   
Comment by keilw [ 17/Aug/11 ]

What you suggest there, a list of suggested systems like JIRA, Bugzilla, etc.?

Comment by Bill Shannon [ 17/Aug/11 ]

A list of examples such as those would be good, but what I had in mind was some
sort of description of what you think the minimum requirements are for an
Issue Tracker for the purposes of the JCP.

Is a spreadsheet sufficient?

A wiki page?

Is some sort of search capability required?

Must the public be allowed to enter issues directly? Or is it ok if they send
their issues to an email address and the Spec Lead enters them?

Must closed issues remain visible, or can they disappear after they're closed?

Does the PMO or the EC have to approve your choice of Issue Tracker when the
JSR is submitted, so the only actual requirement is that the JSR gets approved?

I suspect you don't want to say much about most of this, but think about what you
would consider to be minimally acceptable and not open to the judgment of the EC
and write that. I'm not suggesting any particular answer, only that you decide
what the answer should be and record it in the defined term.

Comment by starksm64 [ 25/Aug/11 ]

At a minimum, in order for issues to be useful for tacking the state of a JSR, we need to enumerate the logical states and resolutions that need to be used to classify issues. I believe all issues must be visible, organized according to state and resolution at each phase of the EC balloting.

Comment by starksm64 [ 30/Aug/11 ]

Suggested states:
+ Open - open, new or in progress issue
+ Resolved - resolution taken, awaiting verification
+ Closed - resolution accepted, end of workflow

Suggested resolutions:
+ Complete - work on issue completed
+ Rejected - issue was not accepted as valid with reason why
+ Deferred - issue was out of scope for current release
+ Challenged - issue has no satisfactory resolution

Comment by pcurran [ 08/Sep/11 ]

Please add the following new definitions

Issue Tracker: A mechanism to allow issues (problems, tasks, comments, or requests for change) to be recorded and tracked by priority, status, owner, or other criteria. The Issue Tracker should permit issues to be identified by states such as open, resolved, and closed and should support the assignment of resolution types such as deferred (postponed to a follow-on release,) fixed (implemented,) challenged (no satisfactory resolution,) and rejected (deemed inappropriate or out of scope.)

Issue: an explicit reference to an item defined in an Issue Tracker.

Issue List: A list of Issues generated from an Issue Tracker, identifying the disposition of each.

Please replace the contents of section 1.1.2 ISSUE TRACKING with the following

Issues must be tracked through a publicly readable Issue Tracker. The Expert Group may choose to use a publicly writable Issue Tracker, thereby permitting the public to log issues directly, or alternatively to identify formal comments in some other manner and to enter them into the Issue Tracker on behalf of the submitter. Whenever a Spec Lead or a Maintenance Lead submits materials to the PMO for review or ballot they must also provide an Issue List indicating the disposition of all of the Issues that have been logged against the JSR. In order to enable EC members to judge whether Issues have been adequately addressed the Issue List must make a clear distinction between Issues that are still open, those that have been resolved, and those that are closed, and must indicate the reason for any change of state.

The PMO will publish the Issue List or a pointer to it together with the other materials.

EC members should review the supplied Issue list and take it into consideration when casting their ballot. If they have any reservations or concerns about a 'yes' vote, or if they wish to vote 'no,' they should accompany their ballot with comments which reference one or more Issues (perhaps logged by them) that they would like to see addressed in the future. EC members should vote 'no' if they believe that the Spec Lead or Maintenance Lead has not adequately addressed all Issues including those that have been rejected or otherwise closed by the Expert Group.

Comment by pcurran [ 08/Sep/11 ]

Please make the changes indicated in my previous comment and then we'll look for additional feedback.

Thanks...

Comment by pcurran [ 08/Sep/11 ]

Will reopen to try and work around a JIRA bug...

Comment by eduardo [ 08/Sep/11 ]

I've implemented all suggested changes, as well as harmonizing the use of Issue List, and changing all instances of "issue tracking mechanism" to "Issue Tracker".

Comment by pcurran [ 08/Sep/11 ]

Reopening until we've confirmed that the changes implement what we agreed.

Comment by pcurran [ 08/Sep/11 ]

It is resolved - we just need to review.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-70] Simplify Maintenance Review process by eliminating Item Exception Ballot and Change Log Created: 11/Aug/11  Updated: 22/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-32 Make the requirement to maintain a Ch... Closed

 Description   

Here's a proposed change that simplifies the Maintenance Review process by
eliminating the Item Exception Ballot and the Change Log. The Change Log is
replaced by the issue tracker, plus a general reference to the materials
submitted to the PMO for the Maintenance Review. (References to the Change
Log elsewhere need to be fixed as well.)

4.1 MAINTENANCE REVIEW

The ML will document all proposed Specification changes as separate
line item changes (indicating dependencies between items) and then send
a request to the PMO to initiate a Maintenance Review. Before the
Maintenance Review begins, the ML must summarize comments received
through the Maintenance feedback email list and must indicate the
disposition of each comment (e.g. deferred with a brief explanation,
rejected with a brief explanation, included in the proposal.) This
summary may be in the form of references to an issue tracking system.
This summary will be posted along with the MR request on the JSR Page.
The PMO will then make a public announcement and begin the review.

The ML may choose to modify one or more of the proposed changes based
on comments received during the review.

At the close of the Maintenance Review the PMO will initiate a 7-day
Maintenance Review Ballot. During this ballot EC members should vote
"yes" if they agree that the Maintenance Release should go ahead as the
Spec Lead has proposed, and "no" if they believe that one or more of
the changes proposed by the ML is inappropriate for a Maintenance
Release and should be deferred to a follow-on JSR. "No" votes must be
accompanied by comments in which the offending items are identified and
the reasons for the objection are explained.

If any line item receives "no" votes from 1/3 or more of the EC members,
the ML may choose to complete the MR without those items, or may choose
to withdraw the MR, possibly resubmitting a modified version or possibly
submitting a full JSR.

NOTE: there is no minimum number of "yes" votes required to move
forward with the proposed Maintenance Release, and "no" votes cannot
prevent a release unless the ML is unwilling to defer items.

At the end of Maintenance Review the ML will update the Specification,
incorporating all approved changes. Items that received "no" votes
from 1/3 or more of the EC members must not be included.

4.2 MAINTENANCE RELEASE

At any time after a Maintenance Review Ballot the Spec Lead will update
the Specification, RI, and TCK, as necessary and submit them to the PMO
for publication in a Maintenance Release. The PMO verifies that the
necessary changes have been made, and publishes the Specification, and
pointers to the RI and TCK on the JSR Web Page.

NOTE: until the Maintenance Release stage is reached any proposed
changes should be considered preliminary and subject to change, and
therefore should not be implemented in shipping products.



 Comments   
Comment by pcurran [ 26/Aug/11 ]

I've written up a new Maintenance Release process proposal based on our discussion during yesterday's Working Group meeting. See here.

Please review this, and comment on it here.

Thanks...

Comment by starksm64 [ 30/Aug/11 ]

I agree with the terms Issue Tracker, Issue and Issue List. I have added what I believe would be the minimum states/categories to the Issue Tracker (JSR348-71) definition issue.

In terms of how changes to license, RI and TCK must be now be provided, this must be done via one or more Issues.

Otherwise, I believe the proposal is good.

Comment by pcurran [ 08/Sep/11 ]

Re the suggestion that "In terms of how changes to license, RI and TCK must be now be provided, this must be done via one or more Issues," as discussed at last week's Working Group meeting this would be more easily handled by the PMO requiring this information in the template that they use for submissions.

Comment by pcurran [ 08/Sep/11 ]

The first set of changes to implement the agreed-upon proposal

Add this new definition

Maintenance Renewal Ballot: a ballot during which EC members vote on whether to permit a Maintenance Lead to extend the deadline for delivery of materials for Maintenance Release, or whether the previous Maintenance Review should be rescinded and the ML be required to start the process again.

Change these definitions as specified

Maintenance Review: A period of at least 30 days prior to finalization of a Maintenance Release when Members and the public consider and comment on the changes the Spec Lead proposes to include in the release, as identified in the associated Issue List.

Maintenance Review Ballot: An EC ballot to determine whether the changes and time line proposed by a Maintenance Lead are appropriate for a Maintenance Release.

Delete these definitions

  • Item Exception Ballot
  • Change Log

Make the following changes (line numbers refer to the Public Review Draft)

Line 234: delete "in the Change Log"

Lines 427-428: Change "the Change Log kept by the Maintenance Lead (see section 5)" to "the Issue list kept by the Maintenance Lead"

Lines 497-500:

Change:

"the Maintenance Lead must update these deliverables as necessary and record the changes in the relevant sections of the Change Log. The modified Change Log, the Specification (if changed,) and URLs for the updated RI and/or TCK must be delivered to the PMO, who will publish them on the JCP website."

to:

"the Maintenance Lead must update these deliverables as necessary and report the changes to the PMO when the Specification (if changed,) and URLs for the updated RI and/or TCK are delivered for publication on the JCP website."

Comment by pcurran [ 08/Sep/11 ]

Second - and final, for now - set of changes to implement the agreed-upon proposal

Replace sections 5.2 and 5.3 with the following

5.2 MAINTENANCE REVIEW

The Maintenance Lead will document all proposed Specification changes through the Issue Tracker and then send a request to the PMO to initiate a Maintenance Review. This request must be accompanied by an Issue List that summarizes all formal comments that have been received and that indicates the disposition of each Issue. The Maintenance Lead should also supply a summary of the proposed Specification changes, ideally in the form of a diff between the proposed and the current Specification. The Maintenance Lead must also provide an estimate of when the final materials will be delivered for the Maintenance Release. If no estimate is provided the deadline will default to 30 days.

The PMO will post the materials on the JCP website for public review. The Maintenance Lead may choose to modify one or more of the proposed changes based on comments received during the review.

At the close of the Maintenance Review the PMO will initiate a 7-day Maintenance Review Ballot. During this ballot EC members should vote 'yes' if they agree that the Maintenance Release should proceed as the Spec Lead has proposed, and 'no' if they have objections to the proposed release on one of the following grounds:

  • One or more of the changes proposed by the Maintenance Lead is inappropriate for a Maintenance Release and should be deferred to a follow-on JSR
  • The proposed Maintenance Release date too far in the future. (EC members should bear in mind that many Maintenance Releases need to be synchronized with updates to a Platform, and that a Maintenance Review may therefore need to be carried out significantly in advance of the proposed Platform release.)
  • Unreasonable changes have been made to the RI or TCK licensing terms.

'No' votes on other grounds will be rejected by the PMO and will be considered as abstentions. All 'no' votes must be accompanied by comments explaining the reason for the vote.

If the ballot fails, the Maintenance Lead may make any necessary corrections before requesting another Maintenance Review and ballot. The process may be repeated any number of times.

5.3 MAINTENANCE RELEASE

After a successful Maintenance Review Ballot the Maintenance Lead will update the Specification, RI, TCK, and Issue List as necessary and submit them to the PMO for publication in a Maintenance Release. The PMO verifies that the necessary changes have been made, and publishes the Specification, the Issue List, and pointers to the RI and TCK on the JSR Web Page.

NOTE: until the Maintenance Release stage is reached any proposed changes should be considered preliminary and subject to change, and therefore should not be implemented in shipping products.

If the Maintenance Lead fails to deliver the final materials within the time-period specified at the beginning of the Maintenance Review process a Maintenance Renewal Ballot will be held to determine whether the deadline may be extended or whether the previous Maintenance Review should be rescinded and the Maintenance Lead be required to go through another Maintenance Review.

Comment by pcurran [ 08/Sep/11 ]

Please make the changes described in the previous two comments and then let's publish and seek further feedback.

Thanks...

Comment by pcurran [ 08/Sep/11 ]

Force assignment to Eduardo by closing and reopening...

Comment by eduardo [ 08/Sep/11 ]

I've incorporated all suggested changes. I've also noticed that the changes include both "Issue List" and "Issue list". These should be normalized and "Issue List" should be either defined or left as "issue list". I will open an issue on this.

Comment by pcurran [ 08/Sep/11 ]

Reopening until we've confirmed that the changes implement what we agreed.

Comment by pcurran [ 08/Sep/11 ]

It is resolved - we just need to review

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-64] Should there be a limit on the number of members from a single company/organization who can join an Expert Group? Created: 10/Aug/11  Updated: 22/Sep/11  Resolved: 19/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If there is no limit on the number members from a single company/organization who can join an Expert Group then the Spec Lead, together with three EG members from his/her company/organization could throw anybody out of the EG.

Even if there is a limit, should we be granting this absolute right to the Spec Lead plus any three members?



 Comments   
Comment by pcurran [ 17/Aug/11 ]

Re: If there is no limit on the number members from a single company/organization who can join an Expert Group then the Spec Lead, together with three EG members from his/her company/organization could throw anybody out of the EG.

We could modify the language in 2.2.3 to specify that the three EG members must be from different organizations (the language is likely to be somewhat clumsy...)

As for the original question, the consensus at today's Working Group meeting seemed to be that we don't have a problem in this area, and shouldn't impose a limit. If we do, though, it should be merely advisory ("no more than x members should be from the same company or organization.")

Comment by pcurran [ 14/Sep/11 ]

Consensus reached during September f2f meeting:

No. However, we should disclose during the application process for EGs what peoples' corporate affiliations are.

EC members should take this into account when voting on JSRs. Diversity is the ideal, but if a JSR is being run in an open and inclusive manner but happens to be "non-diverse" then they may agree that it's appropriate for it to continue.

Separate question: should we publicise the names of the individuals who are representing company <whatever> on the JSR page?

If anyone cares, please open a separate issue.

Comment by pcurran [ 19/Sep/11 ]

Changed lines 259-262 of the September 21 draft to read:

"Details of such requests, including the organizational affiliation of the requester, together with the Spec Lead's official response, substantive deliberations within the EG about the matter, and any other official decisions related to EG membership must be published through the EG's public communication channel."

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-57] Distinction between JSR "ballots" and EC "votes" is still not entirely clear Created: 09/Aug/11  Updated: 22/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc, Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

References are to the August 10 version



 Description   

Earlier confusion over the distinction between JSR "ballots" and EC "votes" has mostly been cleared up.

However, the Standing Rules document still contains (lines 112-113) a reference to the JSR ballot process. This seems unnecessary (particularly since it simply references the Process Document.)

The Process Document should define the process for holding JSR-related Ballots, while the Standing Rules should define the process for EC voting. These are two completely different processes, and we should clearly distinguish between them.

One way to do so is by terminology - by using the term "ballot" for the more formal JSR-related ballots and "voting" for the "advisory" EC votes.

For that reason, I suggest that we replace the term "ballot" in the Standing Rules with "vote."

Note that the section beginning on line 145 is labeled Electronic Voting rather than Electronic Ballots, and earlier in the document we say "Missing two meetings in a row (whether teleconference or face-to-face meetings) results in loss of JSR ballot and EC voting privileges." Both of these examples, I believe, demonstrate the value of making this disctinction.



 Comments   
Comment by pcurran [ 08/Sep/11 ]

Eduardo stated in a comment on another issue:

Regarding the issue of "vote" vs. "ballot" I've tried to harmonize the "Electronic Voting" section by eliminating the word "ballot" completely from it.

I'm interpreting that as a proposed fix for this issue, and am marking this resolved.

We can then review to see if it's OK

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.





[JSR348-133] "Agent" designation unfairly discriminates against individual members already underrepresented Created: 21/Sep/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

54 - The EC has never received an answer as to how much of our current individual membership would not be able to vote in the next election because they are an "agent" of another EC member.

PC> We can't answer this without spending an unreasonable amount of time probing our database. That's the problem. Employees of corporations can "masquerade" as individuals.

SS> send me the member list. here is my NDA: "I promise to use this only to perform above calculation and provide result to PMO and then delete the list." Should take about an hour of time on Excel.

(continued from original comment) My opposition to unqualified "Agent" designation is a desire to prevent further dilution of individual representation (corporate representation in the EC is inversely proportionate to individual membership). Agree that corporate employment should be disclosed during election but it should be very clear that this is not the same as representation as that corporation's Agent.

PC> Preventing Agents from voting separately from their employers does not "further dilute" (when did we previously dilute?") the power of individuals - it does the exact opposite, by preventing corporations from exerting unreasonable control indirectly through their Agents.

SS> we are inventing trouble and discriminating against individuals. besides I believe we decided in the EC meeting to strike this and give the PMO the ability to address fraud - see issue (not yet created) Suggest adding something to "Agent" limiting representation to JCP-related matters (if agent is just a contractor or employee, does not count.)



 Comments   
Comment by pcurran [ 22/Sep/11 ]

As I've already pointed out, we've already spent an inordinate amount of time on this issue. The solution we have - taking into consideration the as-yet-unfixed issue concerning the PMO's power to investigate possible voting fraud (http://java.net/jira/browse/JSR348-147)- is as good as we're going to get for now.

The whole matter will be taken up again when we revise the JSPA.

In the meantime, I'm closing this issue.





[JSR348-152] Member should not be capitalized in the Standing Rules Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When capitalized it refers to JCP Members, which is an entirely different kettle of fish.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Fixed...





[JSR348-148] Elections: grandfather seat holder terms that began prior to EC merge Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

799-807 - Not sure where I stand with ratified seats but a minimum the EC if not the membership should be able to provide names. I thought we discussed this but it is not in this document. Also strike bullet point two, as it predicts an event (merging the ECs) which has not happened yet and won't happen until there is a vote to do this. In the event the Google/Oracle lawsuit is settled in a way that makes ME "exciting" it would be a mistake to reduce the number of seats given the diversity of issues in ME and SE/EE.

PC> If by "provide names" you mean "make suggestions" then of course this is possible. I think we agreed to encourage the EC to make recommendations to Oracle. I don't think it's necessary to call this out in the Process Document. As for reducing the number of seats, that's a matter for the next JSR and you should bring it up there.

SS> Raising here since this JSR includes other controversial issues. Three points here:

1) I think the promise of Java as an open platform is being approached when the EC chooses ratified seats. However the mix needs to include a balance of corporations, JUGs and individual voices. The purpose of ratified seats must be to ensure a balance of representation which can change from year to year among elected seats. Again this is an EC role and requires a balanced EC to begin with (balance of corporate, JUG, and independent individual interests.) Falls under category of "controversial" but other controversial changes have been made within this JSR.
2) Strike references to future changes to EC composition. Anyone elected/ratified to a seat should be grandfathered into their original terms. This is not only for the EC member's benefit but also for the community that elected that member and has expectations on how long they'll remain in the seat. Eliminates hairy future discussions about who gets their terms cut short, which is bound to waste EC time that could be better spent on issues of importance.
3) Though not part of this JSR, I must reiterate that revision of the composition of the ME EC should be placed on hold until the Google/Oracle legal matter is settled, as I've heard from others that the possibility exists that the outcome can profoundly impact the vibrancy of Java ME in either direction.



 Comments   
Comment by sean_sheedy [ 21/Sep/11 ]

Related:

799-807 - the nomination process is controlled by Oracle, not the PMO and it has been said as much in the EC. So either change PMO to "Oracle" (for truth in advertising) or drop ratified seats or change PMO to EC.

PC> And the PMO is chosen by Oracle. If you insist on this change, please log an issue.

Comment by pcurran [ 21/Sep/11 ]

I've changed the relevant words to: "Oracle nominates Members to fill the vacant Ratified Seats with due regard for balanced community and regional representation."

As for your other more random comments...

"1) I think the promise of Java as an open platform is being approached when the EC chooses ratified seats. However the mix needs to include a balance of corporations, JUGs and individual voices. The purpose of ratified seats must be to ensure a balance of representation which can change from year to year among elected seats. Again this is an EC role and requires a balanced EC to begin with (balance of corporate, JUG, and independent individual interests.) Falls under category of "controversial" but other controversial changes have been made within this JSR."

As the text quoted above says, we do expect that the ratified seats will be filled with due regard for balance.

"2) Strike references to future changes to EC composition. Anyone elected/ratified to a seat should be grandfathered into their original terms. This is not only for the EC member's benefit but also for the community that elected that member and has expectations on how long they'll remain in the seat. Eliminates hairy future discussions about who gets their terms cut short, which is bound to waste EC time that could be better spent on issues of importance."

This has already been addressed (and rejected in a separate issue

"3) Though not part of this JSR, I must reiterate that revision of the composition of the ME EC should be placed on hold until the Google/Oracle legal matter is settled, as I've heard from others that the possibility exists that the outcome can profoundly impact the vibrancy of Java ME in either direction."

Indeed - not part of this JSR, hence irrelevant...





[JSR348-140] License changes during MR require unanimous EG approval except for limited circumstances Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

290 - Require unanimous vote of any EG members who participated in the JSR to allow alternate licenses during MR; could permit license horse-trading during MR that benefits some EG members to the detriment of others.

PC> If you insist on opening up this can-of-worms please open a separate issue. I predict that we won't be able to resolve this before Final Draft. (What we have now is a reasonable compromise. Let's see how it works in practice.)

SS> As stated elsewhere, not requiring unanimous consent can lead to discrimination against some EG members. An exception would be the "nominal price increase" perhaps more specifically stated to be "adjusted for inflation". A change in price from free to some price would not qualify for this exception. Such a change would discriminate against open source implementers (assuming the original licenses were compatible with an open source implementation.)



 Comments   
Comment by pcurran [ 21/Sep/11 ]

If we pursue this I predict that it will not be resolved in finite time.

Repeating my earlier comment, we have a starting point. Let's see how it works before we complicate things further.

I'm closing this...





[JSR348-139] prices of licenses to be disclosed in the license terms Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

289 - Require prices of all licenses to be disclosed in the license.

PC> If you insist on opening up this can-of-worms please open a separate issue. I predict that we won't be able to resolve this before Final Draft. (What we have now is a reasonable compromise. Let's see how it works in practice.)

SS> the text currently allows "reasonable" increase in price, which implies that the price is known to begin with. A change to the document requiring that prices be disclosed in the license provides necessary clarity allowing EG members to join an EG without first going through a price negotiation with the spec lead. This coupled with the requirement that an EG vote unanimously to approve a license helps ensure that a surprise "price increase" near the end of a JSR doesn't harm any particular EG member who has already made her contributions.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

The current wording states that "complete copies of the proposed Specification, RI and TCK licenses" must be disclosed.

It doesn't say "complete copies of the proposed Specification, RI and TCK licenses must be disclosed but it's OK to keep the pricing secret."

We have this covered already...





[JSR348-142] Prospective EG members petitions for membership are public; appeal process for rejections Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

301 - Add words to allow members to petition an EG for membership, with a clear appeals path to the EC which can override the spec leads' decision. This was sorely needed for MSA.

PC> We've spent an inordinate amount of time on these issues, primarily to address your concerns about what happened on MSA many years ago. We've agreed that public disclosure is the most reasonable approach to take.

SS> My point is that there is no "public disclosure" if the spec lead considers this a "private adminstrative matter". Suggest wording that "prospective EG members may petition a spec lead for membership while a JSR is active, and spec lead must publish that petition in public (mailing list/wiki/whatever.)". Also "Prospective EG members whose membership is rejected by the spec lead or EG may appeal to the EC using the appeals process described elsewhere. As part of this process the EC shall consult with the member, spec lead, and EG members in reaching a decision. The EC shall decide either to uphold the rejection or require the EG to accept the member. This decision shall be binding." ("binding" because elsewhere EG votes are stated to be merely "advice", so the EG could ignore the "advice" and be within the rules.)



 Comments   
Comment by pcurran [ 21/Sep/11 ]

"Details of such requests [to join an Expert Group,] including the organizational affiliation of the requester, together with the Spec Lead's official response, substantive deliberations within the EG about the matter, and any other official decisions related to EG membership must be published through the EG's public communication channel."

What more do you want?

The Spec Lead may not declare this business "administrative" (that's what the word "must" in the above text implies.)

No need for further clarification.





[JSR348-136] spec lead chooses what counts as "administrative", can suppress info that should be public Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

236 - strike the part on keeping "purely administrative matters" private. What constitutes an administrative matter? The decision of a spec lead to reject a Member's request for membership?

PC> I disagree. We can't always be precise, but "you'll know it when you see it. As for "the decision of a spec lead to reject a Member's request for membership" we explicitly state elsewhere that this must be public.

SS> the spec lead here determines what constitutes "adminstrative." issue of fox watching hen house. please strike



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Agreed. The fox is watching the hen-house. And all of the foxes' buddies and collaborators and competitors are also watching. If there is any monkey-business (to mix our metaphor) then the truth will come out.

We're making major changes in our transparency requirements. Let's see how they work out before we start specifying things in excruciating detail, theeby rendering the Process Document even more unreadable than it already is...





[JSR348-141] Change "offered for the lifetime..." to "continuously available" Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

297 - change "offered for the lifetime of that JSR" to "continuously available."

PC> Already fixed in a later draft

SS> in version JCP-2.8-21SEP2011-Clean.pdf (today's date) the wording still exists on line 251.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Already fixed in an as-yet unpublished version of the document.

The relevant text now reads:

"For as long as a JSR is licensed and while it is legally possible to do so the Spec Lead Member must offer the RI and TCK licenses that were published at the time of Final Release..."

(Note that we can't do more than this since the "lifetime" of a JSR can only be defined by the JSPA, which we are not changing in this JSR.)





[JSR348-143] appeals process open ended; other sections need to provide appeals procedure for those areas Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

399 - the appeals process is open ended (no timelines after a request for clarifition/documentation, for instance.) Other sections must prescribe what options are available to the EC in appeals.

PC> It's deliberately open-ended. As I suggested above, if you insist on spelling everything out in precise and legalistic detail you'll render this document completely incomprehensible and intimidating to the individual developers you want to encourage.

SS> JSR-348-142 provides an example of how the process doc can be clarified to provide more direction to the EC as to how to properly handle an appeal so as to provide a fair and consistent appeal process.

SS> to address the argument of comprehensibility, the comprehensibility of the document would be aided greatly by following true open platform/open source practices; for example, many parts about license decisions and fairness would be eliminated if we settled on a small number of open source (open platform) licenses that members could choose from. Here I'm trying to close loopholes, some of which are created by deviating from these practices.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

Re the most recent comments:

399 - the appeals process is open ended (no timelines after a request for clarifition/documentation, for instance.) Other sections must prescribe what options are available to the EC in appeals.

PC> It's deliberately open-ended. As I suggested above, if you insist on spelling everything out in precise and legalistic detail you'll render this document completely incomprehensible and intimidating to the individual developers you want to encourage.

SS> JSR-348-142 provides an example of how the process doc can be clarified to provide more direction to the EC as to how to properly handle an appeal so as to provide a fair and consistent appeal process.

>>> Then we'll deal with that in issue 142

SS> to address the argument of comprehensibility, the comprehensibility of the document would be aided greatly by following true open platform/open source practices; for example, many parts about license decisions and fairness would be eliminated if we settled on a small number of open source (open platform) licenses that members could choose from. Here I'm trying to close loopholes, some of which are created by deviating from these practices.

>>> Irrelevant. You obviously have a big axe to grind, but please let's keep to the point. We've already agreed that the matter of suggested/recommended licenses is out of scope for this JSR and will be dealt with in the follow-on JSR.

I will close this as "Will not fix."

Comment by pcurran [ 21/Sep/11 ]

See previous comment.





[JSR348-146] EC as level playing field Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

738 - no company should have a permanent seat on the JCP. JCP participation is not mandatory; if the JCP is not working for a company, they can exit the JCP. That, and an ability to fork Java, provide very strong incentives to members to work to keep JCP Java the best it can be, and highly competitive with respect to other platforms.

PC> No comment.

SS> Originally we had agreed to defer "controversial" topics like this to v2 of JCP.next (JSPA changes) but since this JSR contains many "controversial" changes I have to raise it.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

As we've agreed, controversial, legal, and governance issues are out of scope for this JSR.





[JSR348-132] elected members terms should be grandfathered Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

31, 32 - strike words from "so newly elected EC...LENGTH OF TERM" since we are not changing anyone's term after they have been voted into a seat.

PC> We mean what we say. The Process Document says that they'll serve a three-year term. They may not. The wording is appropriate and necessary.

SS> inventing trouble, and possible fairness issues (why should only newest members get their terms reduced?) please strike this. terms of members elected prior to change in EC distribution should be grandfathered in. not sure what the issue is here. we discussed a gradual reduction process in the ec meeting that would take several years to accomplish and nobody seemed to take issue with that. removing this doesn't really effect that.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

We haven't yet locked anything down for the next JSR so it's true to say that newly elected members may not get to serve a full three-year term.

Even if we allow those who hold elected seats to serve their full term, the current plan is that ratified members will not.

So, we need to keep the flexibility that this wording allows us.

Comment by pcurran [ 21/Sep/11 ]

We have not yet decided how we will do the merge. It's quite likely that some members who are elected in 2011 - whether to elected or ratified seats - will not in fact be permitted to serve the full three-year term. Therefore we need this language.

This is not a conspiracy against "individual" members. (In fact, given our current thinking, it's more likely that those who will be most affected by this change are the "corporate" members.)

Comment by pcurran [ 21/Sep/11 ]

Reopening so I can specify "will not fix" rather than "fixed" - sorry about that.





[JSR348-127] ec must vote to cancel meetings once scheduled Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

standing rules:

48 - add "once scheduled, cannot be canceled without 2/3 majority of both ECs". Deals with issues of meetings canceled w/o EC consultation last year.

PC> Needs a separate issue.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

As discussed at the September 21 Working Group meeting...

The PMO/Chair runs the meetings. Like it or not, if the PMO/Chair decides to cancel a meeting, or decides not to show up, there's nothing that EC members can do about this. (We have no proceedures for running meetings in the absence of a Chair.)

So, I'm closing this as "Will Not Fix."





[JSR348-122] JSR-348 changes from individual perspective Created: 21/Sep/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Closed
Project: jsr348
Component/s: General, Process Doc, Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File jsr-348-comments.txt    

 Description   

In the September EC meeting (and prior to close of the Public Review) I expressed reservation about this JSR ultimately coming from a mindset other than that of a community which was, as I expressed it, "collaborating freely on a free platform, finding value not in the platform itself but in what can be created from it". Participating EG members should understand that I know a lot of work has gone into this, and the push for transparency is apparent. However, I kept finding instances where loopholes existed that could be exploited by someone less interested in collaborating and more interested in competing. That there remains an interest in monetization and control through licensing makes these loopholes difficult if not impossible to fill. Long story short, I was encouraged by other EG members to file my comments rather than abstain and let the JSR conclude without my input.

These comments are provided from the perspective of someone who believes that the Java platform should be an open platform as described to us developers so many times over the years in so many venues.

Had this JSR been limited to election reform and not touched license related issues, it would have met the original criteria of not being "controversial" (we had decided early this year to limit this JSR to low hanging fruit we could all agree on, and save the difficult revisions for the post-348 JSR.)

Comments to the Process and Standing Rules docs are attached.



 Comments   
Comment by pcurran [ 21/Sep/11 ]

This is not one issue, it's at least 10 and maybe 20. Since we are now only one week away from Final Draft it's likely that many of these will need to be deferred.

As a courtesy, and to help you to triage your issues and to group them where appropriate, I will comment on the points raised in your text document by means of an email to the Observer's alias.

However, we won't be able to process these unless you file them separately.

Comment by pcurran [ 21/Sep/11 ]

I'm closing this "monster issue" on assumption that you will log/have logged separate issues for everything you care about.





[JSR348-114] Maintenance Review definition should reference Maintenance Lead, not Spec Lead Created: 19/Sep/11  Updated: 20/Sep/11  Resolved: 20/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See Summary.



 Comments   
Comment by pcurran [ 20/Sep/11 ]

Fixed





[JSR348-116] public access to non-written communication must not be required Created: 19/Sep/11  Updated: 20/Sep/11  Resolved: 20/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 1.1.1 could be read to require that the public must have access to
all conference calls, meetings, etc., and that such meetings must be recorded
(audio and video). This section must make it clear that this is not required.



 Comments   
Comment by pcurran [ 20/Sep/11 ]

I added a footnote: "Expert Groups are not required to create or maintain audio or video recordings of their meetings."





[JSR348-83] Spec Lead v. Spec Lead Member Created: 17/Aug/11  Updated: 19/Sep/11  Resolved: 19/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Alex Buckley Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I think this is a redundant and dangerous distinction. It catches out casual and expert readers, e.g. 1.1.3 says "the Spec Lead must continue to offer..." when it means Spec Lead Member. It's inconsistent with having only Maintenance Lead (where is Maintenance Lead Member?) and Expert (where is Expert Member?).

Bottom line, I think there should only be "Spec Lead", and it should follow the style of "Expert", i.e. a Member or a Member Representative.



 Comments   
Comment by Alex Buckley [ 17/Aug/11 ]

Related: the definition of Spec Lead explicitly requires the Spec Lead to be a Member, but that's redundant because the Spec Lead is an Expert and an Expert is a Member (or Member Representative).

Comment by keilw [ 17/Aug/11 ]

Alex, is there a separate issue for this comment? I can't see the option here, but given the right user group I know, JIRA allows linking other issues.

Comment by pcurran [ 23/Aug/11 ]

The definition of Spec Lead seems to have been taken from the JSPA, where the definition of Expert is different (can include non-Members who have signed the IEPA.) We eliminated this category.

The definition does need to be cleaned up to ensure that it doesn't conflict with the JSPA (see http://java.net/jira/browse/JSR348-92.

And yes - there's a superficial inconsistency introduced by not having the terms Maintenance Lead Member and Expert Member. (These may not be necessary - it depends on whether or not we need to make the distinction. Only a review of the text will tell.)

Comment by pcurran [ 14/Sep/11 ]

As discussed and agreed at the September f2f meeting:

We have to make the distinction. Either we do it once in the definition or multiple times within the text.

The former is preferable.

Comment by pcurran [ 19/Sep/11 ]

See the latest comment.





[JSR348-79] Should the Process Document specify what is appropriate for a Maintenance Release? Created: 16/Aug/11  Updated: 19/Sep/11  Resolved: 19/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Public Review draft of the Process Document contains the following text:

"Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements. Modifications to existing APIs or the addition of new APIs should be deferred to a new JSR."

Is it appropriate to provide guidelines like this in the Process Document? (As the author of that text, I believe so.)

If so, is the statement that "the addition of new APIs should be deferred to a new JSR" what we want to say.

As the author of that text, I believe so.

Bill Shannon disagrees. In a private email exchange he said:

The above is too restrictive. We definitely want to allow API changes in an MR. My thoughts on this are...

[text extracted from an Oracle internal document that Bill pointed to...]

Can I do this in a Maintenance Review?

Which API changes are "too big" for the Maintenance Review process is a judgment call. In general, the changes should be straightforward. A person who understands the spec should be able to look at the proposed changes and say "ya, I understand that".

The appropriate measure is less the size of the change and more the complexity of the change. (But of course size and complexity are related.)

You can add new methods, new classes, and new packages to an existing spec.

You can not create an entirely new spec.

In the end, the practical answer to "what can I do in an MR?" is "whatever the JCP EC approves". If you think there's significant risk that they won't approve it if they see it in an MR, don't do it in an MR.



 Comments   
Comment by pcurran [ 14/Sep/11 ]

Discussed at EG 2f meeting. Roger Riggs will draft language saying "changes in a Maintenance Release should not break backward compatiblity."

Comment by Bill Shannon [ 14/Sep/11 ]

I'm not sure why this is specific to Maintenance Releases, don't we expect this to
be true for all JSRs?

Note "should", not "must", and note no strong definition of "backward compatibility".

Comment by rogerriggs [ 16/Sep/11 ]

WRT to line 588-589 of the JCP-2.8-10Sep2011-Clean version of the process doc.

The term Binary Compatibility should be used instead of backward
compatibility.

Binary Compatibility is defined by the Java Language Specification Chapter 13.

Incompatible changes can be contemplated by a JSR (not an MR)
as a result of a thorough review of the impact of changes and broad
review by the EG and community. Incompatible changes are infrequent
but have been used judiciously to remove unused APIs and to correct
technical problems that have little or no impact.

The current wording allows discretion to be used by the ML
and the changes to be checked during the maintenance review
and by the EC before voting but can be strengthened to require
binary compatible changes.

Suggested alt text:

588: .... Modifications to existing APIs or the addition of new APIs
++ must not break binary compatibility,
++ as defined by the Java Language Specification, and
should be deferred to a new JSR.

Comment by pcurran [ 19/Sep/11 ]

I've implemented Roger's suggested change. This is clear enough and small enough that I'm going to close this without review.

Comment by pcurran [ 19/Sep/11 ]

Closing as discussed in the last comment.





[JSR348-103] Remove the notes from the Standing Rules Created: 09/Sep/11  Updated: 10/Sep/11  Resolved: 10/Sep/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Remove the notes from the Standing Rules for clarity of reading.



 Comments   
Comment by eduardo [ 10/Sep/11 ]

Done





[JSR348-96] Specifications should be directly available as HTML on the web Created: 29/Aug/11  Updated: 09/Sep/11  Resolved: 09/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Stig Inge Lea Bjørnsen Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One of the problems with the JSR specifications is that application developers often do not read them or consult them as reference material.

I believe one of the reasons for this is that the specifications aren't directly available on the web as HTML. Today, reading a specification usually requires one to accept the license agreement before downloading the specification as a PDF file.

Contrast this to how easily available the HTTP RFC is at http://tools.ietf.org/html/rfc2616.

I wish we had a similar web site for reading JSRs. The Servlet specification could for instance be available as HTML at http://jcp.org/html/jsr315.

By having predictable URLs parametrized by the JSR number we could have IDEs make the specifications instantly available to developers by right clicking a class and then choose "Open specification".



 Comments   
Comment by pcurran [ 09/Sep/11 ]

This is an excellent suggestion, but unfortuately out of scope for JSR 348. Although you say that you want easy access to the specification what you really mean is you want easy access to the documentation. There's a There's a subtle but very important distinction between these two terms.

The specification is the formal statement of required functionality. The click-through licenses are there for a reason - because the right to implement the technology defined in the specification is granted only under certain conditions (that the implementation be compatible, for example.)

Yes - for many JSRs (those that define APIs) the specification is often written in (or contains) Javadoc, which is identical to the documentation for the implementation of the specification. However, for other JSRs (the VM spec, for example) the specification (how the JVM functions) is very different from the documentation (how to invoke it.)

Bottom line: since documentation is an implementation issue and the JCP is concerned with formal requirements, your suggestion is out of scope for this JSR. I suggest you try to find somewhere within the OpenJDK or GlassFish communities to make this suggestion.

I'm closing this issue, but wish you luck in pursuing it elsewhere.





[JSR348-68] Clarify that the JSPA is sufficient for contributions Created: 10/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[August 10 draft]

On line 194, change:

"the JSPA or an equivalent Contribution Agreement may make it impossible"

to

"the JSPA or an equivalent Contribution Agreement (the JSPA is preferable, and sufficient) may make it impossible"



 Comments   
Comment by eduardo [ 10/Aug/11 ]

I've added the suggested text

Comment by pcurran [ 17/Aug/11 ]

More work needed...

Comment by pcurran [ 08/Sep/11 ]

Whether the JSPA is preferable and/or sufficient will depend on exactly what contributions we're talking about (IP only, or code, for example) and how the Spec Lead is planning to license the resulting artifacts. After much legalistic discussion I conclude that it's inappropriate for us to be giving legal advice in the Process document.

So, let's put this back the way it was.

Please change "the JSPA or an equivalent Contribution Agreement (the JSPA is preferable, and sufficient) may make it impossible" to "the JSPA or an equivalent Contribution Agreement may make it impossible" and then close this.

Sorry for all the confusion.

Thanks...

Comment by pcurran [ 08/Sep/11 ]

Work around the assignment-display bug by closing and reopening

Comment by eduardo [ 08/Sep/11 ]

Reverted to original state





[JSR348-102] Harmonize Issue List and Issue list Created: 08/Sep/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: eduardo Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The latest changes (elimination of Change Log, introduction of Issue Tracker) have introduced both Issue List and Issue list to the Process document; a decision must be made as to whether this needs a new definition or whether it should be all referred as "issue list"



 Comments   
Comment by eduardo [ 08/Sep/11 ]

I've just realized that 348-71 provides a definition of Issue List, so this is not needed.

Comment by pcurran [ 08/Sep/11 ]

Agreed. (Unless you meant that I'd inadvertently used the term "Issue list" with mixed case.) Wherever the term appears it should be "Issue List."

I'm going to close this. Further comments can go into jsr348-71





[JSR348-91] State the document version explicitly in the Executive Summary Created: 17/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: eduardo
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Alex Buckley.

On line 19 of the PR draft change "This version" to "Version 2.8"



 Comments   
Comment by eduardo [ 22/Aug/11 ]

I think that would be a mistake – leaving it as is would save the user to have to go to the very top of the document to verify that they are indeed reading version 2.8; I'd rather not make this change

Comment by eduardo [ 22/Aug/11 ]

Please reopen this issue if you disagree with this disposition.

Comment by pcurran [ 22/Aug/11 ]

In the interests of full disclosure, this change was suggested by Alex Buckley. I asked him "Why? It reads just fine as it is." He responded:

"I believe in extreme clarity for narrative specs. The ultimate goal is being able to identify version-specific artifacts in a spec. Wikipedia gets it right:

http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28words_to_watch%29#Relative_time_references
http://en.wikipedia.org/wiki/Wikipedia:As_of

(One of the most valuable JVMS additions was documenting which class file content was introduced with which class file version. For the Process Doc, it would be nice to record which JSR introduced which Process. People will be grateful circa JCP 6.2 in 2024.)"

I guess we could say "This version (2.8)"

Comment by pcurran [ 22/Aug/11 ]

Reopeneing, since I suggested a compromise in an earlier comment.

Comment by eduardo [ 22/Aug/11 ]

I totally agree with Wikipedia on this, particularly as regards relative time references and lack of specificity, but the sentence in question is quite specific, as it identifies which JSR was used to produce this version. There is no need, in my view, to send the reader scrambling to verify that he/she is indeed reading version 2.8. In 2024 the reference will be to JSR 10456, and that will also be specific enough.

I still think it should not be changed, but I'm curious to know what others, particularly Alex, think about this.

Comment by eduardo [ 08/Sep/11 ]

I'm still waiting for any further comments on this

Comment by pcurran [ 08/Sep/11 ]

Looks good to me - please close this issue.

Thanks...





[JSR348-90] Do we need the defined term Release? Created: 17/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Alex Buckley thinks not (it isn't used very often, and he says "There's just so little to gain with the Release abstraction, and clarity can be lost."

I disagree. I think it's a useful shorthand.

Be that as it may, for now we should make the following changes to the Public Review draft:

  • On line 601 change "Release" to "release"
  • On line 552 change "Final Release or Maintenance Release" to "Release"


 Comments   
Comment by pcurran [ 23/Aug/11 ]

Would you please make the suggested changes and then close this?

Thanks...

Comment by eduardo [ 08/Sep/11 ]

Suggested changes have been implemented





[JSR348-101] Bad formatting in section 6.3 Created: 08/Sep/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Item #11 at line 654 of the August 22 draft is badly formatted. It's outdented compared to the remainder of the list and is separated from it by a blank line.



 Comments   
Comment by eduardo [ 08/Sep/11 ]

Done





[JSR348-61] Reference the issue tracker when discussing comments on "no" votes Created: 09/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

(From Scott Stark)

On lines 713-714 of the August 10 draft, change:

"No" votes must be accompanied by an explanation of the changes (if any) that would persuade the member to change the vote to "yes".

to:

"No" votes must be accompanied by references to the issue tracker items (if any) that if resolved differently would persuade the member to change the vote to "yes".



 Comments   
Comment by pcurran [ 09/Aug/11 ]

And an additional suggestion, derived from this issue: http://java.net/jira/browse/JSR348-62

Insert a new item in the JSR Voting Rules section, after the current item #3:

4. Any vote may be accompanied by comments. When comments include specific suggestions for change these should be logged in the issue-tracking mechanism to ensure that they are addressed.

Comment by eduardo [ 10/Aug/11 ]

I have introduced the suggested changes. For review before closing

Comment by pcurran [ 22/Aug/11 ]

I've verified that the suggested changes have been implemented in the PR draft

Comment by pcurran [ 25/Aug/11 ]

Reopening to suggest a consolidation of the two changes introduced earlier.

Comment by pcurran [ 25/Aug/11 ]

Item #9 on lines 718-719 of the PR draft reads:

"No" votes must be accompanied by references to the issue tracker items (if any) that if resolved would persuade the member to change the vote to "yes".)

Please append this text to item #4 at line #709 (thereby deleting item #9)

Thanks...

Comment by eduardo [ 08/Sep/11 ]

I've merged #4 and #9 as indicated





[JSR348-87] The definition of Profile Specification contains normative requirements that should be moved to the body of the document Created: 17/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Alex Buckley wrote in a comment on another issue "The definition of Profile Specification contains clauses that would be better in 2.1.3" (because they are normative requirements.)

The relevant clauses are "APIs from the referenced Platform Edition must be included according to the referencing rules set out in that Platform Edition Specification. Other referenced Specifications must be referenced in their entirety."

Section 2.1.3 certainly addresses Profile Specifications, but if we move this text into it we'll probably need to rename it.



 Comments   
Comment by pcurran [ 17/Aug/11 ]

I agree that definitions should not - if possible - contain normative requirements.

Yes, the definition of Profile contains some normative language. Yes, section 2.1.3 contains the word Profile in its title. However, looking at the content, it doesn't seem as if the material from the definition of Profile would actually fit there.

Moreover, the normative language in the definition is so closely tied to the previous sentence that separating them would make the whole thing more difficult to understand.

So - I propose we do nothing here





[JSR348-100] Spurious blank line in Process Document Created: 08/Sep/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There's a spurious blank line in Process Document (line 18 of the August 22 draft.)



 Comments   
Comment by eduardo [ 08/Sep/11 ]

Done - it was an artifact of underlying changes in the file not yet accepted.





[JSR348-95] Section 1.1.2 needs a little rewording to alleviate ambiguities Created: 23/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: lightguard Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-71 Issue Tracker should be a defined term Closed

 Description   

In section 1.1.2 it's stated that a publicly readable issue tracker should be used for the specification but implies users can add comments (doesn't say anything about the public being able to add issues). With all the explicit defining that has gone into the current drafts, should this be clarified a bit more to allow addition of issues / comments by the public or simple remove the word "readable" and simply go with "Issues must be tracked through a public issue tracking mechanism."?



 Comments   
Comment by pcurran [ 08/Sep/11 ]

The new wording proposed for section 1.1.2 in
JSR348-71 Issue Tracker should be a defined term addresses this concern.

I'm closing this issue. Further comments can be added to JSR348-71 if necessary.





[JSR348-8] The prohibition on employees of JCP Members voting or running for election as individuals doesn't go far enough Created: 01/Jul/11  Updated: 29/Aug/11  Resolved: 29/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-86 Improve clarity of Member definition Closed

 Description   

The new language that prohibits employees of member companies running for election or voting in their own right covers one important case but it does nothing to guard against the case where a company does not join the JCP in its own right, but instead encourages many of its members to join as individuals.

Suggested change: state that no more than five members of a company be permitted to join as individuals. (The PMO would have to police this, but they do have the means to do so through the Exhibit B's.)

We might want to similarly prohibit employees of non-profits, for example, Apache or Eclipse. (We should not impose similar prohibitions on JUG members.)

The distinction seems to be whether the "employee" (or, in the new broader terminology Member Representative is "empowered to act in the name of or on behalf of the organization.") If we can come up with a suitable definition here it might also address the point raised in email discussion that "employee" doesn't cover the case where someone is working for a company as a contractor.



 Comments   
Comment by keilw [ 03/Jul/11 ]

Should "employeec" of an NGO like Eclipse Foundation only target real staff e.g. Mike or Wayne, or would this apply to every member of such NGOs?

Comment by pcurran [ 03/Jul/11 ]

Employee means what it says: someone who is paid a salary by the organization. I don't know what you mean by "every member of such NGOs."

Comment by eduardo [ 08/Aug/11 ]

Two definitions have been modified:

Java Community Process Member (Member): A company, organization or individual that has signed the JSPA and is abiding by its terms. In the case of an individual, that person may represent himself/herself, or may represent or be otherwise empowered to act on behalf of a company or organization. No more than five individual Members are permitted at any one time as representatives of a company or organization.

Member Representative: A person who is an employee or agent of a Member company or a Member organization and who has been authorized by that Member to represent its interests within the JCP.

Comment by pcurran [ 09/Aug/11 ]

I suggest changing:

"No more than five individual Members are permitted at any one time as representatives of a company or organization."

to:

"No more than five individual Members may represent a company or organization at any one time."

(It's a little shorter and cleaner.)

Do we need to clarify that we don't consider JUG members as "representatives" of their organization, or do we need to explicitly state that? (I'm reluctant to add a formal definition for non-Member Representative)

Comment by pcurran [ 09/Aug/11 ]

Re-opening until my most recent comment is addressed.

Comment by eduardo [ 09/Aug/11 ]

The sentence "No more than five individual Members may represent a company or organization at any one time." is ambiguous, since it could be interpreted as "no more than five [...] can represent [...] at any one time throughout the JCP", which is not the intention. It should read ""No more than five individual Members may represent a given company or organization at any one time.", if I understand the intention correctly.

Comment by pcurran [ 09/Aug/11 ]

I don't understand your last comment.

My proposed text may well be ambiguous (though I don't understand why you think it is) but your proposed alternative seems identical

Comment by eduardo [ 09/Aug/11 ]

My alternative says "for any given company or organization, only five people can represent it"; your text says "only five people can be company or organizational representatives at any one time". Your text limits the total number of such representatives throughout the JCP to only five at any one time; my alternative limits them to five for each company or organization. Is this clearer?

Comment by pcurran [ 09/Aug/11 ]

OK - I now understand what you're saying.

However, your text doesn't actually say "for any given company or organization" any more than mine does.

We both use the term "a company or organization" and I still maintain that we're saying the same thing, only I'm saying it in a few less words.

However, this is nit-picking and we've spent more words discussing it than we might have saved. If you prefer your version then OK. Let's move on to something more important.

(My main point was that we're not explicitly dealing with the JUG situation. Let's see whether others are concerned about that...)

Comment by keilw [ 17/Aug/11 ]

Are JUGs the only organizations this should cover? I know, Patrick specified earlier, "employee" was the only formal member of such group, so except people on its payroll like e.g. Mike or Wayne for Eclipse, anybody who is a committer to Apache, Eclipse or similar foundations wouldn't count?

I hope that anwers above question, too? With "every member" I mean people who signed a committer agreement similar to the JSPA with any of these organizations.

Comment by pcurran [ 25/Aug/11 ]

I'm closing this issue. Let's take the discussion to the related (linked) issue http://java.net/jira/browse/JSR348-86

Comment by pcurran [ 29/Aug/11 ]

Temporarily reopening to fix the (circular) link in my last comment.

Comment by pcurran [ 29/Aug/11 ]

And now closing again





[JSR348-4] Should Maintenance Leads be obliged to provide the final materials within a specified time-period after Maintenance Review? Created: 01/Jul/11  Updated: 26/Aug/11  Resolved: 25/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-56 Define the the time-out periods Closed

 Description   

Should Maintenance Leads be obliged to provide the final materials within a specified time-period after Maintenance Review?

We agreed that this would be difficult to implement since there are no penalties that we can impose.

Some possibilities:

  • Ask the ML to provide an estimate of the time they expect to deliver the final materials.
    • This can't hurt, and might help the PMO to follow-up, but of course would be non-binding.
  • Require the ML to go through Maintenance Review again if they fail to deliver final materials within a specified perios.
    • The second review couldn't force a change, but this would at least be an incentive for the ML to follow through.
  • Declare the JSR Dormant if the ML doesn't deliver within a specified period.
    • How to get out of this state? Presumably this would need another Maintenance Review, in which case this suggestion is almost the same as the second.
      • It would apply some extra pressure on the ML.


 Comments   
Comment by pcurran [ 29/Jul/11 ]

Patrick to open this up for discussion on the alias.

Comment by Bill Shannon [ 08/Aug/11 ]

I think it's perfectly reasonable to say that the ML MUST provide an estimate for when
the final materials will be provided.

Failure to provide the final materials should be handled in the same way as a regular
JSR failing to progress through the process. (I thought timeouts were going to be
added to the process, but I'm not seeing them right now.)

Comment by pcurran [ 08/Aug/11 ]

Copying some comments from the general discussion alias, just to keep everything in one place.

Ben Evans said, responding to my summary of the current draft:

This seems sensible to me. I agree that it's a bit more convoluted than seems ideal, however I can't see any good way to optimise this.

Basically, the intent that I'm seeing here is:

  • If there are any No votes on particular items, then these items should be remediated or removed (possibly with an Item Exception Ballot to check that there is consensus for required modification of the items).
  • If this is the case, then I think there should definitely be time limits imposed on the ML to provide fixes for the items with objections, or to drop the offending item from the Maint release. I would suggest 90 days as a possible time limit for fixes (unless there's a more suitable time limit already present in the process).

Mike DeNicola responded:

I agree with Ben’s suggestion.

In addition, I believe that the ML should provide target dates for an updated Spec and, if necessary, updated RI and TCK, to the PMO.

Scott Stark added:

We agree an exception ballot is required if any no votes exist, and we like the time limit proposed.

Comment by pcurran [ 08/Aug/11 ]

Responding to Bill Shannon's comment

Timeouts have been implemented - see section 0.2 JSR DEADLINES and the JSR Renewal Ballot process.

However, we haven't specified any timeouts for the Maintenance process, and I don't believe it would be appropriate to do so.

While it's reasonable to shut down a JSR that starts but never completes, I don't think it's ever appropriate to "shut down" a JSR that has completed (done a Final Release) just because it hasn't made a Maintenance Release in a particular period of time. (And, what would it mean to "shut down" a JSR that had already completed?)

Bottom-line: if we're going to insist on any kind of deadline (even one supplied by the ML him/herself) then we need a penalty. There aren't many options, but one possibility would be to require another Maintenance Release Ballot.

Comment by Bill Shannon [ 16/Aug/11 ]

I'm not suggesting shutting down a JSR because it hasn't done an MR.

I'm suggesting shutting down an MR because it hasn't progressed.

Since the MR process is just a lightweight alternative to a full JSR for revising a spec,
it seems perfectly reasonable to shut down that spec revision whether it's being done
with a JSR or an MR if it fails to make progress. The timeout starts when the JSR or MR
is submitted, and stops when the JSR or MR delivers the final materials.

Comment by pcurran [ 25/Aug/11 ]

OK. I think we now have agreement. There will be a time-out period (90 days has been suggested) from the submission of the Maintenance Review materials to completion (Maintenance Release.) If the release is not made within this period the MR will be "rescinded" (that's the best term the PMO has been able to come up with so far) and the ML must start again with another Maintenance Review (and ballot.)

I'll incorporate this into the next write-up of the MR process.

All we now need to decide is the exact time-period. We have at least a couple of votes for 90 days. Does anyone think this is too short?

Comment by pcurran [ 25/Aug/11 ]

Since we already have an issue to define the time-out periods (http://java.net/jira/browse/JSR348-56) I've linked this issue to that one. Now we can close this.

Comment by pcurran [ 25/Aug/11 ]

Since we already have an issue to define the time-out periods (http://java.net/jira/browse/JSR348-56) I've linked this issue to that one. I will generalize that issue, allowing us to close this.

Comment by Bill Shannon [ 25/Aug/11 ]

90 days is too short.

We often file MRs well in advance of the final release of the RI for the
platform. Knowing that the MR is approved and all we have to do is deliver
it helps reduce risk for the platform delivery. Being forced to submit all
MRs within 90 days of the final release, when we're trying to stabilize the
release, introduces unnecessary risk.

I greatly prefer the previous suggestion of asking the ML to specify when
the final materials for an MR will be delivered, and otherwise using the
general "JSR has failed to make progress" timeout mechanisms.

90 days between FAB and FR might be reasonable, and I understand this introduces
an asymmetry between a JSR and an MR, but it reflects our desire for MRs to be
low risk lightweight events.

Comment by pcurran [ 26/Aug/11 ]

This issue is closed. I've copied your comment to http://java.net/jira/browse/JSR348-56 where the discussion should continue. Check there for my response.





[JSR348-32] Make the requirement to maintain a Change Log optional? Created: 29/Jul/11  Updated: 25/Aug/11  Resolved: 25/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-70 Simplify Maintenance Review process b... Closed

 Description   

Bill Shannon said, in comments on the draft document,

"We don't really do this. I think this is one are where I'd like
less to be specified by the process document. Or turn this into a
suggestion/recommendation rather than writing it as a requirement."

For the record, I disagree. The Maintenance Process is already too "loose."



 Comments   
Comment by lightguard [ 29/Jul/11 ]

I'm with you pcurran. There are many times I've looked at a spec or MR simply to get a basic idea what has changed between revisions, then I can dive into the sections that interest me the most (for using the spec, not for implementing of course). I'm sure there are others that do the same. Having to sift through Google results or blog entries is not an efficient way of determining what has changed, nor is reading the whole spec. Some specs such as the EJB spec, JSF, JDBC, etc are hundreds of pages long. A change log is a must for getting a feel for what has changed in versions.

A possible thought if a change log is not required in the release is to keep the same issue tracker as the previous spec, where possible. A person could look through milestones / versions to see the differences (and also discussions leading up to the change(s)). Even still, my vote is with keeping the change log as a required item.

These are my own thoughts and are being posted as an individual. They may or may not be the same as my current employer.

Comment by pcurran [ 05/Aug/11 ]

Need more outreach to Spec Leads...

PMO to set up a concall to encourage Spec Leads to provide feedback during the Public Review period...

Comment by Bill Shannon [ 05/Aug/11 ]

It would be interesting to look at previous MRs to see how many of them follow
exactly the format described by the JCP.

I think the intent is good, but the JCP document is overly specific on the format
of the information. I think it would be sufficient to simply require that the MR
submission indicate the changes included in this MR, the changes proposed but deferred,
and the changes proposed but rejected. Those lists could be provided by issue
tracker queries, for instance.

For that matter, assuming use of an issue tracker, anyone should be able to determine
the deferred and rejected changes. All that's really critical is to indicate which
changes are part of this MR.

Comment by lightguard [ 05/Aug/11 ]

To Bill's comments, this is the very reason I'd prefer to at least have JSRs using issue trackers. If it's in the spec awesome, but at a bare minimum all the info should be able to be easily discovered via an issue tracker query or two.

It may be worthwhile to take a look at how Red Hat is doing this with the CDI specification. I think pretty much all of the communication is done via JIRA for that JSR currently. I listen to the mailing list, and IIRC, nearly all of the traffic as of late has been updates / changes to JIRA tickets. It keeps everything open, the community can speak with the expert group and feel like they're being heard, history is tracked, and queries can be run against the tickets. You can also vote or watch specific issues that have interest to you and you don't even need to sign up for the mailing list. Seems like a far superior way of doing things, imo.

Comment by pcurran [ 06/Aug/11 ]

Again responding to Bill...

I have no problem with "relaxing" the specification of the form so long as the requirements for the content are tight. (See, for example, my suggestions for the issue-tracking requirement in this comment )

However, I do have a problem with asking people to "determine the deferred and rejected changes" by scanning an issue-tracker log.

One of the serious problems with the currently (under-) defined process, which doesn't even require that the ML update the spec, is that some MLs expect implementors to figure out for themselves how some random comments in a change log (which Bill now informs me may not even exist!) should be translated into specific changes in a written specification.

So - by all means let's say "the ML must publish a list of suggested changes, and indicate which are proposed for the upcoming release and which are to be deferred" but let's not say "go figure it out for yourself by reading the messages on this mailing list and the comments on this issue tracker."

Comment by Bill Shannon [ 07/Aug/11 ]

Again, I strongly support the intent. An MR should clearly describe what changes
are being made to the spec. I don't object to also clearly describing what
requested changes are deferred or rejected. But for the latter two I think it
should be sufficient to reference an issue tracker, e.g., by providing a URL
that searches for issues of the given type. There should be no requirement to
copy that content into a single "change log".

As for the changes to the spec, I would strongly support a requirement to provide
a list of what's being changed, as well as an updated version of the spec itself
so that the applied changes can be reviewed unambiguously.

It's only the format of the required "change log" that I object to.

Comment by pcurran [ 09/Aug/11 ]

As I suggested in my earlier comment, I'm OK with relaxing the definition of Change Log so that it specifies the required content rather than the form in which the information should be provided, so long as the content must be provided unambiguously.

References to issues (or reports on issues) would be OK. (However, I haven't figured out a simple way to tag things in JIRA for this purpose.)

Note, however, that we have added requirements that the "Change Log" also specify changes to the RI, TCK, and licenses. So long as these are conveyed to the PMO and published by them that would be OK.

(Strictly speaking, that's all that's required today. We define the Change Log as "An area accessible from the JSR Page that lists all changes made to the Specification, RI, TCK, and licenses since the previous Release.")

Comment by pcurran [ 16/Aug/11 ]

Bill Shannon has provided a detailed proposal to address this question in another issue (see http://java.net/jira/browse/JSR348-70)

Please follow up there.

Comment by pcurran [ 16/Aug/11 ]

Please follow up there.

Comment by pcurran [ 25/Aug/11 ]

In preparation for closing this issue (we're taking the discussion to JSR348-70) I'm adding a link to that issue.

Comment by pcurran [ 25/Aug/11 ]

We've agreed in principle to do this, so now we just need to work out the details. We can do that in http://java.net/jira/browse/JSR348-70 (now linked from this.)

So, I'm closing this, as part of a general cleanup in this area.





[JSR348-62] Add an additional vote type to section 6 called "Conditional Yes" Created: 09/Aug/11  Updated: 25/Aug/11  Resolved: 25/Aug/11

Status: Closed
Project: jsr348
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mojavelinux Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

(This issue is raised by me on behalf of Red Hat).

In the JSR Review and Public Review ballots, an EC member will often cast a vote of "Yes" with a conditional clause in the comments section. There should be a formal process for addressing these conditions, perhaps tracked in the same manner as a specification issue.

One proposal is to introduce a "Conditional Yes" option on the ballots. This means the voting EC member agrees with the JSR in principal, but has one or more issues that the voting member would like to see addressed before the next vote. The comment would be converted to a spec issue and would require that it be handled like any other issue (rejection is a possible resolution, provided there is a reason given).

If the issue is not addressed to the voting member's satisfaction, that may translate in a "No" vote. The important part is that the reason for the change is traceable.

This proposed process gives the public a more open view of what the EC views as problems in the spec, or how it relates to other specifications.

The current scrolling text box that is used to display comments is very difficult to read. We would like to propose that each comment is separated into individual blockquote elements, each with a header that includes the name of the voting member. Ideally, those headings would be referencable (with anchor tags).

Additionally, a public Item Exception section in the ballot results page would prevent issues from being forgotten. The new vote type allows for an expression of issues, yet would still allow the vote to be counted as a "Yes" vote toward moving the JSR forward. It's a more formalized way of what's currently being done (either abstaining or voting no and leaving a comment).

This request extends the motivation of the Item Exception Ballot for a Maintenance Review to to JSR Review and Public Review Ballot.



 Comments   
Comment by pcurran [ 09/Aug/11 ]

Hmmm...

This is really three separate issues in one. Please separate them. (On second thoughts, no need to log an issue about the way in which the votes are displayed on jcp.org - this is way out of scope for the Process Document, being simply an implementation detail.)

As for your first suggestion, I've already created a similar issue (prompted by comments on the Experts alias from Scott Stark of RedHat)- see http://java.net/jira/browse/JSR348-61 - in which I suggest that issues should be logged when someone votes no with comments.

Now that I think about it, we should generalize the language to suggest that "yes with comments" (which already is permitted and even encouraged) should also be accompanied by filing one or more issues.

I'll generalize that issue to cover both cases.

Thanks for the suggestion.

Comment by mojavelinux [ 09/Aug/11 ]

Great. Thanks for following up.

Regarding the display of the comments on the jcp.org, while it may seem like an implementation detail, it's a pretty serious issue. The current layout favors the comments of a limited set of voters' comments that are visible, while other comments are hidden below the scroll.

To make this point fit in the process document, I suggest that it be clear that "comments should have equal visibility on the ballot page".

The current layout can be perceived by some as an intention to downplay the comments by making them easy to miss (even though I trust that in reality it was an inadvertent outcome). (Please note that is not an accusation, it's a suggested improvement to avoid such conclusions being made).

Comment by pcurran [ 09/Aug/11 ]

The scrolling list may not be pretty, and it's certainly not state of the art, but I think you're exaggerating the significance. If people can't be bothered to scroll down to view all the comments then I'm afraid I don't have a lot of sympathy for them. (Would you similarly require that a JSR proposal be no longer than can fit in a web-browser without requiring the user to scroll down, on the grounds that material "below the fold" would therefore be discriminated against?)

Be that as it may, our lone web-engineer is so overloaded with more critical matters that this is unlikely to get attention in the forseeable future. I will log it as an internal enhancement request, but I still maintain that it's out of scope for the Process Document no matter how you word the request.

Sorry...

Comment by pcurran [ 25/Aug/11 ]

I'm closing this issue since the essence of the original suggestion (to tie comments on votes to issues) has been addressed in http://java.net/jira/browse/JSR348-61.

There was further discussion on the alias about the specific suggestion to formally define "conditional yes" and "conditional no" votes. For the record, here's what Scott Stark suggested:

We should define the notion of conditional yes/no votes you introduce in the first part of the message along the lines of:

Conditional Yes Vote, a yes vote in a ballot that references one or more Issues that must be resolved in order for the yes vote to be awarded in the next phase of balloting.

Conditional No Vote, a no vote in a ballot that references one or more Issues that must be resolved in order for the vote to be changed to a yes vote in the next phase of balloting.

I responded to this by saying:

There's value in mentioning the concepts but there would be no need to formally define them unless we need to use the terms again. We might be able to achieve the same effect more economically by having an Issue state of "critical" or "showstopper" or whatever.

Considering the discussion at this morning's Working Group meeting, and the resolution of http://java.net/jira/browse/JSR348-61 it doesn't seem as if formal definitions will be necessary. We can repopen this issue if necessary.





[JSR348-69] The Standing Rules document should have a version number Created: 11/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While the Process Document has its own version number (2.8) the Standing Rules will presumably change on a different schedule, and therefore should have its own version number.

I suggest we start with 2.0 (the 2 can match the current version of the Process itself.)



 Comments   
Comment by eduardo [ 22/Aug/11 ]

Done, version 2.0 it is





[JSR348-6] The TCK documentation must contain Compatibility Requirements Created: 01/Jul/11  Updated: 22/Aug/11  Resolved: 10/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 3.1 states that the TCK documentation must contain Compatibility Requirements.

We should specify some specific requirements in the Process Doc and then provide some more detailed examples in the (non-normative) Spec Lead Guide.



 Comments   
Comment by Bill Shannon [ 08/Aug/11 ]

Add another bullet to the bullet list in section 3.1.:

  • Includes requirements that all compatible implementations (a) fully implement the
    Spec(s) including all required interfaces and functionality, and (b) do not modify,
    subset, superset, or otherwise extend the Licensor Name Space, or include any public or
    protected packages, classes, Java interfaces, fields or methods within the Licensor
    Name Space other than those required/authorized by the Spec or Specs being implemented.
    These requirements must apply unless the Spec or TCK explicitly allows exceptions.

This echoes the requirements from the JSPA.

Comment by pcurran [ 08/Aug/11 ]

NOTE: in the August 10 draft the relevant section is 4.1, beginning on line 506.

Looks good, except that it should say "Include requirements" rather than "Includes requirements"

Comment by Bill Shannon [ 08/Aug/11 ]

Back to Eduardo for incorporation into the document.

Comment by eduardo [ 10/Aug/11 ]

Suggested edits have been incorporated. Waiting for review before closing

Comment by pcurran [ 16/Aug/11 ]

The reference to compatibility requirements in the first bullet and also in the second is a bit awkward. I suggest the following change, which isn't perfect, but I think a little better:

Starting on line 507 of the PR draft, change:

The TCK submitted as part of the Final Draft must meet the following requirements:

  • Include documentation covering configuration and execution of the TCK, a definition and explanation of the First-level TCK Appeals Process, the compatibility requirements that must be met in addition to passing the TCK tests, and any other information needed to use the TCK (e.g. Tools documentation).
  • Include requirements that all compatible implementations...

to:

The TCK submitted as part of the Final Draft must meet the following requirements:

  • Include documentation covering configuration and execution of the TCK, any other information needed to use the TCK (e.g. Tools documentation,) a definition and explanation of the First-level TCK Appeals Process, and the compatibility requirements that must be met in addition to passing the TCK tests,
  • The compatibility requirements at a minimum must specify that all compatible implementations...
Comment by eduardo [ 22/Aug/11 ]

I have implemented all suggested changes





[JSR348-29] Fix typos (pointed out by Bill Shannon) Created: 29/Jul/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All line numbers refer to the 29 July Clean version of the Process Document



 Description   

Line 21: change "through the JCP" to "using the Java Community Process itself"

Line 41: change "circulate" to "circulates"

Lines 191-192: delete "modifications to the reference implementation or the TCK,"

Line 195: change "should" to "may"

Line 295: change "of" to "after"

Line 330: change "delivered as" to "delivered only as"

Line 177: change "email aliases" to "mailing lists"

Line 358: change "alias" to "mailing list"

Line 392: change "alias" to "mailing list"

Line 670: change "new Platform Edition Specifications" to "additional Platform Edition Specifications"



 Comments   
Comment by eduardo [ 29/Jul/11 ]

I have implemented the suggested changes except for changes to lines 191-192, 195 and 670, as I thought further discussion may be needed.

Comment by pcurran [ 30/Jul/11 ]

The line 670 change is definitely correct (we had extensive discussions about this a couple of years ago, and it matches the way we have interpreted this text over the years.)

We could discuss 101-192 further, but I thought since it's simply an example (contained within a "should" statement) it would be simpler just to accept the proposal. (Bill's statement that the Spec Lead typically doesn't consult the EG about RI and TCK implementation details is correct.)

As for 195, Bill simply stated that Java EE EGs typically don't exclude these "administrative" matters from the public alias (as indeed I have not with JSR 348) and therefore "may" is more appropriate. A counter-argument would be that "should" does not require, and the recommendation is good practice.

If we're going to keep some of these open for further discussion we really should open separate issues.

Comment by eduardo [ 01/Aug/11 ]

In view of Patrick comments I have proceeded to implement the suggested changes to line 670 and lines 191-192. I have not implemented the suggested change to line 195 because I agree with Patrick that there is no obligation in "should".

As to opening separate issues, I think that just leaving this issue as "incomplete" until we come to an agreement achieves the same result without unnecessarily increasing the number of issues.

Comment by pcurran [ 05/Aug/11 ]

At a Working Group meeting on August 5 we agreed to close this issue without making the change suggested by Bill on line 195, since "should" does not require, and the recommendation is good practice.

All other changes noted in this issue have been implemented.

Comment by Bill Shannon [ 05/Aug/11 ]

Note that many of our engineers will read "should" in the process document as a
requirement on what they do. It's unfortunate if we have to maintain a separate
document that says "you can ignore that requirement of the JCP process". I'd
prefer that all the usages of "should" match what we actually do.

I understand that "should" means "do it that way unless you have a darn good reason
not to". That's a very high bar, and sometimes our reason is just "it's easier if
we don't".

Comment by eduardo [ 05/Aug/11 ]

It is common practice in many standards organizations to make reference to RFC 2119 to clarify the use of must, should, etc.in their process documents.Others refer to the similar (but not exactly equal) practice at ISO wrt these words. Should we do so here too?

Comment by pcurran [ 06/Aug/11 ]

Yes.

Comment by eduardo [ 22/Aug/11 ]

I have added at the end of "II Definitions" the following clarification:

The use of the words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optional" in this document is done in accordance with the IETF's RFC 2119.





[JSR348-48] Should the PMO be referred to as "who" or "which"? Created: 05/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Harold Ogle suggests that throughout the document the term "PMO" should be followed by "which" rather than by "who."

If we make this change, search for "PMO, who"



 Comments   
Comment by pcurran [ 05/Aug/11 ]

Comments from Working Group discussion on August 5:

Patrick: Strictly speaking this is correct, but to me the term "who" seems more natural.

Eduardo: "which" is preferable - don't want to imply that the PMO is one person.

Martijn: the use of "who" can humanize the organization - make people more willing to participate.

We agreed that we need further discussion.

Comment by eduardo [ 05/Aug/11 ]

I've looked at all the places where it says "PMO, who", and I agree with Harold that it should say "PMO, which". Another way to deal with this would be to replace "PMO, who" with "the PMO representative, who", as in "must be reported to the PMO representative, who" – but that immediately poses the question of who is the PMO representative (or assignee, or gofer, or whatever)

Comment by pcurran [ 17/Aug/11 ]

As agreed at this morning's Working Group meeting, please make the change from "who" to "which."

Thanks...

Comment by eduardo [ 22/Aug/11 ]

I have implemented the change from "who" to "which"





[JSR348-26] What happens if no agenda is published in advance? Created: 28/Jul/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: eduardo Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There must be an Agenda – what happens if there isn't one? Specify that in the absence of an agenda the meeting must proceed under the same rules as when there is no quorum.



 Comments   
Comment by eduardo [ 29/Jul/11 ]

Text was inserted: "...otherwise the meeting will proceed as if there was no quorum, regardless of the number of actual participants."

For review before closing.

Comment by pcurran [ 05/Aug/11 ]

Eduardo: please check that current wording ensures that the Chair cannot maliciously deny the opportunity to debate and to vote on issues that EC members consider important.

Comment by pcurran [ 05/Aug/11 ]

Mike DeNicola - alternative solution

Those present at the meeting should establish an agenda at the beginning of the meeting.

Eduardo: this is inefficient

Bruno: should be possible to generate an agenda on the fly if meeting is quorate.

John: should always be an opportunity to add items to the agenda.

Need more discussion with full EG at next week's meeting

Comment by pcurran [ 05/Aug/11 ]

Reopening, pending further discussion of the whole "for discussion/for action" area.

This will be on the agenda for the August 10 EC/EG meeting.

Comment by eduardo [ 10/Aug/11 ]

I have changed the text to say:

"The Chair should email the final agenda 4 calendar days before a meeting. Absent an agenda, the EC members present at the meeting may agree on one at that time, and proceed accordingly."

Note that I have changed "the Chair must" to "the Chair should", since there is no possible enforcement with the way the whole paragraph has changed, and whether the Chair does or does not send an agenda is somewhat irrelevant.

Comment by pcurran [ 16/Aug/11 ]

I believe that the new text captures the sense of the discussion at the recent EC meeting.

Let's close this. People can always reopen if they wish.

Comment by eduardo [ 22/Aug/11 ]

I am reopening this only to change the resolution status from "incomplete" to "fixed"





[JSR348-85] Improve clarity in 4.2 signature tests Created: 17/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Buckley Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The final bullet in the "TCK submitted as part of the Final Draft" requirements would be more readable as:

"Provide 100% signature test coverage. These tests must ensure that all of the API signatures required by the spec are completely implemented, and that only API signatures required by the spec are included in the JSR's namespace."



 Comments   
Comment by pcurran [ 17/Aug/11 ]

Please make the change Alex suggests.

Thanks...

Comment by eduardo [ 22/Aug/11 ]

I have implemented the suggested change





[JSR348-82] The definition of Dormant needs clarification Created: 17/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Buckley Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

What is a "life cycle"? It's not defined elsewhere.



 Comments   
Comment by pcurran [ 17/Aug/11 ]

The full definition is:

Dormant Specification (Dormant): A Specification that does not have an identified Specification Lead or Maintenance Lead. All Specifications become Dormant at the end of their life cycles.

I agree that the second sentence is problematic. I know what it's trying to say - "all specs become Dormant when they become dormant" but that doesn't help much.

We could just delete that sentence, but I'm not sure about the first one either. The intent of the second sentence is to suggest that there's a point at which all specs naturally reach a stable state (when no further work will be carried out on them.) However, this isn't captured in the first sentence. There may well be an identified ML. In fact there always is (the last Spec Lead) unless something has been brought to our attention. This doesn't mean that that person is actively maintaining, or ever will maintain the spec.

What this should really say is something like "a spec that is not being actively developed." This would bring it more into line with the only usage of the term in the document, in section 5.1.1 RELINQUISHING OWNERSHIP, where we say "If no replacement can be found, or if the Transfer Ballot fails, then the PMO will declare the Specification to be Dormant and no further maintenance can be carried out."

I'm going to rename this issue to "The definition of Dormant needs clarification."

Comment by pcurran [ 17/Aug/11 ]

Change the definition to:

Dormant Specification (Dormant): A Specification that is not being actively developed and on which no further development is anticipated, or that the PMO has determined has no assigned Specification Lead or Maintenance Lead."

Comment by pcurran [ 18/Aug/11 ]

On second thoughts, it would be better to reverse the two cases in the definition, since the formal assignment of the Dormant label is more important than the informal usage "all specs become Dormant eventually..."

So, the definition should read:

"A Specification that the PMO has determined has no assigned Specification Lead or Maintenance Lead, or that is not being actively developed and on which no further development is anticipated."

Comment by pcurran [ 18/Aug/11 ]

Please implement the change in my last comment.

Thanks...

Comment by eduardo [ 22/Aug/11 ]

I have implemented the change suggested in the last comment in the thread





[JSR348-76] Minor language changes suggested by Alex Buckley Created: 16/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

The PR draft


Issue Links:
Duplicate
duplicates JSR348-81 "Dormant" definition mentions "life c... Closed

 Description   

On line 32 change "community member(s)" to "one or more Members"



 Comments   
Comment by eduardo [ 22/Aug/11 ]

I've implemented the suggested change





[JSR348-80] Strange artifact at the top of the Process Document Created: 16/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File artifact.jpg    

 Description   

Can't describe it - see the attachment for a screen-shot.

(Hey - the image-attachment display in the bug-report is pretty slick!)



 Comments   
Comment by eduardo [ 22/Aug/11 ]

I have deleted the pixels wide graphic that was causing this





[JSR348-78] More refactoring (into Expert Group Membership) Created: 16/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Alex Buckley:

Section 2.4: Propose moving the 2nd and 3rd paras to new subsection in 1.2. Since EG members can be added at any time, the properties of a well-formed EG (size, modification, multiple Reps from one Member) don't belong in section 2.



 Comments   
Comment by pcurran [ 16/Aug/11 ]

Sounds reasonable and non-controversial. Would you please make the change?

Comment by eduardo [ 22/Aug/11 ]

I have implemented the suggested change





[JSR348-75] Restucture the Executive Summary section Created: 16/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

(From Alex Buckley)

Move this paragraph:

"This version of the JCP was developed using the Java Community Process itself by means of JSR 348, led by Oracle and the combined Executive Committees as the Expert Group"

to end of the section.



 Comments   
Comment by eduardo [ 22/Aug/11 ]

I have moved the para in question to the end of the section





[JSR348-72] Require EGs to maintain a public Document Archive Created: 12/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is probably implicit in the requirement to conduct business in public, but we should make it explicit.

Add some language requiring EGs to maintain a publicly-accessible Document Archive, from where all of their working materials such as meeting agendas and minutes, draft documents, etc. can be downloaded.

See our own Document Archive for an example.



 Comments   
Comment by pcurran [ 18/Aug/11 ]

Starting on line 176 of the PR draft, change:

"As specified below, Expert Groups must operate in a transparent manner, enabling the public to observe their deliberations and to provide feedback. All feedback must be taken into consideration and public responses must be provided. In the initial JSR submission the Spec Lead must specify the transparency mechanisms (for example, the mailing lists and issue tracker) that the Expert Group intends to adopt..."

to this (note that I've broken the text into two paragraphs):

"As specified below, Expert Groups must operate in a transparent manner, enabling the public to observe their deliberations and to provide feedback. All feedback must be taken into consideration and public responses must be provided. They must maintain a publicly-accessible document archive, from where all of their working materials such as source documents, meeting agendas and minutes, and draft documents can be downloaded.

In the initial JSR submission the Spec Lead must specify the transparency mechanisms (for example, the mailing lists, issue tracker, and document archive) that the Expert Group intends to adopt..."

Comment by eduardo [ 22/Aug/11 ]

I have implemented the suggested change.





[JSR348-59] Simplify Mailing Lists section Created: 09/Aug/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: starksm64 Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In 1.1.1 Mailing Lists, lines 202-214 of the http://java.net/projects/jsr348/downloads/download/Working%20documents/JCP%20NEXT%202.8-10AUG2011-Clean.pdf version of the process doc, there is a discussion about why a private mailing list is needed for minor admin issues. This seems overstated and based on the following comment from the closed JSR348-40 issue:

I don't understand why we cannot simply have one moderated list.

EG members would have automatic read/write access to the list
non-EG members would have read access to the list and all write access would be moderated (allowed upon approval)
Since all debates are tracked via the issue tracker, observers have the alternative option of commenting on the issue report.

I suggest this setup because it's used almost universally for open source projects and has proven to work (and scale). Plus, anyone familiar with open discussions will understand this model.

Sending discussions from one list to another, in my opinion, is just making matters more complex than necessary.

is seen as suspicious. I would suggest a much simplified section that would allow for a purely administrative list if that is how the EG decides it needs to conduct business, but does not advocate it.

"All substantive business must be carried out on a public mailing list designated by the Spec Lead. The
purpose of this list is to keep observers aware of important issues. The preferred way to conduct the mailing
list is a moderated list.

If the Expert Group uses a mailing list writable only by Expert Group members, then the EG must also
provide a publicly readable and writable email list or a forum to enable feedback and comments from
the public."



 Comments   
Comment by pcurran [ 09/Aug/11 ]

Throughout the document we try to specify what Expert Groups should do without specifying how they should do it.

So, for example, we do not suggest or recommend having an Experts and an Observers list, with mail from the first copied to the second, as we are have with this JSR.

For this reason, I don't think it's appropriate to recommend a moderated list. That might well be how people choose to meet the requirements, but depending on the collaboration platform the EG chooses, it may or not be convenient or even possible. (As it happens, java.net does not seem to support the concept of moderation for some subscribers and not for others. I certainly wouldn't want to have to approve every single posting to the Experts list.)

The important part of the mailing-list section of the document is the requirement that all substantive business (and we provide examples to indicate what this includes) should be carried out in public. So long as EGs meet this requirement, how they do so is their business.

I agree that the use of the term "should" in "Non-substantive administrative matters ... should be excluded from the public mailing list" implies that we are recommending two lists rather than one.

I'd be happy to change this to "may" in order to make this sentence more neutral.

Comment by lightguard [ 09/Aug/11 ]

Patrick, not to throw a wrench in the works, especially since we're very close to Public Draft, would it not make more sense (and to a point future proof) to drop the mailing list requirement and term it communication, or something similar? Especially in light of new group communication mediums such as the now defunct Google Wave project do we want to mandate that communication must happen through an email list?

Comment by pcurran [ 17/Aug/11 ]

This has now morphed into two suggestions:

1) recommend a moderated mailing list.

We're not going to do that for the reasons I've already stated. We will change the "should" to "may" in discussing the use of a private list for administrative matters and then close this issue.

2) generalizing the concept of "mailing list"

I've opened a new issue for this suggestion: http://java.net/jira/browse/JSR348-84

Comment by pcurran [ 17/Aug/11 ]

On lines 203-204 please change:

"A private mailing list should be used for minor administrative matters."

to:

"A private mailing list may be used for minor administrative matters."

Then please close this issue.

Thanks...

Comment by eduardo [ 22/Aug/11 ]

I have implemented the change proposed in the last comment in this issue thread.





[JSR348-36] The Item Exception Ballot process is under-specified Created: 29/Jul/11  Updated: 18/Aug/11  Resolved: 18/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by lightguard [ 07/Aug/11 ]

The term "Item Exception Ballot" on line 88 in the process document should be bold.

Comment by pcurran [ 18/Aug/11 ]

The summary of this issue doesn't match the description inside. (The definition formatting problem has in fact been fixed.)

Be that as it may, since it seems that we're going to abolish the Item Exception Ballot, or perhaps significantly modify it I'm closing this issue as unnecessary. (We have plenty more issues relating to the Maintenance process!)





[JSR348-73] Should the process for modifying the Standing Rules document be specified in the Process Doc? Created: 12/Aug/11  Updated: 18/Aug/11  Resolved: 18/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc, Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It might be more appropriate to define the process for modifying the Standing Rules document in the Process Document, since some of the material has been moved from the Process Doc to the Standing Rules. (Also, since the Process Document has a more "formal" status.)



 Comments   
Comment by eduardo [ 12/Aug/11 ]

But then a change in the way Standing Rules are modified would necessitate a JSR.

Comment by pcurran [ 12/Aug/11 ]

No - we would simply copy the existing text, which describes the lightweight change process, from the Standing Rules document to the Process Document.

We would have to do a JSR to change the process for changing the Standing Rules

Comment by eduardo [ 12/Aug/11 ]

That's what I meant: once the standing-rules-changing-process is in the Process document, you'll need a JSR to change the standing-rules-changing-process, and I'm not sure that's desirable. And while the Process document has a more "formal" status, as you say, (does it?) the Standing Rules document is as normative as the Process document, so I'm not sure I buy the argument that the later is more appropriate.

Comment by pcurran [ 18/Aug/11 ]

OK - it was a passing thought.

Better to keep the two documents as separate and independent of each other as possible.

I'm closing this.





[JSR348-18] 1.5.2 - Add GitHub to the list of approved collaboration software Created: 19/Jul/11  Updated: 17/Aug/11  Resolved: 20/Jul/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Doc Section 1.5.2: "We must ensure that java.net is on the Approved List."

GitHub is clearly a first-rate collaboration suite, and should be whitelisted.



 Comments   
Comment by lightguard [ 19/Jul/11 ]

+1

GitHub, CodeHaus, Google Code, Bitbucket, etc.

Comment by pcurran [ 20/Jul/11 ]

There will be no list of approved collaboration software (you seem to be working from the out-of-date JSR1 list rather than from the actual draft of the Process Document.

Comment by lincolnbaxter [ 22/Jul/11 ]

So this section has already been stricken from the document?

These ideas were drafted by an independent group reviewing the Early Draft from June 21, 2011 - apologies for out-of-date issues.

Comment by starksm64 [ 29/Jul/11 ]

The June 22 minutes (http://java.net/downloads/jsr348/Meeting%20Materials/2011-06-22-Minutes.html) include this summary:

Terms of Use for Collaboration software

Patrick reported that he had a brief (impromptu) discussion on this issue internally, and that the conclusion was that it would not be appropriate for a legal team to "approve" the Terms of Use for any collaboration software that they had no control over (this could be a legal liablility.) Even if we were to try to do so, Terms of Use can change at any time, making it effectively impossible. Instead, we'll probably need to take a "Caveat Emptor" approach, reminding Spec Leads that they have legal obligations under the JSPA that could be compromised if they accept contributions from people who have not signed the JSPA or some other Contributor Agreement. Each Spec Lead already must manage this risk, and should continue to do so.

Patrick explained the direction (write up later.)

John suggested that if this is the direction we propose to take then the Spec Lead should assert in the JSR submission that they understand the risks and accept responsibility.

Patrick agreed to draft something very high level for EDR, recognizing that it would need to be refined later after discussion with Legal.

Comment by starksm64 [ 29/Jul/11 ]

The June 29 (http://java.net/downloads/jsr348/Meeting%20Materials/2011-06-29-Minutes.html) include this summary:

Terms of Use for collaboration software

Patrick reviewed the current draft language - basically a "caveat emptor" to the Spec Lead. It was suggested that we might want to issue some kind of warning notice to people who join discussion aliases that their contributions might not be accepted unless they have signed the JSPA. However, we also agreed that vague language such as this would not provide any kind of legal cover, and might in fact be misleading.

This will need further discussion - involving legal advice - but is good enough for EDR.

Comment by starksm64 [ 29/Jul/11 ]

The current language in the process document (http://java.net/downloads/jsr348/Working%20documents/JCP%20NEXT%202.8-29JUL2011-Clean.pdf) states, lines 167-174:

will publish this information on the public JSR Page. The Spec Lead must also provide a pointer to any
Terms of Use required to use the collaboration tools so that the EC and prospective EG members can
judge whether they are compatible with the JSPA.

If the EG changes its collaboration tools during the life of the JSR these changes must be reported to
the PMO, who will update the relevant information on the JSR Page. Any such changes must ensure
that previously-published information is incorporated into the new tools. When voting to approve a
JSR's transition to the next stage EC members are expected to take into consideration the extent to
which the Spec Lead is meeting the transparency requirements

Comment by pcurran [ 04/Aug/11 ]

Closing this, since I think we've addressed the submitter's concern.

Comment by lincolnbaxter [ 17/Aug/11 ]

I have to say that this is fantastic! my concerns have been more than addressed.





[JSR348-88] The term member under the 5 member rule needs clarification in the terms of a JUG membership Created: 17/Aug/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Closed
Project: jsr348
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: dsline Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

All,

In reference to a JUG membership (where the JUG is the member of the JCP), I would like to get some clarification on how many JCP members for a single jug can be "members". You still have the primary and secondary contact, but if part of the intent is to get more jug members involved with the JCP, I don't think there should be a 5 member limit for JUG membership.

If a JUG wants to run for an EC seat, should the EC contact be limited to just a primary or secondary contact?

Note: Regardless of how many members the JUG has, it will only get one vote in any election from the Primary JCP Contact.

I welcome your comments on this issue.



 Comments   
Comment by pcurran [ 17/Aug/11 ]

Re "I don't think there should be a 5 member limit for JUG membership."

Agreed. We're just struggling with language to distinguish between people "associated with" a JUG and those who are "authorized to act on behalf of an organization."

See my comments on http://java.net/jira/browse/JSR348-86

Re "If a JUG wants to run for an EC seat, should the EC contact be limited to just a primary or secondary contact?"

I think you're asking whether, if a JUG has representation on the EC, this would change the rules on the number of "representatives" they may have in the JCP. Answer, no.

Re: "Regardless of how many members the JUG has, it will only get one vote in any election from the Primary JCP Contact." Right.

I'm closing this issue. Any further discussion should happen at http://java.net/jira/browse/JSR348-86

Comment by pcurran [ 17/Aug/11 ]

See latest comment





[JSR348-63] The use of the term "representatives" in the definition of Member is confusing Created: 10/Aug/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSR348-86 Improve clarity of Member definition Closed

 Description   

The definition of Java Community Process Member includes the statement "No more than five individual Members are permitted at any one time as representatives of a company or organization."

The use of the term "representatives" here may be confused with the definition of Member Representative. We need to say this differently.



 Comments   
Comment by pcurran [ 17/Aug/11 ]

On lines 97-98 of the PR draft, replace:

"No more than five individual Members are permitted at any one time as representatives of a company or organization."

with:

"No more than five individual Members from any one company or organization are permitted at any one time."

Note also that the words "individual Members" appear in red(line) even in the clean version of the draft.

Comment by pcurran [ 17/Aug/11 ]

Since issue 86 raises some additional questions I will comment it with the relevant material from this issue, and close this one.

Comment by pcurran [ 17/Aug/11 ]

See comments on link to issue 86





[JSR348-81] "Dormant" definition mentions "life cycle" Created: 17/Aug/11  Updated: 17/Aug/11  Resolved: 17/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Buckley Assignee: eduardo
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

The PR draft


Issue Links:
Duplicate
is duplicated by JSR348-76 Minor language changes suggested by A... Closed

 Description   

On line 32 change "community member(s)" to "one or more Members"



 Comments   
Comment by pcurran [ 17/Aug/11 ]

Plus, the description is incorrect, and duplicates the valid issue http://java.net/jira/browse/JSR348-82

I will close this.

Comment by pcurran [ 17/Aug/11 ]

It's a dup. See earlier comment.





[JSR348-58] Clean up and expand on the process for revising the Standing Rules Created: 09/Aug/11  Updated: 16/Aug/11  Resolved: 10/Aug/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This isn't perfect, but I think it's an improvement over what we have now...
Change the contents of Appendix A to:

To revise this document a formal proposal must be submitted to the EC in the form of a Final Draft. The draft will be published by the PMO for 30-day review during which EC members and the public can comment on the proposal. The EC will formally track comments as Expert Groups are required to do for JSRs. At the end of the review period, and after proper disposition of comments and possible revision of the Draft, it will be subjected to a ballot by both ECs. In order for the ballot to pass, for each EC the following must be true: (a) a majority of the votes cast are "yes", and (b) there is a minimum of 5 "yes" votes. If the ballot fails revised Final Drafts may be submitted for additional ballots at any subsequent time.



 Comments   
Comment by eduardo [ 10/Aug/11 ]

The suggested text has been incorporated in the document. Waiting for review before closing.

Comment by pcurran [ 16/Aug/11 ]

Looks good to me. Let's close it. We can always reopen if others want more change.





[JSR348-60] Typos in current draft Created: 09/Aug/11  Updated: 16/Aug/11  Resolved: 10/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: starksm64 Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have come across the following errors in the current proposed public draft:
http://java.net/projects/jsr348/downloads/download/Working%20documents/JCP2%20EC%20Standing%20Rules%20-10AUG2011-Clean.pdf

Line 225, insiste should be insist
Line 409, "Section 6" should be "Section 7" as 7 is where the EC jsr ballot rules are given.
Line 688, "before the b period" should be "before the ballot period"



 Comments   
Comment by pcurran [ 09/Aug/11 ]

There are also various stray blank lines in the Process Document (227, 246) and the Standing Rules (39, 168, 176.)

Comment by pcurran [ 09/Aug/11 ]

Also, on line 225: "may insiste" -> "may insist"

Comment by eduardo [ 10/Aug/11 ]

The lines mentioned in the first description appear to belong to the Process Document, not the Standing rules, whose last line is 176.

Comment by starksm64 [ 10/Aug/11 ]

That is correct, the link is a copy and paste error. I was referring to the current Process Document draft from the 10th of August, 2011.

Comment by eduardo [ 10/Aug/11 ]

Regarding the comment about Line 409, I'm not sure the reference is to Section 7; I think it may be indeed section 6, specifically section 6.3. Be that as it may, I personally believe this is a gratuitous reference that adds nothing but words to the document, and I'd like to delete it.

Regarding blank lines, I found only one in the Process document and one in the Standing rules and I've eliminated them for the PR version. If there are any more, it would be helpful if people were to specify which lines they consider extraneous.

Comment by eduardo [ 10/Aug/11 ]

I've corrected some; I'll wait for input on the others

Comment by pcurran [ 10/Aug/11 ]

I agree - delete "as specified in Section 6 below" from line 409.

Comment by pcurran [ 10/Aug/11 ]

As for blank lines, it's difficult to tell from the line-numbered version which are redundant. In general, if the various text elements (headings, paragraphs, etc.) are correctly defined I wouldn't expect to see any blank lines, since the elements would define how much space should be inserted after them. (For example, most paragraphs in the document are separated from the following paragraph by more than one line's worth of whitespace, but are not followed by a blank line - just for example, see lines 177-178.) Similarly, the headings on lines 173 and 174 are followed by whitespace.

This leads me to suggest that any blank line is suspect. It may be necessary because the preceding element is incorrectly defined, but the only way to find out would be to delete it in the source document and see how it looks.

Be that as it may, I'm pretty sure that the following blank lines should be deleted:

9, 227, 229, 246

I'm not so sure about these:

3, 8, 644

Comment by eduardo [ 10/Aug/11 ]

reopened to change the resolution status

Comment by eduardo [ 10/Aug/11 ]

the line has been deleted.

Spurious blank lines have now been identified in both documents as a result of (invisibly) erroneous formatting of some paragraphs, and has been fixed in most if not all cases.

Comment by eduardo [ 10/Aug/11 ]

Waiting for review before closing

Comment by pcurran [ 16/Aug/11 ]

I've verified that the required changes have been made. We're done with this issue...





[JSR348-55] Typo on line 225 Created: 08/Aug/11  Updated: 09/Aug/11  Resolved: 09/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pcurran Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

August 10 version



 Description   

"may insiste" -> "may insist"



 Comments   
Comment by pcurran [ 09/Aug/11 ]

Consolidated this into issue #60





[JSR348-54] Formatting of Item Exception Ballot in definitions section Created: 08/Aug/11  Updated: 09/Aug/11  Resolved: 09/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: starksm64 Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is a minor formatting issue in the Defintions section of the folowing version of the process doc:
http://java.net/downloads/jsr348/Working%20documents/JCP%20NEXT%202.8-05AUG2011-Clean.pdf

The issue is that the term "Item Exception Ballot:" is not bold like all of the other definitions.



 Comments   
Comment by starksm64 [ 09/Aug/11 ]

This is fixed in the current http://java.net/projects/jsr348/downloads/download/Working%20documents/JCP%20NEXT%202.8-10AUG2011-Clean.pdf

Comment by pcurran [ 09/Aug/11 ]

Fixed in the August 10 draft





[JSR348-40] The observers mailing list is missing messages sent to expert mail list Created: 30/Jul/11  Updated: 09/Aug/11  Resolved: 30/Jul/11

Status: Closed
Project: jsr348
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: starksm64 Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It was brought to my attention that the expert list and observer lists seem to show a discrepency in the number of messages they have. This is reflected in the number of messages that are shown on the mailing lists summary page of the jsr348 site:
http://java.net/projects/jsr348/lists

The expert group archives shows 31 msgs sent in July:
http://java.net/projects/jsr348/lists/experts/archive/2011-07/thread/1

The observers group archives shows 27 sent in July:
http://java.net/projects/jsr348/lists/observers/archive/2011-07/

The 4 missing messages are:
http://java.net/projects/jsr348/lists/experts/archive/2011-07/message/15 through 17

[JSR348 EG] Re: Automating Contributor Agreements
Scott Stark 07/15/2011

[JSR348 EG] Re: Automating Contributor Agreements
Werner Keil 07/16/2011

[JSR348 EG] Re: Automating Contributor Agreements
Scott Stark 07/19/2011

and message 27:
http://java.net/projects/jsr348/lists/experts/archive/2011-07/message/27

[JSR348 EG] AUTO: Daniel Bandera is out of the office (returning 08/01/2011)
Daniel Bandera 07/22/2011



 Comments   
Comment by pcurran [ 30/Jul/11 ]

The answer is simple. As I explained when we first set up these aliases, messages sent directly to experts@jsr348.java.net (as the first three messages were) are not automatically copied to observers. (If you remember, there's a bug in java.net and although I could configure the messages to be copied over, they would not be archived there.) So - you need to send messages to the front-end alias jsr348-experts@jcp.org, which will ensure that they are copied over.

As for the fourth message, observers is moderated such that if you're not a subscriber to it I have to approve the message before it's distributed. I didn't think that the world needed to know that Daniel Bandera is out of the office, so I didn't approve that message.

So, this is not a bug.

Comment by mojavelinux [ 09/Aug/11 ]

I don't understand why we cannot simply have one moderated list.

  • EG members would have automatic read/write access to the list
  • non-EG members would have read access to the list and all write access would be moderated (allowed upon approval)

Since all debates are tracked via the issue tracker, observers have the alternative option of commenting on the issue report.

I suggest this setup because it's used almost universally for open source projects and has proven to work (and scale). Plus, anyone familiar with open discussions will understand this model.

Sending discussions from one list to another, in my opinion, is just making matters more complex than necessary.

Comment by mojavelinux [ 09/Aug/11 ]

Non-EG members have another outlet for discussion through the use of the JCP forums (if/when they are activated again).

"Note that the wiki and discussion boards are currently unavailable. Please send JSR feedback directly to the Spec Lead in the meantime."





[JSR348-31] Contribution Agreement should be a formally-defined term Created: 29/Jul/11  Updated: 08/Aug/11  Resolved: 05/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by pcurran [ 05/Aug/11 ]

Here's my suggested definition. Feel free to modify or replace.

Contribution Agreement: A legal agreement defining the terms, particularly those concerning the grant of intellectual property rights, under which contributions are made to the work of an Expert Group.

Comment by Bill Shannon [ 05/Aug/11 ]

"Contribution Agreement" shouldn't be so closely connected to "Expert Group".

I would use:

Contribution Agreement: A legal agreement defining the terms, particularly those concerning the grant of intellectual property rights, under which contributions are made to an open source project.

Comment by eduardo [ 05/Aug/11 ]

Done, adopted the suggested definition

Comment by eduardo [ 05/Aug/11 ]

A contribution agreement should not be closely connected to open source either, as it's used in many other contexts. How about "A legal agreement defining the terms, particularly those concerning the grant of intellectual property rights, under which contributions are made to a project" (or, given that this is a JCP Process Document, "are made to a JSR")?

Comment by Bill Shannon [ 05/Aug/11 ]

Does the JCP process document refer to contribution agreements for things other
than open source projects? If so, then "... are made to a project" seems fine.

"... are made to a JSR" is wrong. The contributions to the JSR are made under
the JSPA.

Comment by eduardo [ 05/Aug/11 ]

I'm happy with "are made to a project", and will implement it.

Comment by pcurran [ 06/Aug/11 ]

The whole point of this issue is to define the term as used in this text (that is, where there may not be a JSPA):

"Spec Leads should be aware of their obligations under the JSPA to license the output of their JSR on Fair, Reasonable, and Non Discriminatory terms, and to make certain patent grants. Incorporating feedback provided through public email lists or forums without ensuring that the provider has signed the JSPA or an equivalent Contribution Agreement may make it impossible to meet these requirements or may expose the Spec Lead Member to legal liability."

"To an open-source project" is clearly incorrect (many EGs do not conduct themselves as open-source projects.

"To a project" seems unnecessarily vague.

I really think we should say "to a JSR" (or perhaps "to the work of an Expert Group") since we're need to cover the case where contributions to a JSR is not covered by a JSPA.

Comment by Bill Shannon [ 08/Aug/11 ]

We seem to be mixing two issues together here.

A Contribution Agreement is not related to contributions to the EG. It's used for
contributions to a project (that might be implementing the JSR).

Defining the term in a way that's different from common usage will only cause confusion.

I think the definition should say "... are made to a project".

The longer text you quote above could say "... or an equivalent Contribution Agreement
for any project implementing the JSR ..."

Comment by pcurran [ 08/Aug/11 ]

(To Bill)

I understand your point, but in this context Contribution Agreements most definitely are related to contributions to the EG. The whole reason we're bringing them up is to deal with the situation where someone who has not signed the JSPA makes a contribution (admittedly to a project) that makes its way into the JSR.

Nevertheless, I like your suggestions.

So: the changes would be

1) Define Contribution Agreement as "A legal agreement defining the terms, particularly those concerning the grant of intellectual property rights, under which contributions are made to an open source project."

2) Change line 194 (of the August 10 draft) to read:

"the JSPA or an equivalent Contribution Agreement for any project implementing the JSR ..."





[JSR348-52] Clarify when a 2/3 majority is required to approve a new JSR Created: 06/Aug/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Lines 690-693 define when a 2/3 majority is required to approve a JSR. The intent is that 2/3 is required for JSRS:

a) that define new Platforms (that is, the first JSR to specify a previously non-existent Platform), or
b) modify the Java language

The existing language is somewhat ambiguous in case a) and could be interpreted as refering to UJSRs that update existing Platforms.

The language should be clarified. Suggestions to follow.



 Comments   
Comment by pcurran [ 06/Aug/11 ]

I suggest changing:

"Ballots to approve UJSRs for additional Platform Edition Specifications"

to:

"Ballots to approve UJSRs that define the initial version of a new Platform Edition"

Comment by Bill Shannon [ 07/Aug/11 ]

I think that's pretty good. Let's see if everyone else agrees that that's clear.

Comment by eduardo [ 08/Aug/11 ]

I've implemented the last suggested change.





[JSR348-53] "Reasonable increases in price" should not be considered changes in licensing terms Created: 08/Aug/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 0.0.3 states that the license terms offered when a JSR goes final must continue to be offered "for ever."

Reasonable increases in price should not be considered a change in terms.

Suggested wording - change lines 226-227 from:

"During the lifetime of the JSR the Spec Lead must continue to offer the RI and TCK licenses that were published at the time of Final Release."

to:

"During the lifetime of the JSR the Spec Lead must continue to offer the RI and TCK licenses that were published at the time of Final Release, with the exception that reasonable increases in price are permitted."



 Comments   
Comment by eduardo [ 08/Aug/11 ]

Done





[JSR348-51] When a Spec Lead withdraws the replacement should be sought from the Member company Created: 06/Aug/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

0.1.1 WITHDRAWAL OF AN EXPERT FROM THE EXPERT GROUP reads:

"An Expert may withdraw from the Expert Group at any time. When this happens, the Spec Lead should approach the Member who originally contributed the Expert and work with that organization to find a replacement. If no replacement is offered, the Spec Lead may recruit a replacement from another Member. If the departing Expert"

This should be replaced with:

"An Expert may withdraw from the Expert Group at any time. When this happens, the Spec Lead should approach the Member who originally contributed the Expert and work with that organization to find a replacement. If no replacement is offered and the departing Expert was not the Spec Lead, the Spec Lead may recruit a replacement from another Member. If the departing Expert was the Spec Lead, the Expert Group should choose one of its members as the new Spec Lead.



 Comments   
Comment by Bill Shannon [ 06/Aug/11 ]

The Member who provided the Spec Lead have first choice in providing a new
Spec Lead.

Comment by pcurran [ 06/Aug/11 ]

That's what my proposed change says (or at least, is intended to say.)

First, whether or not the member who resigns is the Spec Lead, seek a replacement from the Member company/organization.

Then, if no replacement is forthcoming, seek a replacement EG member from the entire membership, and a replacement Spec Lead from among the EG.

If you think my wording is unclear, please suggest an alternative.

Comment by Bill Shannon [ 07/Aug/11 ]

The first part is unclear because it says what the Spec Lead should do, but if the
Spec Lead is the one who's leaving, they're not going to be doing that.

Replace the last sentence with:

If the departing Expert was the Spec Lead, the Member who provided the Spec Lead
should provide a new Spec Lead. If the Member is unable to provide a new Spec
Lead, the Expert Group should choose one of its members as the new Spec Lead.

Comment by eduardo [ 08/Aug/11 ]

I would like to replace the existing paragraph with the following, which I believe is clear, unambiguous, and reflects both suggestions (please note: I have added "if any" for those cases that affect individuals):

"An Expert may withdraw from the Expert Group at any time. If the withdrawing Expert is the Spec Lead, the Expert Group, with the help of the PMO, should approach the Member who originally contributed the Expert, if any, and request them to provide a suitable replacement; if not such replacement is forthcoming, the Expert Group should choose one of its members as the new Spec Lead. If the withdrawing Expert is not the Spec Lead, the Spec Lead should approach the Member who originally contributed the Expert, if any, and work with that organization to find a suitable replacement. If not replacement is offered or is not otherwise available, the Spec Lead may recruit a replacement from the entire membership or from the EG membership."

Please let me know asap if that's acceptable.

Comment by pcurran [ 08/Aug/11 ]

Looks good to me...

Comment by Bill Shannon [ 08/Aug/11 ]

Two cases of "not" should be "no".

This last clause is confusing - "... from the entire membership or from the EG membership"

The entire membership of what? The JCP?

If an expert leaves, why would you need another expert on that same EG to replace the
leaving expert? The other expert is already there! In what sense would they be
replacing the leaving expert?

Do you mean another expert from a Member who is on the EG?

Other than the Spec Lead case, most of this is just advice since experts can be added
to the EG at any time from any JCP member (subject to Spec Lead and EG approval).

Comment by eduardo [ 08/Aug/11 ]

Reopened to respond to comments

Comment by eduardo [ 08/Aug/11 ]

s/not/no – agreed, errors due to copy and paste

The last clause actually due to a misunderstanding of a suggested edit, and it is indeed meaningless as is.

Changed it to:

"An Expert may withdraw from the Expert Group at any time. If the withdrawing Expert is the Spec Lead, the Expert Group, with the help of the PMO, should approach the Member who originally contributed the Expert, if any, and request them to provide a suitable replacement; if no such replacement is forthcoming, the Expert Group should choose one of its members as the new Spec Lead. If the withdrawing Expert is not the Spec Lead, the Spec Lead should approach the Member who originally contributed the Expert, if any, and work with that organization to find a suitable replacement. If no replacement is offered or is not otherwise available, the Spec Lead may recruit a replacement from amongst other Members."

Comment by Bill Shannon [ 08/Aug/11 ]

I guess that's ok, although I would prefer the second sentence to be this:

If the withdrawing Expert is the Spec Lead, the Member who originally contributed the Spec Lead, if any, should provide a suitable replacement; ...

Comment by eduardo [ 08/Aug/11 ]

I think that would be underspecified, so I'll leave it like it is for now, but will reopen if others also think it's overspecified.





[JSR348-25] Calculating a majority Created: 28/Jul/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

Status: Closed
Project: jsr348
Component/s: Standing Rules
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: eduardo Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The use of the word "majority" and how to calculate it is somewhat confusing in the "Voting" section. Replace existing text with "For the purpose of calculating the voting results, a majority is achieved when the result of dividing the yes votes by the sum of the yes and no votes is larger than 0.50."



 Comments   
Comment by pcurran [ 29/Jul/11 ]

The whole matter of "voting" is confusing since we use the term for two very different things - JSR ballots, and other "advisory" votes.

I suggest using different terminology:

  • JSR Ballot (or just ballot) for all JSR-related "votes"
  • "Voting" everywhere else
Comment by pcurran [ 29/Jul/11 ]

Review document to see whether distinction is necessary/useful.

Comment by eduardo [ 29/Jul/11 ]

I think the best distinction we can make is to make sure that while "vote" is used either as a noun or a verb, "ballot" is never used as a verb but only to indicate the question being put before the voters. We should make sure also that if "ballot" is used in any of the definitions, it should not be replaced by "vote" in the text (an example of this is the use of "JSR approval vote" in section 1.0 instead of "JSR Approval Ballot")

Comment by pcurran [ 04/Aug/11 ]

This proposed change is helpful, but doesn't really address my concern that we need to make a clear distinction between the formal, binding, ballots concerning JSRs and the advisory "votes."

I'm not sure how to do this, but at the least we should scrutinize the documents carefully for any confusing terminology.

Comment by eduardo [ 05/Aug/11 ]

Doesn't the sentence "All EC decisions are to be understood as being advisory in nature except as they pertain to JSR related ballots" make it clear?

Comment by pcurran [ 05/Aug/11 ]

I didn't express myself clearly.

Yes, "All EC decisions are to be understood as being advisory in nature except as they pertain to JSR related ballots" makes the distinction clear. My concern was that - at least with earlier drafts - we tended to use the terms vote and ballot somewhat loosely, so that it wasn't always clear which category a particular "decision" belonged to.

Comment by eduardo [ 05/Aug/11 ]

Oh, I've changed that throughout in both documents. I would propose to mark this issue as Resolved/Fixed and close it, and accept that it may be reopened if after further reading it proves to be still confusing.

Comment by eduardo [ 08/Aug/11 ]

I believe at this time there is no inconsistency or ambiguity in the use of the terms.





[JSR348-33] Consistency in references Created: 29/Jul/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: eduardo Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JSR348-41 Section numbering Closed

 Description   

Prior to review, a careful read must be done to make sure that references to sections in the document go indeed to the right place, given that sections have been moved around and re-numbered



 Comments   
Comment by eduardo [ 01/Aug/11 ]

All section numbers will changed when JSR348-41 is implemented; it would make no sense to do this before 41 is completed

Comment by eduardo [ 08/Aug/11 ]

Done





[JSR348-41] Section numbering Created: 01/Aug/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: eduardo Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JSR348-33 Consistency in references Closed

 Description   

Currently the first section in the document is 0 (zero). This should be changed to 1 (one).



 Comments   
Comment by pcurran [ 05/Aug/11 ]

OK - go for it

Comment by eduardo [ 08/Aug/11 ]

Done





[JSR348-50] Clarify the meaning of the term "release" Created: 05/Aug/11  Updated: 05/Aug/11  Resolved: 05/Aug/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Harold Ogle:

The term "release" is used in multiple places (see, for example, lines 51, 205, 210, 352, 515.) It's not always clear, particularly to those who are unfamiliar with the process, what this means.

Formally defining Release as "A Final Release or a Maintenance Release" should take care of most of these references. Others might need to be rephrased to refer to a transition from one JSR stage to another.



 Comments   
Comment by pcurran [ 05/Aug/11 ]

After line 148 insert the following definition:

Release: A Final Release or a Maintenance Release

On line 51 change "release" to "Release"

On line 373 change "one release in advance" to "one JSR submission in advance"

On line 536 change "releases" to "Releases"

On line 584 change "release" to "Release"

Comment by eduardo [ 05/Aug/11 ]

Done





[JSR348-38] Process Doc should contain a non-normative reference to the Spec Lead Guide Created: 29/Jul/11  Updated: 05/Aug/11  Resolved: 05/Aug/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Spec Lead Guide provides examples of how things should be done where it's not necessary or appropriate to tightly specify these in the Process Document.

Some suggested references to the Spec Lead Guide from the Process Doc are:

*It tells you where to find the online form to submit a JSR proposal
*It will provide sample Compatibility Requirements for inclusion in the TCK documentation (see issue JSR348-6)



 Comments   
Comment by pcurran [ 05/Aug/11 ]

Eduardo: Could you take a stab at this?