The Eclipse Foundation Specification Process (EFSP) was authored as an extension to the Eclipse Development Process (EDP). With this in mind, before we can discuss the EFSP, we’ll start with a quick EDP primer.
At a high (and very simplified) level, the EDP looks a little something like this:
All open source projects at the Eclipse Foundation start life as a proposal. A proposal literally proposes the creation of a new open source project: the proposal document suggests a name for the new project, and defines many things, including a description and scope of work. The proposal also serves as the nomination and election of all project committers and project leads.
The proposal is posted for community feedback for a minimum of two weeks; during that time, the Eclipse Foundation staff works behind the scenes to ensure that the project’s name can be claimed as a trademark, a mentor has been identified, the licensing scheme works, and more. The community feedback period ends with a creation review which lasts for a minimum of one week. The creation review is the last opportunity for the community and the members of the Eclipse Foundation to provide feedback and express concerns regarding the project.
After successful completion of the creation review, and the project resources have been provisioned by the Eclipse Webmaster team, the project team engages in development. Project committers push code to into the project’s source code repositories, and produce and disseminate milestone (snapshot) builds to solicit feedback as part of an iterative development process.
When the time comes to deliver a formal release, the project team produces release candidates and engages in a release review. A release review provides an opportunity for the project team to demonstrate to their Project Management Committee (PMC) that their content is ready for release, work with the Eclipse Intellectual Property Team to ensure that all of the required IP due diligence has been completed successfully, and give the community and membership a final opportunity provide feedback and express concerns. Following a successful release review, the project team will push out their final (GA) build and announce the official release to their community via established channels.
The proposal serves as the first plan for the new open source project. Subsequent releases start with the creation of some sort of plan before reengaging in the development (release) cycle. The level of formality in the planning process varies by project. For many projects, the plan is little more than an acknowledgement that further development is needed. But for some projects, planning is a well-defined open process by which the committers work with their communities to identify themes and issues that will be addressed by the release.
In my next post, I’ll discuss how this process is extended by the the EFSP. Then, I’ll start digging into the details.
You can find the community draft of the Eclipse Foundation Specification Process here.
Please see:
