| Re: [jakarta.ee-spec.committee] Recent Edits |
I'm starting to become concerned/confused about this as well.
I think we were previously expecting that a specification project would manage the specification document, the source code for the API classes, and the source code for the TCK. Assuming we need special rules for specification projects, do we really want those special rules to apply to the API and TCK, which after all are just source code projects?
The API classes are hard because they mix specification with (varying amounts of) implementation. But none of the IP issues for the spec apply to the TCK, right? Maybe the TCKs should be in separate code projects that follow the normal EDP rules?
Steve Millidge (Payara) wrote on 05/29/18 02:28 AM:
_______________________________________________I share Ivar’s concerns here.
I am also confused by the definitions and the developing special nature of this specification project and how that is going to work in practice with the standard Eclipse API and TCK projects that will live under the EE4J PMC.
So forgive me if I get this wrong are we saying;
Specification Project -> creates Document, Specification Implementation, TCK?
A normal EE4J project under the PMC creates just the API?
Or are we saying Specification Project just creates the Document and must ensure there is a TCK, API and Specification Implementation before the Specification can be released.
Also given the document just essentially describes the API and behaviours under the API how is the Specification project going to control/influence the work of the API project working under usual EDP rules of engagement?
I’m afraid I’m a fairly practical person and I am now confused about practicalities of who is doing what.
Thanks
Steve
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Ivar Grimstad
Sent: 25 May 2018 18:02
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Recent Edits
Hi,
I think we should tread carefully here so we don't become a corporate club where you have to pay to play, which is exactly what critical voices in the community have warned against.
I can understand the reasoning behind the wish for a company to being able to replace a committer on a project. But at the same time, if a corporation is allowed to do that it should probably apply to individual committers as well. E.g. someone that wants to resign from the project for some reason and give the reigns over to someone else. By doing so, we are going against the Open Source Rules of Engagement defined by the EDP (https://www.eclipse.org/projects/dev_process/development_process.php#2_1_Open_Source_Rules_of_Engagement). So be prepared for a storm! This will not be well received by our critics...
Ivar
On Fri, May 25, 2018 at 2:56 PM Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
Below ....
On Fri, May 25, 2018 at 4:02 AM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Richard,
We (the EMO) are thinking about this, and how we could make it work if we decide it is the right thing to do.
Two points:
- I find it surprising that the small-company guy is arguing for the corporate approach. I realize that this is quite typical in standards organizations. Is everyone else on the list comfortable that this explicit corporate presence is desirable?
Well, like any other organization that is dedicating resources to the effort of Jakarta EE, we (Tomitribe) want to ensure that we benefit from that investment. When an engineer works on a Jakarta EE specification, it costs the company money in terms of salary, but that's not all. Often the employee will rely on other resources in the company such as people or equipment. None of this is free. I am a committer for the EJB Specification project. Tomitribe is counting on me to make valuable contributions that will result in a stronger specification which means a healthier market for Tomitribe and everyone else. If I were to leave Tomitribe, they would want to protect that investment in time and energy by replacing me with another qualified individual. My time contributing to specifications is not a sunk cost.
When a company's representative is added to a Specification Project its done on merit, just like adding an individual. It's expected that the company can contribute, regardless of the representative, real value to the definition of the specification. The company has to have demonstrated expertise in the area concerned.
- I hope that you are prepared to argue for this when our friends like Markus Karg take us to task for being a bunch of corporate shills ;)
Of course.
On 2018-05-24 10:58 AM, Richard Monson-Haefel wrote:Thanks, Mike.
At this time committers are defined as "individuals." I would like to see that expanded to include "representatives". A representative is the role of committer in a project that can be occupied by an employee of the company that is represented. Not sure if that makes sense or not. You can be nominated and elected as a committer to a project as either an individual or as a representative of a company. If an elected representative leaves the company they were elected to represent, the company has the option of appointing a new representative. If the project wishes to also keep the original representative they can be re-nominated and elected as an individual or as a representative of a different company. A representative committer is equal in all other ways to an individual committer.
On Thu, May 24, 2018 at 4:09 AM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Please do not worry about how Wayne and I get the approvals in place for any necessary process changes. I'm confident we can make what we agree to happen. Let's figure out what the right solution is, and then the EMO can figure out how to implement it.
On 2018-05-24 1:36 AM, Richard Monson-Haefel wrote:I believe changes to the Eclipse Development Process require approval by the Eclipse Board, so if a rule change is necessary it would need to be proposed to the board. Whether or not an exception can be made for just the EE4J Working Group or if the change would need to apply to all Working Groups, I do not know. If the rules germane to this issue cannot be changed, than instead of a rules change it could be considered a “courtesy” that is commonly extended to companies whose whose employee, elected as a committer, has ended their employment with that company. For example: Project X has 10 committers with names (A, B, C ... J). Committer B worked for ACME Company when elected to a Specification Project. When Committer B is nominated they declare that although they are individual they also are an official representative of ACME Company. This proclamation is not binding in anyway, but is simply informative part of the nomination. Committer B announces that they are leaving the ACME Company to become independent but will sign a new Committers Agreement as an Independent (or their new company will sign one) and will stay on Project X. The ACME Company makes a request that another employee, Ms. K, me nominated as a committer to Project X. The Project Lead, as a courtesy to the ACME Company, can choose to nominate Ms. K. The vote is taken according to normal Eclipse Development Handbook and Ms. K is either elected a committer or not.
On Wed, May 23, 2018 at 7:22 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
That's a start, but that makes it clear we're inventing new rules for Spec Projects that are different than any other Eclipse project. Is there a better way to "overlay" the Spec Project rules on top of the existing Project rules?
Richard Monson-Haefel wrote on 05/23/18 02:34 PM:
Good point. Here is a counter proposal:
In addition to accepting individuals to a Specification Group, the group lead or the group can nominate/elect (or whatever) a representative of an organization. If the represenative leaves that organization, the organization can nominate a replacement represenative. The original representative can remain on the Specification Group as an individual or perhaps representing some other company, but the company that originally invested in that represenative has the right to nominate a new represenative. The newly nominated represenative can be subject to a vote by the group. That way the organization that lost the represenative has the oppourtunity to maintain its place at the table but is not an automatic “pay to play” contributor.
I think that protects the investment made by the organization when it has payed the representative salary and gave that time to the Specification Group without making it a “pay to play” situation. So there can be individual group members and organizational group members.
On Wed, May 23, 2018 at 4:00 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Richard Monson-Haefel wrote on 05/23/18 07:28 AM:
Depending on the membership level, an organization should automatically get a seat on any specification project they want but should excercise self-restraint to focus on those specifications germane to their products. Why, for example, should a company become a strategic member if it cannot have a seat at the table?
So, if you pay then you can play?
What about the people who don't pay?
At the JCP, the Spec Lead would decide whether an expert was qualified to be on the expert group. We ran into quite a few people who clearly only wanted to be on an expert group so that they could add that to their resume. We rejected many of those people.
If "expert group members" are Committers on a Spec Project, who qualifies the Committers? After the Project is created, I assume it would be the Project Lead. Before the Project is created, is it just the person who proposes the project? And you're suggesting that the Project Lead would have no choice but to accept any Committer proposed by a paying Member?
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________jakarta.ee-spec.committee mailing listjakarta.ee-spec.committee@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee--
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader