The Eclipse Foundation Specification Process defines a general framework for developing specifications in open source at the Eclipse Foundation; it extends the Eclipse Development Process (EDP) by adding a few extra checks and balances. In the first installment of this series, we described the EDP; in this second installment, we introduce the Eclipse Foundation Specification Process (EFSP) with a focus on how it extends the EDP. We’ll provide more detail and tackle why it’s implemented as it is in future installments.
Note that we’re using the same form of pseudo-legal style capitalization of defined terms that we use in the EDP, EFSP, and other policy documents in this post.
Like regular Eclipse open source projects, a Specification Project starts life as a Proposal with a description, scope, list of committers, and more; goes through an iterative development cycle that produces one or more Milestone builds; and then engages in a release process.
Unlike a regular Project, a Specification Project must be aligned with exactly one Eclipse Foundation Working Group. The Working Group designates a Specification Committee that maintains and manages the specification process on the Working Group’s behalf (when we talk about the Specification Committee in the context of a Specification Project, we mean the Specification Committee of the Working Group with which the Specification Project is aligned).
A Specification Project must get approval from the corresponding Specification Committee to pass key project lifecycle events. In this regard, the role of the Specification Committee is very similar to the governance role of the Java Community Process’ (JCP) Executive Committee.
It’s worth noting that the EFSP provides the general framework for doing specifications in open source at the Eclipse Foundation and that we expect multiple Working Groups to leverage it for that purpose. We also fully expect that a Specification Committee will augment the process as it’s defined. We expect, for example, that we will have a Jakarta EE Specification Process that uses the EFSP as its foundation.
The Specification Committee needs to approve of the creation of a Specification Project from a Proposal by taking a role in the Creation Review. The expectation is that the Specification Committee members will consider the details of the proposed Specification Project (with particular focus on the Scope) before making their decision. In addition to the requirements defined by the EDP, a Super-majority affirmative vote of the entire Specification Committee is required to approve a Creation Review.
Following successful creation and provisioning of project resources, the Specification Project begins development. During the development cycle, the project team must produce at least one Milestone build of the specification’s content (documentation and technical artifacts) to solicit feedback, and at least one of the Milestone builds must serve as a trigger to engage in a Progress Review.
Progress Reviews, a new addition to the EDP (introduced with the 2018 version), are roughly equivalent to Release Reviews, but with the intent of ensuring that the Specification Project is progressing in a manner that will ultimately result in a successful release. A Specification Committee and Project Leadership may compel a Specification Project to engage in additional Progress Reviews.
For a Progress Review, the Project Management Committee (PMC), and Eclipse Management Organization (EMO) validate that the Project Team is following the EDP and EFSP, and that the Eclipse Foundation’s Intellectual Property Policy is being correctly implemented. The EFSP further requires that the Specification Committee approve a Progress Review by Super-majority vote.
At the end of every release cycle, the project team must produce a Release Candidate build that we label as a Specification Version and then engages in a Release Review. For a Release Review, the PMC, EMO, and Specification Committee all engage in the same sorts of activities that they do for a Progress Review, but with the understanding that approval results in the ratification of the specification and promotion to an official status. The EFSP requires that the Specification Committee approve a Release Review by Super-majority vote.
Following a successful Release Review, the final release version of the Specification Artifacts are considered Ratified and morph into what the process refers to as a Final Specification. It is the Final Specification that must be used to build Compatible Implementations.
Following a successful first release (and every subsequent release thereafter), and before engaging in any further development of the specification, the project team must assemble and present their Plan for review by the Specification Committee via Plan Review. The notion of a Plan Review is specific to the EFSP (since Plan Reviews are not part of the EDP, no formal involvement from the PMC is required). A Plan Review provides the Specification Committee with an opportunity to ensure that the plan for the next Specification Version is in-scope, fits within the overall vision of the Working Group, and is otherwise charting a path to eventual ratification and release. The EFSP requires that the Specification Committee approve a Plan Review by Super-majority vote.
After the Plan is approved, the Project Team engages in Development as before.
We’ll discuss the relationship between Specification Projects, Working Groups, and Specification Committees; what happens when the Specification Committee does not approve a vote; the relationship between a Specification Version and Final Specification; and more in future posts.
Mike and I delivered a talk about this at EclipseCon Europe 2018, titled “Introducing The Eclipse Foundation Specification Process” (or go directly to the video on our YouTube Channel).
Please see:
