Eclipse Foundation Specification Process Changes

A Specification Project is an open source Project (as that term is defined by the EDP) concerned with the development and delivery of Specifications.

A Specification Project is contained, either directly or indirectly, in exactly one Top-Level Project. The Scope of a Specification Project is bounded by the Scope defined in its Top-Level Project’s Charter.

A Specification Projects is aligned with exactly one Working Group. The Scope of a Specification Project is bounded by the Scope defined in its Working Group’s Charter.

Specification Projects operate under the supervision of both the Project Leadership Chain and their Working Group’s Specification Committee.

At the time of creation, a Specification Project must provide a well-defined Scope that is bounded by the Scope of its Top-Level Project. Since a change in Scope may change the nature of the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.

A new Specification Project may be created via Project Proposal and Creation Review; alternatively, an existing Project may be converted into a Specification Project via Restructuring Review.

The Patent License defines how patent grants flow from a Final Specification to an implementer of the Specification. The Eclipse Foundation Intellectual Property Policy defines two choices for Patent License: Implementation Patent License or Compatible Patent License.

TheA Process Specification project always utilises the Implementation Patent License.

When a Working Group engages in Technical Specification development, the Working Group’s Steering Committee must set the Working Group’s default Patent License for its Specification Projects following the process defined by the Eclipse Foundation Working Group Process. In the absence of an explicit Steering Committee decision to the contrary, the Implementation Patent License prevails.

All Specifications produced by a Specification Project must use the same Patent License.

At the time of creation, a proposal to create a new Specification Project or convert an existing Project into a Specification Project must explicitly state its choice of Patent License.

The Working Group’s Specification Committee must confirm, prior to initiating a ballot that will result in the establishment of a Specification Project, that the selection of Patent License matches the default Patent License. The Working Group’s Steering Committee must approve exceptions to the Working Group’s default Patent License.

Specifications must be developed by Specification Projects. A Specification Project may be used to develop multiple Specifications.

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 successful Super-majority ballot of the Specification Committee is required to approve designation of a Profile Specification. A Specification Committee may, at its discretion, elect to label one or more Profiles as a Platform.

Committers on Specification Projects must either work for a Member Participant or individually become an Individual Participant, thereby working on behalf of a Participant. By definition, a Committer on a Specification Project is a Participant Representative. The terms Committer and Participant Representative are therefore used synonymously in the context of a Specification Project.

Participant Representatives must either be employed by a Member Participant, or may complete the membership process independently as an Individual Participant.

In the case where a Member Participant has no Participant Representative on a Specification Project, they may appoint one. In the case where a Member Participant already has representation by one or more Participant Representatives on a Specification Project, they must follow the Committer election process as defined by the EDP to add additional Participant Representatives.

An individual who is not affiliated with a Member Participant must be elected as a Committer to a Specification Project following the Committer election process defined by the EDP, before becoming an Participant Representative as an Individual Member.

Participant Representatives may retire (or be retired by the Project Leadership Chain) from a Specification Project via the Committer retirement process defined by the EDP.

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

A Release Plan lists themes andthemes, areas of focus, describes Milestone Builds, 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 Milestone Builds and Reviews, are determined by both the Project Leadership Chain and the Specification Committee. Minimally, a Release Plan must include a textual description of the activities planned for the Release, and tentative dates for Milestone Builds, Progress Reviews,Reviews 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 may, at their discretion, require that the project team engage in additional Progress Reviews.

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 of the Specification Committee. If the Release Plan is rejected, the Project Team may reapply at a future date.

The Specification Project life cycle is defined by the EDP.

To produce a Specification Version (with the exception of Service Releases) a Project Team must engage in a formal Release Cycle under the supervision of the PMC and the Specification Committee.

A Specification Project’s first Release Cycle starts with the successful completion of a Creation Review (or Restructuring Review in the event that a Restructuring Review is used to convert an existing Project into a Specification Project). To start a subsequent Release Cycle (and every Release Cycle thereafter), the Project Team must present a Release Plan to the Specification Committee in a Plan Review. The Plan Review must be approved by a Super-majority of the Specification Committee.

A Release Cycle ends when the Project Team delivers a Specification Version to the EMO and Specification Committee via a Release Review. To extend the Release Cycle, the Project Team must stage a Milestone Build and engage in a Progress Review. The Project Team must engage in either a Release Review (which ends the Release Cycle) or a Progress Review (which extends the Release Cycle) within twelve (12) months of the last Review.

The Project Team must deliver at least one Milestone Build to demonstrate progress and solicit feedback. Milestone Builds may be incomplete (for example, designated Compatible Implementations will not necessarily pass Milestone Builds of the TCK in their entirety). Subsequent Milestone Builds should, however, demonstrate progress. Later (feature complete) Milestone Builds may be referred to as Release Candidates.

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

Reviews are a formal process through which all major lifecyclelife cycle 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 of the Specification Committee is required to successfully complete a Review. Such Review must 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 Project Team must complete all required due diligence under the Eclipse Foundation IP Policy before initiating a Review.

With the approval of the Specification Committee by a Super-majority, 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.Final Specifications. 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 RatifiedA Technical Specification can use either version 1.1 or 2.0. A Process Specification must use version 2.0.

A TCK for a Final Specification in composite must be distributed under the Eclipse Foundation Technology Compatibility Kit License. Other technical artifacts must be distributed under an Open Source License.

To update the EFSP itself:

Individual Specification Committees may tailor the process for their unique requirements. To develop their own customization of the EFSP: