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.

See "[http://www.eclipse.org/projects/dev_process/development_process.php#6_3_1_Creation_Review 6.3.1 Creation Reviews]" and "[http://www.eclipse.org/projects/dev_process/development_process.php#6_3_Reviews 6.3 Reviews]" in the Eclipse Development Process.

+

−

</div>

+

−

<blockquote>

+

=Overview=

−

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

+

Please see [[Development Resources/HOWTO/Starting A New Project|Starting a New Project]].

−

</blockquote>

+

−

===What are the Requirements?===

+

Here is what you can expect from a creation review:

+

+

==Before the Review==

+

* You assemble a proposal. Proposals must be provided using our standard template.

+

* The proposal document is sent to the EMO for review.

+

* EMO posts the review in draft form on the [http://www.eclipse.org/proposals eclipse.org/proposals] page and invites your feedback.

+

* EMO posts the live document and invites community review.

+

** The project will be announced in a quasi-weekly note sent to the members and committers of the Eclipse Foundation.

+

** An entry will be made in the [http://www.eclipse.org/forums/eclipse.proposals Proposals Forum].

+

** A [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&component=Proposals%20and%20Reviews&product=Community&classification=Eclipse%20Foundation bugzilla record] will be created to track the proposal and review.

+

* You monitor the communication channel (Proposals Forum) and answer any questions posed about the project

+

* With assistance from EMO, you solicit two mentors for your project from the [[Architecture Council]].

+

* When you believe that your project is ready for creation, you request that the EMO schedule a creation review.

+

** A project proposal must be available for community review for a minimum of two weeks.

+

* The EMO will initiate a trademark review on your project's proposed name

+

** The review will be scheduled only after the Eclipse Foundation has taken ownership of your project name's trademark.

+

+

==During the Review==

+

* Reviews occur over five generally-accepted business days, generally Wednesday to Wednesday.

+

* You continue to monitor the 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.''

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!

Be sure that you have read the [http://www.eclipse.org/projects/dev_process/parallel-ip-process.php Parallel IP Process Guidelines] and understand that you must submit a Contribution Questionnaire for your [[Development Resources/Initial Contribution | Initial Contribution]] before you check it into CVS.

+

+

== 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 [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Architecture%20Council 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. [http://www.eclipse.org/proposals/maya/maya_creation_review.pdf 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. [http://eclipselabs.org 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.)

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

'''Enough Developers.'''

Line 24:

Line 102:

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

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

−

−

'''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. [http://eclipselabs.org Eclipse Labs]).

−

−

'''Extensible frameworks and exemplary tools.'''

−

−

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

'''Sufficient Time for the Community.'''

'''Sufficient Time for the Community.'''

Line 41:

Line 111:

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.

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.

−

===Mentors===

+

=Best Practices=

−

+

In addition to the [[#Qualitative Requirements | qualitative requirements]], the Eclipse membership is interested in a number of "evidence of best practice" indicators.

−

Proposals are required to have at least two Mentors before scheduling a Creation Review (see "[http://www.eclipse.org/projects/dev_process/development_process.php#6_1_Mentors 6.1 Mentors]"). The name, corporate affiliation(s), and current Eclipse projects/roles must be listed in the on-line version of the proposal and in the documentation for the Creation Review.

+

−

+

−

The proposal leads are responsible for recruiting the mentors. Mentors are not recuited or assigned by the EMO. The EMO will provide advice on who the proposal leads might approach as mentors, but neither the proposers nor the suggested mentors are obligated to act on that advice.

+

−

+

−

Mentors must be existing members of the Architecture Council (see the [http://www.eclipse.org/org/foundation/council.php#architecture membership page]). The best way to attract the attention of the whole Architecture Council and solicit mentors is to open a bug against [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Architecture%20Council Community/Architecture Council].

+

−

+

−

===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 Creation Review documents must include short nomination bios of the proposed initial committers. These bios should discuss their relationship to, and history with, the incoming code and/or their involvement with the area/technologies covered by the proposal. The goal is to help keep any legacy contributors connected to new project and explain that connection to the current and future Eclipse membership, as well as justify the initial Committers' participation in a meritocracy. ''

+

−

</blockquote>

+

−

+

−

===What are the Best Practices?===

+

−

In addition to the [[#What are the Requirements? | required pre-requisites]], the Eclipse membership is interested in a number of "evidence of best practice" indicators.

+

'''Communities.'''

'''Communities.'''

Line 82:

Line 133:

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 [http://www.eclipse.org/org/press-release/pressguidelines.htm press guidelines]) does not endear themselves to the Eclipse community. The [[Development Resources]] page provides pointers to a great deal of information about the [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process] and more. At a minimum all prospective committers on the new project should be familiar with the [[Development Resources/New Commmitter Handbook | New Committer Handbook]].

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 [http://www.eclipse.org/org/press-release/pressguidelines.htm press guidelines]) does not endear themselves to the Eclipse community. The [[Development Resources]] page provides pointers to a great deal of information about the [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process] and more. At a minimum all prospective committers on the new project should be familiar with the [[Development Resources/New Commmitter Handbook | New Committer Handbook]].

−

−

===Preparing the Documentation===

−

The documentation for a Review has traditionally been a slide deck however there is no reason to use slides: a short report/document would work equally well if not better (reports are information dense relative to slides, and that's a good attribute). In fact, the proposal document itself can provide a solid foundation for the review documentation.

−

−

In any case, the review document must be/have:

−

−

* '''Neutral File Format.''' The document must be published in an operating-system neutral file format. PPT and DOC files are not considered neutral. PDF or HTML is currently the best choice. The EMO can convert Open Office and Microsoft Office to PDF if you are unable to do so.

−

* '''Archival Quality.''' The document must be comprehensible and complete on its own without requiring explanation by a human presenter. Archival quality is required because it will be available on the eclipse.org website in perpetuity; future Eclipse users, adopters, and even new project committers will consult it long after the review conference call has been completed.

−

* '''Correct Copyright and License.''' The document is being written (and thus copyrighted) by you, not by the Eclipse Foundation, and thus the copyright statement needs to be by you (or your employer). Similarly, the content should be licensed under the EPL.

−

−

The document must cover the issues discussed in the above sections. In addition, it must include:

−

* Brief, executive summary of the project proposal

−

* Comments about the community response to the proposal both positive and, if any, negative

−

* Description of the [[Development Resources/Initial Contribution | Initial Contribution]]. Is this an existing project that is moving some or all of its code to Eclipse?

−

*# Describe extent of move (e.g. some, all, module);

−

*# Name where the code is hosted;

−

*# List existing domain names associated with this code;

−

*# List any trademarks that may apply to the project name;

−

*# List the license(s) was it previously hosted under;

−

*# Provide a list of all past and present contributors and committers (or copyright holders).

−

* Initial implementation focus - the next step after the Creation Review will be full-speed-ahead implementation, so the project team had better have an initial implementation direction

−

* Confirmation that the project members and new candidates have read and understand the [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process] and their responsibilities towards the community and especially in regards to IP issues.

−

* Future directions - it's always a good idea to have some idea of where the project is planning to go.

−

−

===The Review Process===

−

A review culminates in a review period of at least five generally accepted business days and ultimately end with a succeed/fail determination from the EMO. This review period grants the community one last opportunity to get involved with the project prior to its creation. ''In the past, all reviews were ended with a phone call. We no longer hold calls for reviews.''

−

−

Once the review content has been created, the operational side of a Creation Review is:

−

# Schedule the review by sending email to emo@eclipse.org. (Depending on when you read this, you may have already completed this step.)

−

#* Reviews are scheduled at most twice a month, usually on Wednesdays, usually in the morning (USA)/afternoon (Europe)/night (Asia).

−

#* Reviews are grouped up to four at a time.

−

# At least one week in advance of the start of the review period, you (the proposal lead) sends the review document to emo@eclipse.org for posting.

−

#* The EMO posts the document via the website (through the wonders of database-driven web pages, the document is automatically linked from the proposal and from the review notice).

−

# The EMO announces the review:

−

#* via the eclipse.org/projects web page (as soon as the review is scheduled);

−

#* via the reviews and announcements RSS feed (as soon as the review is scheduled and again when the review document is posted); and

−

#* via email to the committers and membership-at-large mailing lists (at least one week in advance of the review conference call).

−

# At the end of the review period, the EMO will make the succeed/fail determination based on community feedback.

−

−

===After a Successful Review===

−

After the successful review, and the approval of the Creation Review by the EMO:

−

# the EMO will ask you to fill out the [http://www.eclipse.org/projects/project_provisioning_request.php New Project Provisioning Form]

−

# once your website CVS directory is created, you will provide content for the webpages including:

−

## The [http://www.eclipse.org/projects/dev_process/incubation-conforming.php incubation graphic] so that your new project is allowed to participate in the [http://www.eclipse.org/projects/dev_process/parallel-ip-process.php Parallel IP process].

# send email to emo@eclipse.org asking for your project to be marked as "incubation (conforming)" in the Foundation's project database. The EMO will check your website for conformance as per the [http://www.eclipse.org/org/documents/Eclipse_Project_Requirements.html Board's requirements] - this is a required step for participation in the [http://www.eclipse.org/projects/dev_process/parallel-ip-process.php Parallel IP process].

−

# you submit a Contribution Questionnaire for your initial code contribution using the [http://portal.eclipse.org portal]. Note in the comments that you are requesting a [http://www.eclipse.org/projects/dev_process/parallel-ip-process.php Parallel IP process] approval to check the initial code into the source code repository before the entire IP review is completed.

−

# after receiving check-in approval from Eclipse Legal via IPZilla, you can check in the initial code contribution and your project is alive and well.

''This page is moderated by the EMO''

''This page is moderated by the EMO''

[[Category:Development_Resources]]

[[Category:Development_Resources]]

[[Category:How to Contribute]]

[[Category:How to Contribute]]

Revision as of 10:24, 6 April 2011

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.

More information

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

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.