Eclipse Foundation Specification Process
Version 1.4. May 15, 2024
The document describes the Eclipse Foundation Specification Process (EFSP) for optional use by Eclipse Foundation Working Groups.
The EFSP leverages and augments the Eclipse Foundation Development Process (EDP). The EDP defines important concepts, including the Open Source Rules of Engagement, the organisational framework for open source projects and teams, releases, reviews, and more.
Although many of the activities related to this process are conducted by open source projects operating under the EDP, this specification process, and the Final Specifications delivered under it, are to be managed by Working Groups.
Subject to the approval of the Eclipse Management Organization (Executive Director or Delegate), individual Specification Committees may tailor the process for their unique requirements.
This document, and future revisions thereof will be approved by the Eclipse Foundation Board of Directors.
Applicable Documents and Processes
-
The Working Group Participation Agreement for the corresponding Working Group
-
Eclipse Foundation Trademark License Agreement
In the event of any conflict between the terms set forth in this EFSP and the terms of the documents listed above, the terms of those documents shall take precedence.
Terms and Definitions
- Check Point Reviews
-
The Plan Review, the Progress Review, and the Release Reviews.
- Committer
-
A developer who has the necessary rights to make decisions regarding a Project. A Committer on a Specification Project is a Participant Representative.
- Compatible Implementation
-
Any implementation of a Technical Specification that fulfils all requirements of a Final Specification as demonstrated by fulfilling all requirements of the associated TCK.
The notion of a Compatible Implementation is not meaningful for a Process Specification.
- Contribution
-
Content delivered to a Project under the terms of the Eclipse Contributor Agreement.
- Contributor
-
An individual who is a party to the Eclipse Contributor Agreement.
- Creation Review
-
A review to assess the community and membership response to a Project Proposal, verifies that appropriate resources are available for the project to achieve its plan, and serves as a Committer election for the project’s initial Participant Representatives. For a complete definition, see the EDP.
- Final Specification
-
A completed and ratified revision of a Specification.
- Individual Participant
-
An individual Committer Member of the Eclipse Foundation (as defined in the Eclipse Foundation Bylaws) who agrees to actively participate in the Working Group and meets the requirements for participation as defined by the Working Group Charter. An Individual Participant is specifically not employed by a Member Participant.
An individual who is not employed by a Member Participant must first be elected to a Specification Project, and then become a Member of the Eclipse Foundation and Individual Participant of the Specification Project’s Working Group. An Individual Participant is, therefore, a Committer by definition. By extension, an individual relinquishes Individual Participant status when they relinquish Committer status.
- Major Release
-
A type of Release that includes either significant new functionality and/or breaking changes.
- Member Participant
-
A Strategic or Contributing Member of the Eclipse Foundation (as defined in the Eclipse Foundation Bylaws) that agrees to actively participate in the Working Group and meets the requirements for participation as defined by the Working Group Charter.
- Minor Release
-
A type of Release that includes new features over a Major Release.
- Open Source License
-
One of the following OSI-approved open source licenses:
-
Eclipse Public License - v 2.0 (possibly with Secondary Licenses)
SPDX short identifier: EPL-2.0 -
Eclipse Distribution License - v 1.0
SPDX short identifier: BSD-3-Clause -
Apache License - v 2.0
SPDX short identifier: Apache-2.0 -
MIT
SPDX short identifier: MIT
This list may be modified with the Super-majority approval of the Working Group Steering Committee and the Eclipse Foundation Board of Directors.
-
- Participant
-
An Eclipse Foundation Member that agrees to actively participate in the Working Group and meets the requirements for participation as defined by the Working Group Charter.
Membership classes are described on the Eclipse Membership page (and more formally in the Eclipse Foundation Bylaws). Members must have executed the corresponding Working Group Participation Agreement (for more information, see the Participation Structure for Working Groups and Agreements in the Eclipse Foundation Working Group Process).
There are two different types of Participant: Member Participant and Individual Participant.
- Participant Representative
-
Participant Representatives represent the interests of a Participant on a Specification Project. All Committers on a Specification Project are Participant Representatives (the terms Committer and Participant Representative are used synonymously in the context of a Specification Project). The Participant Representative of an Individual Participant is the same person.
- Patent License
-
The Patent License defines how patent grants flow from a Final Specification to an implementer of the specification. The Patent License is either the Implementation Patent License or Compatible Patent License as defined in the Eclipse Foundation Intellectual Property Policy.
- Plan Review
-
A Review to approve a Release Plan to start a Release Cycle.
- Pre-Proposal Phase
-
A phase in the Project life cycle during which an individual or group of individuals declares their interest in, and rationale for, establishing a Project and assembles a proposal to create a new Specification Project. For a complete definition, see the EDP.
- Process Specification
-
A Process Specification describes how a process is put into practice. See Specification.
- Profile
-
A Specification that includes by reference a collection of Specifications and possibly additional requirements.
- Progress Review
-
A type of Review that is used by a Project Team to summarise the accomplishments of the Project, verify that the Eclipse Foundation Development Process and Eclipse Foundation IP Policy have been followed, and to highlight any remaining quality and/or architectural issues. For a complete definition, see the EDP.
- Project
-
A Project is the main operational unit by which all open source development occurs. For a complete definition, see the EDP.
- Project Management Committee (PMC)
-
The primary leadership of a Top-Level Project with responsibility to ensure that the Projects within its supervision are active and viable. For a complete definition, see the EDP.
- Project Proposal
-
A document that describes the Project and the context in which the Project is being created. For more information, see the EDP.
- Project Leadership Chain
-
The leadership chain for a project is composed of the project’s project lead(s), the leadership of the parent project (if any), the PMC leads and PMC members for the Top-Level Project, the EMO, and the EMO(ED). For a complete definition, see the EDP.
- Proposal Phase
-
A phase in the Project life cycle during which a Project Proposal is presented to the community and Membership at Large to solicit feedback. For a complete definition, see the EDP.
- Release
-
A synonym for Final Specification.
- Release Candidate
-
A feature-complete build.
- Release Cycle
-
The cycle of development that produces a Final Specification.
- Release Plan
-
The description of activities to be undertaken as part of a Release Cycle to produce a Specification Version.
- Release Review
-
A Release Review is a type of Progress Review that is aligned directly with a specific Release. This definition is the same as in the EDP.
- Review
-
The EFSP uses the same reviews as defined in the EDP.
- Scope
-
The defined scope of activities for a Specification Project.
- Service Release
-
A Release that includes only minor changes and/or clarifications over a Major or Minor Release.
- Specification
-
A Specification is a description of how something is done, made, or designed. See Process Specification and Technical Specification.
- Specification Committee
-
A committee of a Working Group established to manage this Process for technologies within the scope of its Working Group.
- Specification Document
-
The document that defines a Specification.
- Specification Project
-
An Eclipse Foundation Project operating under the EDP and EFSP that is constituted to deliver Specification Versions. A Specification Project may deliver both Technical Specifications and Process Specifications.
- Specification Team
-
A synonym for Project Team (as that term is defined in the EDP). The Project Team may also be referred to as an Expert Group, Special Interest Group, or Technical Committee.
- Specification Version
-
A completed revision of a Specification which is a candidate to become a Final Specification.
- Super-majority
-
Two-thirds of the eligible voters.
- Technical Specification
-
A collection of Application Programming Interface (API) definitions, descriptions of semantic behaviour, data formats, protocols, and/or other referenced specifications, along with its TCK. See Specification.
- Top-Level Project
-
An organisational unit that defines an overall mission and Scope for a collection of Projects (and Specification Projects). For a complete definition, see the EDP.
- Technology Compatibility Kit (TCK)
-
Software and/or documented requirements that support the testing of implementations to ensure that they are compatible with the Technical Specification.
A TCK is not generally meaningful for a Process Specification.
- Working Group
-
An Eclipse Foundation Working Group established under the Eclipse Foundation Working Group Process. Definitions from the Working Group Process are included herein by reference.
Other terms used in this document are defined in the EDP.
Structure and Organisation
A Specification Project is the main operational unit for Specification development at the Eclipse Foundation.
Specification Projects
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.
|
|
For more information regarding Project creation, see Starting an Open Source Project at the Eclipse Foundation. |
Patent License
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.
|
|
For help regarding selection of a Patent License, see Patents and Specifications. |
A 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
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.
Specification Versions
A Specification Version is a candidate Final Specification.
Each Specification Version references specific versions of its constituent artifacts (if any).
For a Technical Specification, constituent artifacts include the Specification Documents, zero or more other Specifications, one or more Compatible Implementations licensed under an Open Source License, and exactly one associated TCK.
When the result is a Major or Minor Release, a Project Team must engage in a Release Review to ratify a Specification Version as a Final Specification. When the result is a Service Release, a Specification Version is automatically a Final Specification.
Technology Compatibility Kits
Compatibility with a Technical Specification is validated with a Technology Compatibility Kit (TCK). TCKs are not required for Process Specifications.
The Project Team must designate exactly one TCK under an Open Source License for each Specification Version of a Technical Specification. A binary version of the TCK licensed under the Eclipse Foundation TCK License becomes a part of the Final Specification.
The TCK may be different for different Specification Versions/Final Specifications.
Any implementation of a Technical Specification that fulfils all of the requirements of the TCK associated with a Final Specification may claim that it is a Compatible Implementation of that Final Specification. The TCK version associated with the Final Specification must not be modified other than as allowed or required by the rules of the TCK.
All parts of a Technical Specification should be covered by the TCK.
Compatible Implementations
Technical Specifications have Compatible Implementations.
A Compatible Implementation must fulfil all requirements of a Final Specification including all requirements of the corresponding TCK and be in compliance with the Eclipse Foundation TCK License. A Specification Version of a Technical Specification must identify at least one Compatible Implementation under an Open Source License that fulfils the requirements of the TCK.
Participant Representatives
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 Eclipse Project Handbook defines the Committer election process to add additional Participant Representatives, and the Committer retirement process. |
Specification Committee
The Specification Committee works with the PMC to manage the overall vision for the Specification Projects under their supervision.
Approvals
A Specification Committee must approve, by Super-majority, the following life cycle events of Specification Projects:
-
The creation of a new Specification Project;
-
The Release Plan for a new Release Cycle of a Specification;
-
Each revision to the Scope of a Specification;
-
Each Check Point Review of a Specification Project, including the ratification of Specification Versions;
-
Designation of a Specification as a Profile (this Super-majority must include a Super-majority of Strategic Members of the Working Group, when the Working Group has a notion of Strategic Member or equivalent); and
-
Designation of a Profile as a Platform (this Super-majority must include a Super-majority of Strategic Members of the Working Group, when the Working Group has a notion of Strategic Member or equivalent).
A ballot is used to seek Specification Committee approval. Unless otherwise stated in this process (or a Working Group-specific derivative of this process), the default period for all Specification Committee ballots is seven (7) days. During that time, any member of a Specification Committee may request that the period be extended to thirty (30) days.
A Specification Committee may opt to increase the length of the ballot period, but may not—under any circumstances—reduce any review period to fewer than seven (7) days.
All artifacts related to a ballot must be delivered in distribution form to the Specification Committee prior to the start of the ballot period, must not change during the ballot period (with the exception of minor corrections that do not change the semantic intent, as determined by the Specification Committee), and must persist in the delivered form following the ballot as part of the public record.
All other votes of the Specification Committee require a simple majority.
Release Plans
A Release Plan lists themes, areas of focus, and 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 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 Progress 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.
Specification Process
The EFSP is based on the Development Process described in the EDP.
Specification Project Life Cycle
The Specification Project life cycle is defined by the EDP.
Releases
While in the Incubation and Mature Phases, a Specification Project may produce Specification Versions which, when ratified, become Final Specifications. A Release Review is required to ratify all Major and Minor Releases of a Specification Project.
There are three types of Releases: Major, Minor, and Service. A Project Team may consult with their PMC and Specification Committee to determine the appropriate classification.
|
The notions of Major, Minor, and Service Release bear a close resemblance to the "MAJOR.MINOR.PATCH" structure described by the Semantic Versioning specification. While a Project Team may opt to use Semantic Versioning when naming their releases, this process imposes no requirement to do so. Further, this process imposes no requirement to tie any particular type of Release to any particular Semantic Versioning scheme. |
Major and Minor Releases
A Major Release includes significant new features and/or breaking changes. A Minor Release includes new features over a Major Release.
A Specification Project’s first Release must be a Major or Minor Release.
Service Releases
A Service Release includes only minor changes and/or clarifications over a Major or Minor Release. Specifically, a Service Release must not include any significant new features and/or breaking changes. A Project Team may consult with their PMC and Specification Committee to determine precisely what constitutes a minor change and/or clarification.
A Project Team must have previously engaged in a successful Release Review prior to engaging in a Service Release.
|
|
In the case where a Specification Project hosts multiple Specifications, the first release of any individual Specification must be treated as either a Major or Minor Release regardless of its history. |
No reviews are required for a Service Release.
Specification Version Life Cycle
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 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 engage in a successful Release Review before the final Specification Version may be ratified after which the Specification Version becomes a Final Specification.
Reviews
Reviews are a formal process through which all major life 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.
Creation Review
Specification Projects are created using the process defined by the EDP with the added requirement that the Specification Committee must approve the Project Proposal by a Super-majority before the Specification Project can successfully complete a Creation Review.
An existing Project may be converted into a Specification Project via a Restructuring Review. In this case, the Restructuring Review serves as the Creation Review; other changes to the nature of the existing Project (e.g., the Scope) may be included with the Restructuring Review. Unlike a Creation Review, no Project Proposal is required for a Restructuring Review. Like a Creation Review, a Restructuring Review that converts an existing Project into a Specification Project must be approved by the Specification Committee by Super-majority ballot.
The Eclipse Foundation’s Executive Director must approve a Project Proposal before it can be posted for community review. In the event where a Project Proposal undergoes significant changes during the community review period (e.g., the Scope or Patent License is changed), the EMO will confirm the Executive Director’s approval prior to initiating a Creation Review.
A Project Proposal’s selection of Patent License must be approved by the Working Group’s Steering Committee prior to the start of a Creation Review. A Patent License that matches the Working Group default Patent License (as designated by the Steering Committee) is automatically approved. In the case where the Specification Project proposes to use a Patent License that is different from the Working Group’s default the EMO will engage the Working Group’s Steering Committee to vote to approve the exception.
The Working Group’s Specification Committee must approve the Project Proposal by a Super-majority ballot to accept the Specification Project under its supervision. The Specification Committee ballot may be undertaken in parallel with the Creation Review. A Creation Review must run for a minimum of one week; in the case where a Specification Committee ballot is not complete within the review period, the EMO will withhold declaration of the outcome of the Creation Review until after the ballot has completed.
The Project Proposal must not be modified while the Creation Review and Specification Committee ballot are in progress. In the event that the Project Proposal is modified during the review period, the review will be terminated by the EMO. A terminated review can be restarted at a later date.
Upon successful completion of a Creation Review, the EMO will declare the review successful and initiate the process of provisioning project resources.
Plan Review
A Plan Review provides a means for the Project Team to present their Release Plan to the Project Leadership Chain, the Specification Committee, and the community for feedback. The Specification Committee must approve the Plan Review by a Super-majority ballot.
Progress Review
Progress Reviews are used to extend a Release Cycle. During a Release Cycle a Project Team may be required to engage in one or more Progress Reviews.
The Specification Committee must approve the Progress Review by a Super-majority.
Progress Reviews may be combined with a Graduation or Restructuring Review, but must not be combined or overlap with a Release Review.
Release Review
A Specification Project must engage in a successful Release Review at the end of each Release Cycle.
The Specification Version’s final artifacts must be delivered to the PMC and Specification Committee before the start of the Release Review. The final build may be staged before the start of the review, but must not be distributed as an official release until the Release Review is successfully completed.
For a Technical Specification, the Project Team must provide evidence that the TCK selected for the Specification Version provides sufficient coverage to reasonably validate Compatible Implementations and must provide evidence that cited Compatible Implementations fulfil all requirements of the TCK.
A Release Review concludes successfully with approval from the PMC and EMO, and approval by a Super-majority of the Specification Committee.
With approval, the Specification Project must release the final artifacts of the Specification Version.
Ratification
With the approval of the Specification Committee by a Super-majority, a Specification Version can be promoted and distributed by the Specification Committee as a Final Specification.
All Specification Versions referenced by a Final Specification must themselves be 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. A 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.
Exceptions
Exceptions to this process may be granted only with Super-majority approval of the Specification Committee and approval of the Executive Director. All exceptions must be documented as part of the public record. Such documentation must include the exact change to the process, the case or conditions under which it applies, and the votes of each Specification Committee member.
Notwithstanding this exception process, no Specification Committee ballot period may be shorter than seven (7) days.
This exception process may not be used to override a Specification Committee member’s request to extend the ballot period.
Addendum: Process Revisions
Eclipse Foundation Specification Process
To update the EFSP itself:
-
The Executive Director convenes a committee (composed primarily, but not exclusively, of representatives from Working Group Specification Committees) and appoints a chairperson;
-
The Committee initiates the work, gathers requirements, and authors an updated document;
-
The Committee approves final draft by simple majority (lazy consensus);
-
The Eclipse Board of Directors approves the final draft by super-majority vote; and
-
The update is published for use.
Working Group Specification Process
Individual Specification Committees may tailor the process for their unique requirements. To develop their own customization of the EFSP:
-
The Specification Committee initiates work, gathers requirements, and authors an updated document;
-
The Specification Committee approves final draft by super-majority vote (as defined in the EFSP);
-
The Working Group Steering Committee approves final draft by super-majority;
-
The EMO(ED) approves final draft; and
-
The process is published for use.