Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Development Resources/HOWTO/Creation Reviews

< Development Resources
Revision as of 19:57, 25 August 2008 by Bjorn.freeman-benson.eclipse.org (Talk | contribs) (New page: =Guidelines for Creation Reviews= <div style="border: 1px dashed black; float: right; width: 200px; background-color: rgb(255,255,221); padding: 0 3px 0 3px"> See "[http://www.eclipse.org/...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Guidelines for Creation Reviews

See "6.3.1 Creation Reviews" in the Eclipse Development Process.

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.

(1) What are the Requirements?

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.)

REnough 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.

RClear 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.

RCollaborations.
Successful Eclipse projects extend and enhance the Eclipse tool suite, and thus 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.)

RExtensible frameworks and exemplary tools.
Is this project visibly committed to producing both extensible frameworks and exemplary tools built on top of those frameworks? Eclipse is dependent on its projects producing both frameworks for the ecosystem to extend, and end-user tools to attract the critical mass of users which enable the ecosystem to exist.

RSufficient 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.

GEvidence 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.


This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)

Back to the top