Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Development Resources/HOWTO/Creation Reviews
The purpose of the Creation Review is to assess the community and membership response to the proposal, to verify that appropriate resources are available for the project to achieve its plan, and to serve as a committer election for the project's initial Committers. The Eclipse Foundation strives not to be a repository of "code dumps" and thus projects must be sufficiently staffed for forward progress.
Contents
Overview
The creation review is only part of the overall project creation process which starts with a project proposal and ends with your code being available for download. Please see Starting a New Open Source Project of the overall process.
Creation reviews occur over five generally-accepted business days, generally Thursday to Wednesday. They are an extension of, and a natural conclusion to, the community review period for your project proposal. As such, your only real commitment during the review is to continue to monitor the proposal's communication channel and answer any questions related to your project.
At the end of the review period, the EMO will declare the review complete (reviews tend to end successfully).
Note: There are no calls. We used to have a phone call at the end of each review period; we don't do this anymore.
After the review, the EMO will initiate the provisioning process. As part of the committer provisioning process there will be paperwork requirements initiated via email; please make sure that your project's committers respond to these email requests in a timely manner as the Webmaster Team cannot provision any project resources until after at least one project committer's paperwork has been processed.
- The Webmaster and IP Teams will configure the resources that your project needs;
- Before you commit any code into any project source code repository, you must get approval of your Initial Contribution from the Eclipse IP Team through the Eclipse IP Due Diligence Process.
Checklist
Prior to scheduling the creation review, the EMO will check for the following things:
- Proposal document is complete
- Top-level project along with any containing (i.e. second-level project) is indicated
- Project has a well-defined scope
- Project lead is identified
- The specified email addresses for project committers are correct (note that the proposal document will display warning messages for any committer email addresses that are not already registered to an Eclipse Foundation account)
- Biographical information (as it relates to the project) is provided for each initial committer
- Two Architecture Council Mentors are identified
- PMC approval has been obtained
- Trademark assignment is complete
- All questions have been satisfactorily answered in the communication channel
- Qualitative requirements are satisfactorily addressed
More information
Helpful Documentation from the Eclipse Development Process
Trademark Assignment
Each new project must have a trademark review on the project name and the project nickname (if any). You don't need to specifically request a trademark review; the EMO will initiate it when you request to schedule your Creation Review. We need at least two weeks to complete a trademark review, so please be sure to request your Creation Review at least three weeks before the start of your preferred review period. Earlier than three weeks is even better!
Intellectual Property
Be sure that you have read the Parallel IP Process Guidelines and understand that you must submit a Contribution Questionnaire for your Initial Contribution before you check it into your project's source code repository.
PMC Approval
Please forward an email showing that you have PMC approval for the review. The easiest way to do this is to request approval on your PMC mailing list and forward the response to EMO.
Mentors
You require two Architecture Council Mentors for your project. You can request mentors any time after your project has been posted in draft form, but well in advance of initiating a creation review. To request mentors, create a bug against The Architecture Council including a link to the proposal document.
Review Documentation
The proposal document can serve as the creation document.
In years past, a second document--generally a presentation--was created for reviews. We have done away with this practice as the presentation tended to be little more than a reflection of the information already present in the proposal document.
Committers
The Creation Review acts as the new committer election for the initial Committers and thus the on-line version of the proposal and the review documentation must contain the same level of nomination justification and background as an election would.
The committer bios don't have to be long or involved, but they should describe each committer's relationship to and history with the incoming code, and/or involvement with the area or technologies covered by the proposal. This document includes some good examples of committer bios.
Code
In general, a new Eclipse project should start with code. That code may have been developed in-house, or at one of any number of hosting services (e.g. Eclipse Labs).
Timing
As a project proposal leader, you may ask the question "when can we hold a Creation Review for our proposal?"; the primary answer is: "we will hold the Creation Review as soon as you are confident that you have sufficient community support for the proposal". The EMO will assist you in making that decision using (at least) the following criteria: (Note that these criteria are mostly qualitative and thus - except for a few cases - there are no "right answers". The expectation is that proposers will have good answers for questions around these criteria in order to pass the Creation Review.)
Qualitative Requirements
Enough Developers.
The project has sufficient committed developers to achieve its goals. The Eclipse Foundation is not a place to "abandon in public" code; rather, the Eclipse Foundation strives to have active projects with active communities and thus enough developers to move the project along.
Clear and Concise Description.
If the community found any aspects of the proposal confusing, unclear, or using unfamiliar jargon, those areas must be clarified. This is a hard and fast requirement: because the Eclipse community must be able to evaluate the proposal. To do that, they must be able to understand the proposal and thus it must be clear and straightforward and free of marketing-speak.
Collaborations.
Successful Eclipse projects are those that collaborate with existing Eclipse, or other open source, projects. Again, it can be hard to start a collaboration before demonstrating the technology, but at the same time it is never too early to start discussing collaborations with other projects. Additionally, it never hurts to join and help an existing project to start establishing those social networks that will make future collaborations on the new project possible.
For each place this new project overlaps an existing Eclipse project, what does the overlapee say about the potential overlap? (Note that the overlapee's opinion is not required to be positive, but that it is important for new projects to understand where they fit and for existing projects to understand what new developments might be coming along.)
Sufficient Time for the Community.
The minimum time from posting a proposal to a Creation Review is no less than two weeks. Anything less than two weeks of general accepted business days would not be giving the Eclipse membership sufficient notice of new initiatives.
Evidence of Activity.
Proposals that are more than three months old without having been created as a Project are, perhaps, not sufficiently supported by the community as the original proposers believed. Thus proposals older than three months have a somewhat greater burden of proof that they will be viable Eclipse Projects.
Best Practices
In addition to the qualitative requirements, the Eclipse membership is interested in a number of "evidence of best practice" indicators.
Communities.
Does the project have a community of contributors and users, outside the core developers, who are willing to work towards making this a success? This is a bit of a Catch-22 situation because it is sometimes hard to attract a community before any milestones or releases, but it is also true that projects with limited developers and even fewer users tend not to have much technical impact.
Diversity.
Is this a single company project or a multi-organization effort? If all the committers and contributors are in the same organization or have financial ties to the same organization, the project is at a greater risk of being de-staffed. Brand new projects are not required to be diverse, but projects cannot graduate from incubation without appropriate diversity.
Technical Scope.
Does the project have a technology scope and focus which will have a reasonable likelihood of success? Projects that are too big will definitely fail; projects that are too small are unlikely to be interesting.
Maturity Plan.
The proposal needs to define the destination/end-game/ultimate objectives for the project. What is the expected time scale for this project? Which is the destination top-level PMC for this project? For example, does this project expect to investigate technology for two years and then have proven itself sufficiently to be integrated into the Platform as a component? Does this project expect to be integrated into a the Web Tools Platform as a sub-project (and thus continue to exist, but under that PMC)? Etc. Note that this section is about a plan, not a commitment, but it does need to be a realistic and believable plan.
Following Eclipse Rules.
The Eclipse Foundation attempts to minimize the number of restrictions and rules placed on projects but there are a few. Because it is the responsibility of each Eclipse committer and project lead to understand and implement this minimal set of standards, a proposal team that shows a disregard (either deliberate or through a lack of effort) for these policies (such as the press guidelines) does not endear themselves to the Eclipse community. The Development Resources page provides pointers to a great deal of information about the Eclipse Development Process and more. At a minimum all prospective committers on the new project should be familiar with the New Committer Handbook.
This page is moderated by the EMO