Re: [jakarta.ee-spec.committee] Topics for today

[Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>]

Greetings folks.

Here's my summary of what we discussed on the call. Let me know if I've gotten anything wrong.

I've injected a couple of questions into this discussion. Feel free to comment here. I'll add them to the agenda for tomorrow's call.

Votes. What sorts of things do we expect a project team to vote on and what, specifically, do we need to say about the voting process?

We did not reach a conclusion. Some in the group feel that this adds unnecessary complexity to the process. We decided to table further discussion until tomorrow's session.

The proposal at hand is that we require the committers on a Specification Project to engage in a positive vote before engaging the Specification Committee to either change the scope of a Specification Project or petition for the adoption of a final Specification Version.

The rationale for requiring this vote is that the intellectual property for a Specification Project flows to the implementer of a Specification Version via the committers and we feel that it is important to have an explicit positive acknowledgement from all Participants as a final check.

We did not discuss the specifics of the vote beyond asserting that all Participants get to vote. I believe that "supermajority" was suggested, but don't recall if we reached any conclusion. Typical voting rules are: the vote is open for a full week; to succeed, we three positive votes; and any voter can veto. Assuming that my rationale is correct, I think that we need the veto. 

I'll reinforce that for these votes, every Participant gets to vote not every Committer. How Specification Project teams implement the vote is out of scope for the EFSP (we should expect to provide a best practice).

This discussion led to a discussion regarding the special powers granted by Member Participants to inject a committer onto a Specification Project. It was affirmed that any organization that is a member of the EF and has signed a Working Group Participation Agreement (for the specific Working Group), can become a Participant in a Specification Project with the ability (responsibility?) to appoint a single representative Committer ("Specification Participant Representative"). There are no further restrictions (e.g. a company can appoint their representative Committer as soon as they have completed the necessary paperwork.

The ability appoint themselves as a representative committer does not extend to Individual Members.

I think that I'd like to change "Specification Participant Representative" to "Member Participant Representative" for consistency. Any objections?

We further asserted that the ability to inject a Committer onto a Specification Project is an exception to the general practice. The general practice follows the rules as laid out in the EDP: Committers must be elected into the role (which includes initial committers included on a project proposal).

Committers on Specification Projects must be covered by a Member Agreement and Working Group Participation Agreement. For employees of member companies ("Member Participants"), the company is responsible for executing these agreements. For an individual who does not work for a member company ("Individual Participants"), the individual must first become a committer, and then execute the Member Agreement and Working Group Participation Agreement as an individual.

For the sake of completeness, for the purposes of the EFSP, the "Participant" role applies to a specific Specification Project. An organization may be a "Member Participant" in multiple Specification Projects.

We spoke briefly about Committer Elections and I believe that we agreed that the standard practice applies for all Specification Projects. That is, there is no special case where having Committer status on one Specification Project grants an individual similar status on another project. We did discuss that "familiar with the process and subject matter expert" can be considered reasonable merit in a nomination statement.

 

Note that approvals are already covered in the document: e.g. the Specification Committee must approve new project proposals, scope changes, release plans, and reviews by super majority. 

We noted that all Member Companies are not represented on the Specification Committee, so representation on the committee does not meet the requirements of the stated rationale for requiring a Participant vote.

 

Project Team. Does the Member Company's ability to appoint a representative Committer trump the Project Leadership Chain's ability to add or remove committers under extreme circumstances? (this is something that we might just leave to the grievance handling process)

The Project Leadership Chain may ask a Member Participant to appoint a replacement for a disruptive representative Committer. The grievance process applies otherwise.

 

Is the Specification Committee in the Project Leadership Chain (Project Lead, PMC, EMO, EMO(ED)).

We decided no.

 

Do Project Leads have any special roles or responsibilities beyond what's outlined in the EDP?

We decided no.

 

Profiles. Bill made the suggestion that we should restrict Profiles from defining any APIs of their own. This feels natural to me. However, I'm not sure that I want to bake it into the process. Do we want to make this a formal restriction, or is this something that the Specification Committee can handle via the approvals process?

We reasserted that a platform is a Profile, and that no special definition of "platform" is required in the EFSP.

I think that we decided that restriction against including APIs in a Profile doesn't need to be baked into the EFSP.

This lead to a discussion regarding references to other specifications (this conversion was lengthier than these notes suggest, but I think that I've summarized it correctly).

A reference can either be a "requires" or an "includes" reference. Bill used different words ("dependency" and "reference").

e.g. (requires) an implementation of the JSP specification runs in a servlet container (but the servlet container is not part of the implementation)

e.g. (includes) an implementation of servlet specification is contained in an implementation of the JSP specification.

A Profile has an "includes" relationship (as I've tried to describe it) with the transitive closure of the specifications that it references. The rationale being that a "Profile" must specify a "complete" implementation and that the label helps to make this nature clear.

 

I wrote that "only Compatible Implementations of Profiles that are certified by the Specification Committee may leverage the associated Brand".

I believe that we decided that this is true. Whether or not this belongs in the EFSP is an open question (see below).

 

Bill suggested that this should not be a part of the process. We have discussed the focus of the process in the past, and I believe that it was decided that the EFSP stops at the point when the Specification Committee adopts a Specification Version. Do we have general agreement?

If yes, then should we remove the "Branding and Certification" section and the various references to "Brand"?

We didn't discuss this. I'll add it to the agenda tomorrow. 

 

Reviews. Can the Specification Committee also define the minimum and maximum time periods between reviews? If a project fails to make progress at a reasonable rate, can the Specification Committee declare it to be "stalled"?

What does "stalled" mean? How long can a Specification Project be stalled? What happens next. Specification Committee can decide to cancel the current release cycle iteration and kick the project back to planning, or some other form of remediation. In the extreme case, the Specification Committee can get the Project Leadership Chain to replace the project team.

I'll add this to the agenda for tomorrow.

 

Wayne

--

Wayne Beaton

Director of Open Source Projects

The Eclipse Foundation