Eclipse Foundation Specification Process

Specification Projects operate under the supervision of both the Project Leadership Chain and the Specification Committee.

Among other things, the Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the Specification. Since a change in Scope may change the nature of the contribution to the project, a change to a Specification Project’s Scope must be approved by a Super-majority vote of the Specification Committee.

Specifications must be developed by Specification Projects. 

A Specification may describe parts as being optional. Optional parts of a Specification must not conflict with one another; it must be possible for a Compatible Implementation to implement all optional parts.

A Specification can define rules. If defined, such rules must not override the rules defined in any referenced Specification.

A Specification that aggregates other Specifications by reference may be designated as a Profile. Profiles do not have to be arranged in unique subsets (i.e. a Specification may appear in more than one Profile). A Super-majority, including a Super-majority of Strategic Members, is required to approve a Profile Specification. A Specification Committee may, at its discretion, elect to label one or more Profiles as a “Platform”.

Specification Project Committers must be Members of the Eclipse Foundation. Committers may be Members by virtue of working for a member organization, or may choose to complete the membership process independently.

All Specification Project Committers must be covered by a Working Group Participation Agreement.

Member Participants have the right to appoint a Participant Representative to every Specification Project that falls under the purview of the Specification Committee.

The Specification Committee works with the PMC to manage the overall vision for the Specification Projects under their supervision.

A Release Plan lists themes and areas of focus, describes Milestones, and lists tentative dates for Reviews. The work defined by a Release Plan must be within the Scope of the Specification Project.

The exact requirements for a Release Plan, including the number and timing of Milestones and Reviews, are determined by the Project Leadership Chain and the Specification Committee. Minimally, a Release Plan must include a textual description of the activities planned for the Specification Version, and tentative dates for at least one Milestone, at least one Progress Review, and the Release Review. Following approval, the Specification Committee must be notified of any changes to the dates of the Progress Review and the Release Review. The Specification committee can require that the project team engage in a Progress Review.

The Project Proposal serves as the Release Plan for the first release of a Specification Project.

A Release Plan must be approved by a Super-majority vote of the Specification Committee. If the Release Plan is rejected, the Specification Team may reapply at a future date.

The Specification Project Lifecycle is defined by the EDP.

To produce a Specification Version, a Specification Project must engage in a formal Release Cycle under supervision of the Project Management Committee (PMC) and the Specification Committee.

A Specification Project’s first Release Cycle starts with the successful completion of a Creation Review. To start a subsequent Release Cycle, the Specification Team presents a Release Plan to the Specification Committee in a Plan Review. The Plan Review must be approved by a Super-majority vote of the Specification Committee.

The Specification Team must deliver at least one Milestone to demonstrate progress and solicit feedback. Milestones may be incomplete. For example, designated Compatible Implementations will not necessarily pass milestone builds of the TCK in their entirety. Subsequent Milestones should, however, demonstrate progress. Later Milestones may be referred to as Release Candidates.

Milestones should be staged for limited distribution to key stakeholders to solicit feedback. The delivery of at least one Milestone must coincide with engagement in a successful Progress Review.

The Specification Team must engage in a successful Release Review before the final Specification Version may be Ratified. A Specification Version becomes a Final Specification when it is Ratified.

Service Releases (bug fixes) for a Specification Version that has engaged in a successful Release Review do not require any further Reviews, but must be approved by a Super-majority vote of the Specification Committee.

Reviews are a formal process through which all major lifecycle events and changes to Specification Projects are announced and reviewed by the membership-at-large, and approved by the PMC, the Specification Committee, and the EMO.

A Specification Project may engage in all of the Reviews described by the EDP with the additional requirement that approval by a Super-majority vote of the Specification Committee is required to successfully complete a Review. Such Review shall include affirmation that the Specification Version in progress remains within the Scope of the Specification Project. Other additions and qualifications are noted in the descriptions of the reviews below.

Project Leads are responsible for initiating the appropriate Reviews. The Project Leadership Chain may also initiate a Review on the project’s behalf.

The Specification Team must complete all required due diligence under the Eclipse IP Policy before initiating a Review.

With the successful completion of a Release Review, including approval of the Specification Committee by a Super-majority vote, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.

All Specification Versions referenced by a Ratified Final Specification must themselves be Ratified. The Release Review for prerequisite Specification Versions may be run concurrently with the Release Review for a referenced Specification Version.

The Specification Document for the Final Specification must be distributed as read-only text under the Eclipse Foundation Specification License. The Ratified TCK in composite must be distributed under the Eclipse Foundation Technology Compatibility Kit License. Other technical artifacts must be distributed under an Open Source License.

The diagram below is a conceptual model of the transition from a Specification Version to a Final Specification. No specific packaging technology or structure should be implied from this diagram.