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

Difference between revisions of "Development Resources/HOWTO/Pre-Proposal Phase"

(Project or Contribution?)
 
(51 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<div style="float: right; border: 1px dashed black;
+
''See "[http://www.eclipse.org/projects/dev_process/development_process.php#6_2_1_Pre-Proposal 6.2.1 Pre-Proposal Phase]" in the Eclipse Development Process''
background-color: #FFFFDD;"><table><tr><td width="150px">See "[http://www.eclipse.org/projects/dev_process/development_process.php#6_2_1_Pre-Proposal 6.2.1 Pre-Proposal Phase]" in the Eclipse Development Process</td>
+
 
</tr></table></div><blockquote><em>An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.
+
An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.
 
* The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.  
 
* The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.  
</em></blockquote>
 
  
===(1) Project or Component or Contribution?===
+
=Project or Contribution?=
One of the major purposes of the Eclipse Development Process is to ensure that the projects are open and transparent to the membership and ecosystem. Another major purpose is for the Councils to minimize duplication across the projects, i.e., we strive to have one official Eclipse framework for each technical area. Thus, as the first step in a new proposal, we ask four questions:
+
 
 +
One of the major purposes of the Eclipse Development Process [https://www.eclipse.org/projects/dev_process/development_process.php (EDP)] is to ensure that the projects are open and transparent to the membership and ecosystem. Another major purpose is for the Councils to minimize duplication across the projects, i.e., we strive to have one official Eclipse framework for each technical area. Thus, as the first step in a new proposal, we ask four questions:
 
# Is there already a [http://www.eclipse.org/projects/ Project] at Eclipse working the same technical area (i.e., a Project whose scope includes this area)?  
 
# Is there already a [http://www.eclipse.org/projects/ Project] at Eclipse working the same technical area (i.e., a Project whose scope includes this area)?  
#If so, would this proposal be more suited as a contribution to that project or a new sub-project or component of that existing project?
+
# If so, would this proposal be more suited as a contribution to that project or a new sub-project of that existing project?
 
#* Note that an overlap between projects is not prohibited but is strongly discouraged. The Eclipse membership has indicated that they are ok with multiple incubating projects in a given technical area, but would prefer a single project once the frameworks mature.
 
#* Note that an overlap between projects is not prohibited but is strongly discouraged. The Eclipse membership has indicated that they are ok with multiple incubating projects in a given technical area, but would prefer a single project once the frameworks mature.
 
#* In all "competing project" situations to date, the projects eventually realized that it would be in their best interest to work together and thus merged their projects before graduating.
 
#* In all "competing project" situations to date, the projects eventually realized that it would be in their best interest to work together and thus merged their projects before graduating.
 
# Is this new effort going to be managed as part of an existing project or is it going to be a separate entity?
 
# Is this new effort going to be managed as part of an existing project or is it going to be a separate entity?
#:Here we examine the interaction of the project leads and the synchronization (or lack thereof) of release schedules. For example, if the new effort is always going to release at the same time as another project and the leads of the new effort and the other project are regularly coordinating development plans, then perhaps this new effort is a component of the other project. Otherwise, if the new effort is more independent (in management and in release schedule), then perhaps it should be a separate project.
+
#* Here we examine the interaction of the project leads and the synchronization (or lack thereof) of release schedules. For example, if the new effort is always going to release at the same time as another project and the leads of the new effort and the other project are regularly coordinating development plans, then perhaps this new effort is a component of the other project. Otherwise, if the new effort is more independent (in management and in release schedule), then perhaps it should be a separate project.
# Is this new effort within the scope of the enclosing Project or Top-Level Project? For example, a new "syntax highlighting editor for Pascal" would not be in scope of the "Web Standard Tools" project.
+
# Is this new effort within the scope of the (optionally) enclosing parent Project and charter of the enclosing Top-Level Project? For example, a new "syntax highlighting editor for Pascal" would not be in scope of the "Web Standard Tools" project.
  
<span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span> The new effort must be in scope with respect to it's enclosing Project(s).
+
The new effort must be in scope with respect to its enclosing Project(s).
  
===(2) The Purposes===
+
=Project Name=
The other major question that we ask of all new efforts (components, contributions, or projects) is whether the effort is consistent with the [http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf?page=4 Purposes]. One of the common edge cases in new projects is the issue of Tools versus Run-times. The [http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf?page=4 Eclipse Bylaws, section 1.1], state that "the Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools".
+
Naming and branding are challenging issues. In order to provide a consistent brand for Eclipse, projects must follow [http://www.eclipse.org/projects/dev_process/project-naming-policy.php the project naming guidelines] which effectively say:
* The distinction between tools and run-times is not as black-and-white as one    might like - for example, is the code generated by a tool consider a    run-time? What about a library that must be linked to use the code generated    by a tool? What about a framework that must be installed on a J2EE server in    order to use a particular tool with that server? etc. - and yet the Eclipse    organization is conscious of the issue.
+
* Currently, the    policy is that "plumbing", or primitive, run-times are not    acceptable whereas frameworks that work on top of existing run-times (e.g.,    works on top of J2EE) are acceptable.
+
* Frameworks that are in support of development tools are acceptable;        frameworks that are application servers, database servers, operating        systems, etc. are not acceptable. Projects that are more appropriate at        other more server-centric open source organizations (such as Apache or        ObjectWeb) are not.
+
* The easiest proposals, of course, are those with no ambiguity: for    example, an Eclipse tool that generates configuration files for an Apache    run-time to render.
+
 
+
<span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span>The new effort must be consistent with the Purposes.
+
 
+
===(3) Project Name===
+
<span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times;">R</span>Naming and branding are challenging issues. In order to provide a consistent brand for Eclipse, projects must follow [http://www.eclipse.org/projects/dev_process/project-naming-policy.php the project naming guidelines] which effectively say:
+
 
# The best names are descriptive but at the same time memorable.  
 
# The best names are descriptive but at the same time memorable.  
 
# The project name does not include "Eclipse" or "Project".
 
# The project name does not include "Eclipse" or "Project".
 
# The project name is not the name of an existing product and will not be used in the name of a product.
 
# The project name is not the name of an existing product and will not be used in the name of a product.
  
===(4) Clear, Concise, and Understandable Proposal===
+
=Clear, Concise and Understandable Proposal=
The next step in establishing a new project at Eclipse is to contact the Eclipse Management Organization (EMO; email emo@eclipse.org) and work towards a clear, concise, and understandable Proposal.
+
Create the proposal [https://wiki.eclipse.org/Development_Resources/HOWTO/Starting_A_New_Project#Proposal_Creation_Links here].
  
The Proposal includes:
+
We provide an online template that you fill in with the proposal details.
* <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span>'''Clear and concise description.'''<br>    It is important that the description of the new project be understandable by the diverse    Eclipse community and not just by specialists in the subject matter. It is    also important that the description concentrate on the technical aspects of    the project and avoid marketing buzzwords. Terms that are not in common use    amongst the Eclipse membership must be defined, and references to standards    should be linked to the corresponding URL.
+
** A thought experiment for clarity and conciseness is "if I        randomly choose five Committers from the entire Eclipse Committer pool,        will those five people understand what this project is about?" The        five may not agree with the proposal or even believe that it is        feasible, but they need to understand what it is proposing.
+
* <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span>'''The Fit fit with Eclipse.''' How does this project fit with the other Eclipse projects?  Does it build on top of other projects?  What are the dependencies?  Does it overlap with existing projects?  Why are the needs this project meets are not met by existing Eclipse projects?
+
* <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span>'''Resources committed.'''    Eclipse is a place for active projects, not a place for dumping unwanted    code. Eclipse projects involve substantial on-going development activity.    Thus proposals should be convincing about the resources that are being    brought to the project in addition to any initial code contribution.    The proposal should include a list of interested and committed persons and companies and their affiliations, but should not include corporate or group logos.
+
* <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span>'''Vendor neutral.''' Eclipse is place for vendor neutral projects which includes being    operating system agnostic. If, as is usually the case, the proposal is    coming from a single company, the proposal should explain how the resulting    project will be vendor neutral. Similarly, the proposal should explain away    any operating system dependencies.
+
  
====(4.1) Previous Proposals to Emulate====
+
==Tips==
Past proposals are available from the [http://www.eclipse.org/proposals/ archived proposals page]. Four good examples to emulate are: [http://www.eclipse.org/proposals/eclipse-mylar/ Mylar], [http://www.eclipse.org/proposals/dltk/ DLTK], [http://www.eclipse.org/proposals/modeling/ Modeling], and [http://www.eclipse.org/proposals/eclipse-dsdp/ DSDP].
+
* Use plain non-technical English.
 +
* Describe all acronyms.
 +
* Provide urls where appropriate to direct reader for further information.
  
====(4.2) Proposal File Format and Submission====
+
==Notes==
The proposal itself is a static HTML page (with a small fragment of PHP) using the standard Eclipse Proposal CSS style sheet ([http://www.eclipse.org/proposals/templates/proposal-template.zip please use the template we provide]). We have found that there are a number of problems with HTML generated by Microsoft Word and thus ask that proposers use some other tool to create the page. Sorry, but the EMO does not have the time or resources to convert other file formats to the correct static HTML.
+
* Eclipse projects involve substantial on-going development activity. Thus proposals should be convincing about the resources that are being brought to the project in addition to any initial code contribution.  
 +
The proposal should include a list of interested and committed persons and companies and their affiliations, but should not include corporate or group logos.
 +
* Eclipse is place for vendor neutral projects which includes being operating system agnostic. If, as is usually the case, the proposal is coming from a single company, the proposal should explain how the resulting
 +
project will be vendor neutral. Similarly, the proposal should explain away any operating system dependencies.
  
Proposals must be zipped (to avoid problems with the Foundation's email anti-virus scanner) and emailed to emo@eclipse.org.
+
==Proposals to Review for Guidance==
 +
* [https://projects.eclipse.org/proposals/eclipse-advanced-scripting-environment-ease EASE]
 +
* [https://www.eclipse.org/proposals/technology.smarthome/ Eclipse SmartHome]
  
===(5) Mentors===
+
==Sections To Fill In==
<div style="float: right; border: 1px dashed black;
+
Please fill in the following sections. Headings follow the listing in the online proposal system.
background-color: #FFFFDD;"><table><tr><td width="150px">Mentors are members of the Eclipse [[Architecture Council]]. For help, please see [[Architecture Council/Mentorship | Mentorship]].</td>
+
</tr></table></div><span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#00CC99; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">G</span>New projects (i.e., incubating projects) at Eclipse require the supervision of at least [http://www.eclipse.org/projects/dev_process/development_process.php#6_1_Mentors two Mentors]. The proposal can be posted prior to selecting mentors, but it cannot have a [http://www.eclipse.org/projects/dev_process/development_process.php#6_3_1_Creation_Review Creation Review] without mentors. Thus it behooves the proposers to begin finding mentors as early as possible.  
+
  
===(6) Posting and Declaration===
+
===Basic section===
After the EMO receives and agrees the proposal is ready to post, the following steps are taken:
+
* Provide a project name.
# The EMO modifies the proposal text to include the correct internal Foundation database record identifier and the correct discussion newsgroup.
+
* Click "I know what I'm getting into" checkbox.
# The proposal is placed at a hidden url on the eclipse.org website.
+
# The EMO drafts a <em>declaration</em>. The declaration is a short email message sent by the EMO to the Eclipse membership-at-large stating that X is proposing project Y at Eclipse. The declaration has the following form:
+
  
We are notifying the Eclipse Membership-at-Large of the intent of Person P (Company Q) to propose the XYZ Project as a EFG incubator.
+
----
+
A brief description of the project is below. A draft project proposal has been posted on
+
  http://www.eclipse.org/proposals/xyz/
+
------------------------------------------------------------------------
+
+
*Project Declaration for the "XYZ Project"
+
+
The goal of this project is to add comprehensive support blah blah blah...
+
* <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">R</span>The EMO requires positive approval from at least three people before publicly posting the proposal and sending the declaration. All three people (or their appointed delegates) must reply that they are ok (+1) with the hidden-url proposal and the declaration before the proposal will be made public.
+
*# The proposer, speaking for all the people and companies involved
+
*# The Eclipse Foundation's Director of Committer Community
+
*# The Eclipse Foundation's Executive Director
+
* The EMO updates the internal Foundation database, thus publishing the proposal on the website. At the same time, the EMO creates the corresponding discussion newsgroup.
+
* The EMO sends you an email reminding you to read and implement the [http://www.eclipse.org/projects/dev_process/proposal-phase.php Guidelines for the Proposal Phase]
+
  
===(7) Press and Publicity===
+
===Discussion section===
History has shown that companies who are starting or joining their first open-source project, or perhaps merely their first Eclipse open-source project, want to carefully stage the press announcements. Because the Eclipse membership-at-large is large and includes press, the EMO works carefully with the proposers to ensure that news is not prematurely leaked.
+
  
A press release at this point is optional. Some companies and individuals like to have a press release when the project is proposed, while others prefer to wait until the project is approved/created, and then others do not issue one at all - it is completely up to the proposal team. Any release must include Q&amp;A's, messages and preparation by the stakeholder spokespeople. The discipline of creating a press release ensures that all stakeholders have agreed on messages, positioning and have identified spokepersons.
+
====Background====
 +
* Describe where the project came from. What is the historical journey of the project; who/what company wrote the project. Did it go through any significant alterations/rewrites/language changes?
  
<span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times;">R</span>If you do decide to issue a press release, the Eclipse Foundation Marketing Director must help you coordinate the announcement. (Email the EMO for further information.)
+
====Scope====
 +
Provide an introductory paragraph describing what the project aims to be followed by several bullet points. The scope should allow for some flexibility, but still provide well-defined boundaries for the project.
 +
* What is in-scope?
 +
* What is out-of-scope?
  
===(8) Legal Paperwork to Start Now===
+
====Description====
<span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#00CC99; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times; ">G</span>It is important for the proposers to begin moving the various [http://www.eclipse.org/projects/dev_process/new-committer.php#Paperwork Committer Agreements] through their company's legal department as the paperwork always seems to take longer than one would like. The project cannot be provisioned (source code repository, bug repository, website, etc.) without completed legal paperwork.
+
The introductory paragraph should clearly explain what the is and does. Think of this as an expanded elevator pitch.
 +
* Use plain English.
 +
* Include graphics/tables if they help with clarity.
 +
* Focus on the technical aspects of the project.
 +
* Is there any collaboration/usage by/with other Eclipse projects?
 +
* Does it build on top of other projects?  What are the dependencies?  Does it overlap with existing projects?  Why are the needs this project meets are not met by existing Eclipse projects?
  
Similarly, the proposers will want to start gathering the required documentation for the initial code contribution questionnaire. The important information includes:
+
====Why Here====
* Documentation of code ownership and the right of the proposer to contribute the code under the EPL
+
* Why does this project want to host at Eclipse?
 +
* What do you expect to gain by having your project at Eclipse?
 +
* What value does the project provide to the Eclipse community and ecosystem?
 +
 
 +
====Licenses====
 +
* Check the licenses that apply to the project.
 +
* Under what license(s) will the project's artifacts be distributed? If you're not sure, contact the Eclipse Management Organization (EMO) for assistance.
 +
* If the initial contribution is currently distributed under a different license, please make note of the current licensing terms in the "Legal Issues" section.
 +
 
 +
====Legal Issues====
 +
* Please describe any legal issues around the project and/or code.
 +
* List the current licenses of the main code.
 +
* List the 3rd party dependencies and associated licenses.
 +
 
 +
====Initial Contribution====
 +
* Where is the code coming from? Current Eclipse project/GitHub repository or other.
 +
 
 +
====Future Work====
 +
* How is the project going to grow its community (users/adopters/committers)?
 +
** Run events, attend conferences, write great documentation etc
 +
* What are the major items to be developed?
 +
** Couple of bullet points of major items.
 +
 
 +
----
 +
 
 +
===Source Code Section===
 +
 
 +
====Repository Source Type====
 +
* Select the type of source code repository the project will use as its primary host.
 +
 
 +
====Source Repositories====
 +
* If you have existing publicly-accessible (ie. GitHub) source repositories for this project, list the URLs for them here.
 +
 
 +
----
 +
 
 +
===People===
 +
* A project needs a project lead and at least one committer.
 +
** These can change down the road.
 +
 
 +
====Initial Committers====
 +
* Need to already have committer status at Eclipse.
 +
** If not, then they will not show up when searched for.
 +
 
 +
====Committers====
 +
* These are folks who will be working on the project but are not currently Eclipse committers.
 +
** List all involved here; if not once project is created it will require an election to add additional committers (not difficult).
 +
 
 +
====Mentors====
 +
We will request members from the Architecture Council to fill these.
 +
 
 +
* Mentors are members of the Eclipse [[Architecture Council]]. For help, please see [[Architecture Council/Mentorship | Mentorship]].
 +
* New projects (i.e., incubating projects) require the supervision of at least two [http://www.eclipse.org/projects/dev_process/development_process.php#6_1_Mentors Mentors].
 +
* Proposal can be opened for community review without mentors.
 +
* Mentors must be present before we can schedule the [http://www.eclipse.org/projects/dev_process/development_process.php#6_3_1_Creation_Review Creation Review] without mentors.
 +
** We seek mentors on behalf of projects.
 +
 
 +
====Interested Parties====
 +
* Who is interested in this project? This could be individuals or companies.
 +
 
 +
=Refining Proposal=
 +
The EMO will review the proposal. Please expect a series of back and forth emails to clarify and improve the proposal. This
 +
can take time, so please be patient.
 +
 
 +
==Posting and Declaration==
 +
Once the proposal is ready, the following steps occur:
 +
 
 +
* The EMO modifies the proposal text to include the correct internal Foundation database record identifier.
 +
* The proposal can only accessed by a limited number of people with permission to view and edit.
 +
* The EMO will send a short email message to the Eclipse membership-at-large stating that X is proposing project Y at Eclipse.
 +
** The EMO requires positive approval from at least three people before publicly posting the proposal and sending the declaration.
 +
All three people (or their appointed delegates) must reply that they are ok (+1) with the hidden-url proposal and the declaration before the proposal will be made public:
 +
** The proposer, speaking for all the people and companies involved
 +
** The Eclipse Foundation's Director of Committer Community
 +
** The Eclipse Foundation's Executive Director
 +
 
 +
Once approval is given:
 +
* The proposal will be made public for community review.
 +
* We will create a new proposal topic at [https://www.eclipse.org/forums/index.php/f/202/ eclipse forums].
 +
* Post on various social media.
 +
 
 +
=Press and Publicity=
 +
 
 +
* Please let us know how you would like this handled.
 +
** We typically post to [https://www.eclipse.org/forums/index.php/f/202/ eclipse forums] and post on social media.
 +
 
 +
* If you would like to issue a press release, the Eclipse Foundation Marketing Director can help coordinate. Please [mailto:emo@eclipse.org email the EMO].
 +
 
 +
=Legal Paperwork=
 +
 
 +
It's important to review the Legal components of being an Eclipse project.
 +
* Please review [https://www.eclipse.org/legal/guidetolegaldoc.php A Guide to the Legal Documentation for Eclipse-Based Content].
 +
* Please familarize yourself with [https://www.eclipse.org/legal/ Eclipse Legal].
 +
 
 +
It is important to start the various [http://www.eclipse.org/projects/dev_process/new-committer.php#Paperwork Committer Agreements] with your company's legal department.
 +
 
 +
* The project cannot be provisioned (source code repository, bug repository, website, etc.) without completed legal paperwork.
 +
 
 +
Start gathering the required documentation for the initial code Contribution Questionnaire (CQ). The important information includes:
 +
* Documentation of code ownership and the right of the proposer to contribute the code under the EPL.
 
* Licenses, source code, and provenance of all third-party (non-EPL) code included or referenced in or by the EPL'ed initial code.
 
* Licenses, source code, and provenance of all third-party (non-EPL) code included or referenced in or by the EPL'ed initial code.
 
* And by ''all'', we mean ALL the code: many third-party libraries include other third party libraries and those include others and so on and so on.
 
* And by ''all'', we mean ALL the code: many third-party libraries include other third party libraries and those include others and so on and so on.
  
''This page is moderated by Anne Jacko and Wayne Beaton (Eclipse Foundation)''
+
=Next Steps=
 +
 
 +
* Proposal are posted for a minimum of two weeks for the community to review.
 +
** Please monitor the communication channel for the proposal (community can comment at bottom of the proposal and at [https://www.eclipse.org/forums/index.php/f/202/ Eclipse Forums/Proposals]
 +
** You can update the proposal at any time during the community review.
 +
 
 +
The EMO will schedule a [https://wiki.eclipse.org/Development_Resources/HOWTO/Review_Information_for_Project_Leads#Creation_Reviews creation review] once the project has met the following conditions:
 +
* Minimum of two weeks for community review have passed.
 +
* Successful trademark review completed.
 +
* Two mentors for project.
 +
 
 
[[Category:Development_Resources]]
 
[[Category:Development_Resources]]
 
[[Category:How to Contribute]]
 
[[Category:How to Contribute]]

Latest revision as of 15:32, 8 July 2014

See "6.2.1 Pre-Proposal Phase" in the Eclipse Development Process

An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.

  • The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.

Project or Contribution?

One of the major purposes of the Eclipse Development Process (EDP) is to ensure that the projects are open and transparent to the membership and ecosystem. Another major purpose is for the Councils to minimize duplication across the projects, i.e., we strive to have one official Eclipse framework for each technical area. Thus, as the first step in a new proposal, we ask four questions:

  1. Is there already a Project at Eclipse working the same technical area (i.e., a Project whose scope includes this area)?
  2. If so, would this proposal be more suited as a contribution to that project or a new sub-project of that existing project?
    • Note that an overlap between projects is not prohibited but is strongly discouraged. The Eclipse membership has indicated that they are ok with multiple incubating projects in a given technical area, but would prefer a single project once the frameworks mature.
    • In all "competing project" situations to date, the projects eventually realized that it would be in their best interest to work together and thus merged their projects before graduating.
  3. Is this new effort going to be managed as part of an existing project or is it going to be a separate entity?
    • Here we examine the interaction of the project leads and the synchronization (or lack thereof) of release schedules. For example, if the new effort is always going to release at the same time as another project and the leads of the new effort and the other project are regularly coordinating development plans, then perhaps this new effort is a component of the other project. Otherwise, if the new effort is more independent (in management and in release schedule), then perhaps it should be a separate project.
  4. Is this new effort within the scope of the (optionally) enclosing parent Project and charter of the enclosing Top-Level Project? For example, a new "syntax highlighting editor for Pascal" would not be in scope of the "Web Standard Tools" project.

The new effort must be in scope with respect to its enclosing Project(s).

Project Name

Naming and branding are challenging issues. In order to provide a consistent brand for Eclipse, projects must follow the project naming guidelines which effectively say:

  1. The best names are descriptive but at the same time memorable.
  2. The project name does not include "Eclipse" or "Project".
  3. The project name is not the name of an existing product and will not be used in the name of a product.

Clear, Concise and Understandable Proposal

Create the proposal here.

We provide an online template that you fill in with the proposal details.

Tips

  • Use plain non-technical English.
  • Describe all acronyms.
  • Provide urls where appropriate to direct reader for further information.

Notes

  • Eclipse projects involve substantial on-going development activity. Thus proposals should be convincing about the resources that are being brought to the project in addition to any initial code contribution.

The proposal should include a list of interested and committed persons and companies and their affiliations, but should not include corporate or group logos.

  • Eclipse is place for vendor neutral projects which includes being operating system agnostic. If, as is usually the case, the proposal is coming from a single company, the proposal should explain how the resulting

project will be vendor neutral. Similarly, the proposal should explain away any operating system dependencies.

Proposals to Review for Guidance

Sections To Fill In

Please fill in the following sections. Headings follow the listing in the online proposal system.

Basic section

  • Provide a project name.
  • Click "I know what I'm getting into" checkbox.

Discussion section

Background

  • Describe where the project came from. What is the historical journey of the project; who/what company wrote the project. Did it go through any significant alterations/rewrites/language changes?

Scope

Provide an introductory paragraph describing what the project aims to be followed by several bullet points. The scope should allow for some flexibility, but still provide well-defined boundaries for the project.

  • What is in-scope?
  • What is out-of-scope?

Description

The introductory paragraph should clearly explain what the is and does. Think of this as an expanded elevator pitch.

  • Use plain English.
  • Include graphics/tables if they help with clarity.
  • Focus on the technical aspects of the project.
  • Is there any collaboration/usage by/with other Eclipse projects?
  • Does it build on top of other projects? What are the dependencies? Does it overlap with existing projects? Why are the needs this project meets are not met by existing Eclipse projects?

Why Here

  • Why does this project want to host at Eclipse?
  • What do you expect to gain by having your project at Eclipse?
  • What value does the project provide to the Eclipse community and ecosystem?

Licenses

  • Check the licenses that apply to the project.
  • Under what license(s) will the project's artifacts be distributed? If you're not sure, contact the Eclipse Management Organization (EMO) for assistance.
  • If the initial contribution is currently distributed under a different license, please make note of the current licensing terms in the "Legal Issues" section.

Legal Issues

  • Please describe any legal issues around the project and/or code.
  • List the current licenses of the main code.
  • List the 3rd party dependencies and associated licenses.

Initial Contribution

  • Where is the code coming from? Current Eclipse project/GitHub repository or other.

Future Work

  • How is the project going to grow its community (users/adopters/committers)?
    • Run events, attend conferences, write great documentation etc
  • What are the major items to be developed?
    • Couple of bullet points of major items.

Source Code Section

Repository Source Type

  • Select the type of source code repository the project will use as its primary host.

Source Repositories

  • If you have existing publicly-accessible (ie. GitHub) source repositories for this project, list the URLs for them here.

People

  • A project needs a project lead and at least one committer.
    • These can change down the road.

Initial Committers

  • Need to already have committer status at Eclipse.
    • If not, then they will not show up when searched for.

Committers

  • These are folks who will be working on the project but are not currently Eclipse committers.
    • List all involved here; if not once project is created it will require an election to add additional committers (not difficult).

Mentors

We will request members from the Architecture Council to fill these.

  • Mentors are members of the Eclipse Architecture Council. For help, please see Mentorship.
  • New projects (i.e., incubating projects) require the supervision of at least two Mentors.
  • Proposal can be opened for community review without mentors.
  • Mentors must be present before we can schedule the Creation Review without mentors.
    • We seek mentors on behalf of projects.

Interested Parties

  • Who is interested in this project? This could be individuals or companies.

Refining Proposal

The EMO will review the proposal. Please expect a series of back and forth emails to clarify and improve the proposal. This can take time, so please be patient.

Posting and Declaration

Once the proposal is ready, the following steps occur:

  • The EMO modifies the proposal text to include the correct internal Foundation database record identifier.
  • The proposal can only accessed by a limited number of people with permission to view and edit.
  • The EMO will send a short email message to the Eclipse membership-at-large stating that X is proposing project Y at Eclipse.
    • The EMO requires positive approval from at least three people before publicly posting the proposal and sending the declaration.

All three people (or their appointed delegates) must reply that they are ok (+1) with the hidden-url proposal and the declaration before the proposal will be made public:

    • The proposer, speaking for all the people and companies involved
    • The Eclipse Foundation's Director of Committer Community
    • The Eclipse Foundation's Executive Director

Once approval is given:

  • The proposal will be made public for community review.
  • We will create a new proposal topic at eclipse forums.
  • Post on various social media.

Press and Publicity

  • Please let us know how you would like this handled.
  • If you would like to issue a press release, the Eclipse Foundation Marketing Director can help coordinate. Please email the EMO.

Legal Paperwork

It's important to review the Legal components of being an Eclipse project.

It is important to start the various Committer Agreements with your company's legal department.

  • The project cannot be provisioned (source code repository, bug repository, website, etc.) without completed legal paperwork.

Start gathering the required documentation for the initial code Contribution Questionnaire (CQ). The important information includes:

  • Documentation of code ownership and the right of the proposer to contribute the code under the EPL.
  • Licenses, source code, and provenance of all third-party (non-EPL) code included or referenced in or by the EPL'ed initial code.
  • And by all, we mean ALL the code: many third-party libraries include other third party libraries and those include others and so on and so on.

Next Steps

  • Proposal are posted for a minimum of two weeks for the community to review.
    • Please monitor the communication channel for the proposal (community can comment at bottom of the proposal and at Eclipse Forums/Proposals
    • You can update the proposal at any time during the community review.

The EMO will schedule a creation review once the project has met the following conditions:

  • Minimum of two weeks for community review have passed.
  • Successful trademark review completed.
  • Two mentors for project.

Back to the top