Eclipse Foundation Specification Process Operations Guide

The specification committee is responsible for implementing the EFSP for all specification projects (as that term is defined by the EFSP) that operate under the purview of the a working group. A working group may, via their charter, assign specification committee responsibilities to another committee.

The specification committee is ultimately responsible for ensuring that the final specifications produced by the working group’s specification projects make sense. The definition of “makes sense” varies by specification committee participant, but is generally understood to mean that the specification can be implemented and that those aspects of the Eclipse Intellectual Property Policy with regard to essential claims are observed. In practical terms, specification committee participants wield power via the ballots that are required to approve key lifecycle events per the EFSP.

The Specification Committee is responsible for producing, publishing, and maintaining operational guidance documentation for specification projects. This includes the minimum requirements and process for producing a final specification. It also includes operational guidance for running a specifications TCK for the purpose of testing for compatibility.

The Specification Chair (or their delegate) is responsible for initiating ballots, tallying their results, disseminating them to the community, and (when appropriate; e.g., in the case a release review ballot) reporting them to the EMO.

The Specification Committee is also responsible for defining and refining how they implement the EFSP for those Specification Projects under their purview.

A specification project has one or more project leads. Project leads are the main liaison between the project team and the Eclipse Management Organization (EMO), and are responsible for ensuring that team members are implementing their responsibilities under the EDP, EFSP, and the Eclipse Foundation’s IP Policy. The lead is responsible for initiating reviews as the project reaches the appropriate milestone.

The EFSP states that a member participant may appoint a participant representative committer. A member participant is defined as a strategic member or contributing member of the Eclipse Foundation that is a participant in the working group (i.e., has signed the corresponding working group participation agreement). In the case of specifications, vendor-neutrality trumps meritocracy. A specification process must be accessible to all companies who wish to participate.

Appointment of a participant representative:

Appointing a participant representative this is a power that a member participant will use to ensure that they have at least one committer on a specification project. If the member participant already has an employee as a committer, then that member participant is considered to already have a participant representative and cannot appoint another.

Additional committers can be added via committer election.

Use the web form to create a new project proposal. This is the same form that we use for all Eclipse Projects and it captures the same sort of information, including the identity of the working group under which the specification project is intended to operate (the field labelled "Is this a specification project?").

A proposal document is initially accessible only by the person who creates the proposal and anybody that they list in a project role. Everyone who is listed as a project lead will have read and write access to the proposal document while it is in this draft state; all other listed persons will have read access.

To open the proposal for community review, send a note to the mailto:emo@eclipse-foundation.orgEMO. The EMO will review the proposal and may make recommendations for changes to the team. When the EMO is satisfied that the proposal is ready for community review, they will open the proposal for community review.

Immediately after opening a specification project proposal for community review, the EMO will request approval from the corresponding PMC and inform the corresponding specification committee.

The EMO will connect with the PMC via their mailing list request their approval. With their approval, the PMC indicates that they believe that the scope of the specification project fits in with the overall mission and scope of the top-level project and that they are prepared to provide guidance to the project team and participate in the specification project’s governance as required by the Eclipse Foundation Development Process. The EMO will accept a +1 from any member of the PMC as approval on behalf of the entire PMC. PMC approval is required before the start of the creation review.

Every development cycle starts with a plan and a plan review. The project team assembles their release plan, the project lead (or their delegate) presents the plan to the specification committee, and the specification committee initiates plan review. The plan review consists entirely of a ballot of the specification committee. A super-majority of the specification committee must vote to approve the plan.

A plan should concisely describe the new features and themes on which the development team intends to focus. The level of detail required in a plan varies by working group.

Committers work in a specification project Git repository. Committers collaborate, accept contributions from contributors, and otherwise construct the specification.

If a development cycle extends beyond a year, the project team must engage in a progress review.

To initiate the release process, the project team starts by creating a specification version. A specification version is, effectively, a release candidate build of the specification document and related artifacts.

A creation review is required before a new specification project is created.

Creation reviews are tracked and managed by the EMO. A creation review requires a ballot of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.

In considering their vote in the ballot, the question that specification committee members must consider is whether or not they would vote to approve the eventual release, ratification, and creation of a Final Specification when the project returns for a release review. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Plan reviews occur at the start of a development cycle. A creation review serves as the plan review for a specification project’s first release.

Plan reviews are not formally tracked or managed by the EMO, but rather are initiated and managed directly by a member of specification committee; the EMO can provide assistance if required. In practice, a plan review requires no more formal ceremony than a successful ballot of the specification committee.

When reviewing a plan, the question that specification committee members must consider is whether or not they would vote to approve the eventual completion of the plan when the project returns for a release review. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Ideally, when casting their vote, specification committee members should focus less on the mechanics of implementing the plan and more on the broader implications of the themes and changes suggested in the plan to implementors, adopters, and the ecosystem.

A release review is required for all major and minor releases from a specification project. The review may be skipped for service releases that do not implicate any new intellectual property (i.e., bug fixes only). A specification project must engage in a release review for the first release of all specifications (independent of whether or not it is a major, minor, or service release).

Releases of specification projects operate under the EDP augmented by the EFSP. Release reviews are tracked and managed by the EMO. A release review requires a ballot of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.

The basic timeline for a release review is as follows.

The review itself involves several parallel activities:

While the above chart shows that the ballot occurs after the review starts, the ballot can be initiated at any time. The requirement is that the ballot must conclude with an affirmative result before the review can be declared successful.

It is up to the individual parties to determine the basis on which they will vote in the ballot. When determining how to vote, the question that specification committee members must consider is whether or not they believe that the specification as written can be implemented, that the TCK is complete enough, and whether or not the project team has met their obligations under the EFSP. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

A progress review is required by a specification project when the time elapsed between a Plan Review and a Release Review exceeds one year.

Progress reviews are tracked and managed by the EMO. A progress review requires a ballot of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.

The specification committee may make additional requirements. The specification project team should communicate their intent to engage in a progress review with the specification committee in advance to ensure that any additional requirements are addressed and that the specification committee has an opportunity to ask questions and otherwise provide guidance in advance of the initiation of the ballot.

Before initiating a Progress Review, the specification project team and specification committee need to coordinate and discuss the state of the specification work, and decide on what—​if any—​mitigation work is required. This discussion should occur on a public channel (either on an issue in a a public project or working group issue tracker, or on the specification committee’s public mailing list). The process can be initiated by a specification project committer, a PMC member, or a working group representative. The specification project team and specification committee should reach agreement on the state of the project and any mitigation that is required before initiating the Progress Review.

With the conditions established, a project committer must contact the EMO to initiate the review.

When determining how to vote in a release review ballot, the question that specification committee members must consider is whether or not they believe that the specification is progressing in a manner that will produce a specification that can later be ratified. If the answer is yes, then the specification committee member should vote in the affirmative +1; they should either vote in the negative -1 or abstain +0 otherwise.

Progress Reviews are posted for community review for one week.

A restructuring review is required whenever the nature of a project is changed.

Examples include (but are not limited to):

Where:

The <details> for a release review ballot should include:

The <details> for a progress review ballot should include:

Restructuring Reviews are used to change the structure of a project. A restructuring review would be used to, for example, move a specification from one project to another, move a specification project from one working group to another, or convert an existing open source software project into a specification project.

The <details> for a restructuring review should concisely describe the changes that are proposed. This could be as simple as a statement stating that "The Eclipse Foo project will be converted into a specification project.", but other changes may be included.

For example:

The most critical aspect of the EFSP is the management of essential claims as defined by the Eclipse IP Policy. In this regard, the requirement that all committers be covered by an Eclipse Foundation Membership Agreement and Working Group Participation Agreement cannot be relaxed. By extension, the restrictions placed on participants and participant representatives cannot be relaxed in any customisation of the process, nor can the ability of a participant to appoint a participant representative be inhibited in any way.

The requirements regarding scope must not be relaxed. Specifically, the requirements regarding approvals and the requirement that the development work of the project stay with the boundaries defined by the scope must not be curtailed.

The underlying principles of open source (the so-called “Open Source Rules of Engagement”) may not be curtailed. Specifically, all specification projects must operate in an open and transparent manner, must follow meritocratic practices to promote individuals to positions of power and authority, and (although not strictly listed as a rule of engagement) operate in a vendor neutral manner.

The powers granted to the project leadership chain by the EDP must not be restricted.

In general, quantities included in the EFSP and EDP can be increased, but not decreased. For example, the period of time required to run a simple ballot (e.g. a committer election) must not be less than seven days (it is generally accepted at a week is a reasonable minimum period of time to run a ballot that meets a minimum standard of community inclusion).

The EFSP defines a set of underlying principles and fundamental requirements. It intentionally does not define any sort of practical implementation, or prescribe any specific technologies. Specialisations of the process should take a similar approach. The process might, for example, extend the amount of time required for a specification committee ballot; but any attempt to describe the specific mechanisms and technology by which a ballet is run in a practical sense is more of an operational detail that should be defined in an operations document.

In order to be able to claim compatibility with a specification, the Eclipse Foundation TCK License requires that you send your TCK results to tck@eclipse.org. The note is a means by which you satisfy the terms of the TCK license by notifying the Eclipse Foundation of the results; it is not a request to approve the results. The Eclipse Foundation keeps a record of the results; it does not approve the results.