The Eclipse Foundation Specification Process (EFSP) includes an image that provides an overview of what goes into creating a new Specification Project. By creating, we mean the process of taking a Specification from an initial idea or concept through to the point where the necessary resources and permissions are in place to do real development. It’s the same basic process that we follow when creating a regular Eclipse Project with an extra Specifications-specific approval added in.
The first couple of steps of the project creation process usually happen via private email exchanges between the people involved with the project and the Eclipse Management Organization (EMO) (this is one of the few things that we do in private at the Eclipse Foundation). With this communication, we take the idea behind a Specification Project and create a Proposal that describes and defines it. The Proposal includes important information like a statement of Scope, a description, and the list of the initial Specification Team (Project Leads, Committers, and Mentors). Other useful information is contained the Proposal, including background information, descriptions of content that already exists, and initial plans.
In the steady state (i.e. after the Specification Project has been created), all roles are assigned via demonstrations of merit and votes from the existing Committers. Since we have no existing Committers before the project is created, the creation process serves as the display of merit for the community and vote.
The EMO works with the proposers to whip the Proposal into shape. When the EMO decides that the content is complete, it is delivered to the Executive Director of the Eclipse Foundation (EMO(ED)) for approval to post for community review.
Once we have EMO(ED) approval and the Proposal is posted for the community to review, it is said—according to the Eclipse Development Process (EDP)—to have entered the Proposal Phase. We often refer to this as the community review period. During this period, other developers may step up and volunteer to become Committers, community members may ask questions, the Scope and other aspects of the Proposal may be tweaked, and more. Crucially, during this period, Member Companies of the Eclipse Foundation have an opportunity to express concerns and even (possibly) reject the Project Proposal (this has never actually happened). A Specification Project must stay in the Proposal Phase for a minimum of two weeks to give the various stakeholders enough time to review and respond.
The EMO uses the Proposal Phase to ensure that we can reasonably assert ownership of the Specification Project’s name as a trademark on behalf of the community (or at least that the project name does not infringe on somebody else’s trademark). If a Specification Project’s name is already used by the Specification Team (or an organization that’s involved with the Proposal), then EMO will work with them to transfer ownership of the trademark and associated Internet domains to the Eclipse Foundation. In parallel, the EMO will also work with the Eclipse Architecture Council to identify a Mentor, and seek approval from the Project Management Committee (PMC) of the target Top-level Project. It’s not shown on the image, but we’d use this time to inform the corresponding Specification Committee that the new Specification Project is coming.
At the Eclipse Foundation, we organize all Projects and Specification Projects hierarchically. Top-level Projects, which sit at the the top level of the hierarchy, are generally not used for actual development work. It is in the Projects (also referred to as Subprojects) under the Top-level Projects where the real work happens. All Top-level Projects have a PMC who—as part of the Project Leadership Chain for all projects that fall under the Top-level Project—are responsible for ensuring that the Specification Teams work as good open source projects (as defined by the EDP).
When all of these separate threads are resolved, we move to the Creation Review. During this period, no further changes are allowed and the Proposal is locked down. The EMO uses this time to ensure that the process was followed. The Creation Review lasts for a minimum of one week. We schedule all reviews—Creation Reviews included—based on the date that they conclude; reviews are scheduled to conclude on the first and third Wednesday of every month (we may schedule additional reviews in exceptional cases).
To successfully complete a Creation Review for a Specification Project, the EFSP requires that we have Super-majority approval of the Specification Committee (Super-majority is defined as two thirds of the Specification Committee members). The EFSP is silent regarding the specifics of how such a vote is executed, but is generally accepted that votes run for a minimum of a week (a Specification Committee may decide that more or less time is required). The factors that the Specification Committee must consider when casting their votes are also not specified. In general though, the Specification Committee will be looking at whether or not new Specification Project Proposals are viable and are a good fit with the corresponding Working Group.
Upon successful conclusion of the Creation Review, the Proposal is sent to the Eclipse Webmaster Team for provisioning. The provisioning process starts with Committer Paperwork: once we have complete paperwork for one Committer, the Webmaster will create resources including websites, Git repositories, Issue trackers, etc. for the Specification Team.
With provisioned Committers and resources, the Specification Project is said to be in the Incubation Phase (or “in incubation”); it will stay in this phase until the Specification Team engages in a Graduation Review (which is generally combined with the project’s first or second Release and corresponding Release Review). The first action of the Specification Team with their new Specification Project is to submit their Initial Contribution (when a Specification comes to the Eclipse Foundation with existing intellectual property) to the Eclipse IP Team for review; with their approval of the Initial Contribution, that content can be added to the project’s Git repository and the Specification Team can start to weave their magic.
Please see:
