EFSP: The Specification Committee Votes

One key difference between Eclipse open source software projects as defined by the Eclipse Development Process (EDP), and open source specification projects as defined by the Eclipse Foundation Specification Process (EFSP) is that specification projects must be aligned with exactly one specification committee. More generally, specification projects are aligned with an Eclipse working group and are governed (in part) by the working group’s specification committee.

The specification committee is required to vote to approve key milestones in the lifecycle of their specification projects:

  • Specification project creation;
  • Release plan;
  • Revision to the scope;
  • Progress and release reviews;
  • Service releases; and
  • Designation of a profile or platform.

The most frequent votes occur when specification projects engage in the reviews that occur during the development cycle (highlighted in bold).

efsp

To succeed, a vote requires positive responses from a super-majority (defined as two-thirds) of the members of the specification committee. Votes to designate a specification as a profile or platform require positive responses from a super-majority of the specification committee members who represent the interests of Strategic Members of the Eclipse Foundation. It’s worth noting that there is no veto.

The criteria by which representatives decide how they’re going to vote varies by individual and according to the values of the individual and the organization that they represent (if applicable). Minimally, the specification committee is expected to use their vote to ensure that specification projects stay within scope. In the case of a progress review, the voters will need to consider whether or not the project is progressing in a manner that will eventually result in a successful vote on the eventual release review that gates the ratification of the final specification.

The EFSP is silent on what happens in the event of a failed vote. In the event of a failure, we expect that feedback regarding the reason for the failure will be provided to the project team, who will work to mitigate issues and then re-engage.

Please see:

Advertisements
This entry was posted in Community, EDP, EFSP, Jakarta EE. Bookmark the permalink.

3 Responses to EFSP: The Specification Committee Votes

  1. Pingback: Eclipse Foundation Specification Process, Part II: the EFSP | Eclipse Hints, Tips, and Random Musings

  2. Pingback: Eclipse Foundation Specification Process, Part I: The EDP | Eclipse Hints, Tips, and Random Musings

  3. Pingback: Eclipse Foundation Specification Process, Part III: Creation | Eclipse Hints, Tips, and Random Musings

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s