| <?php |
| include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php"); |
| |
| $pageTitle = "Pre-Proposal Phase"; |
| $pageKeywords = "development process"; |
| $pageAuthor = "Bjorn Freeman-Benson Nov 20/05"; |
| |
| include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-after-definitions.php"); |
| ?> |
| <div id="maincontent"> |
| <div id="midcolumn"> |
| |
| <h1>Pre-Proposal Phase</h1> |
| <p><i>version 026 - November 10, 2005</i></p> |
| <p><a href="index.php">[This is one page of the larger document.]</a></p> |
| <h2>Pre-Proposal Phase</h2> |
| <p>The Pre-Proposal Phase starts when an individual or company declares their interest in, |
| and rationale for, establishing a project; and ends with a proposal being |
| made available to the membership by being posted on the eclipse.org website.</p> |
| <p>The first step is to decide whether the new idea is a top-level project, a |
| sub-project, or a component. Some rules of thumb on this decision are:</p> |
| <table border="1" width="100%"> |
| <tr> |
| <td width="25%"> </td> |
| <td width="25%" align="center"><b>Component</b></td> |
| <td width="25%" align="center"><b>Sub-Project</b></td> |
| <td width="25%" align="center"><b>Top-Level Project</b></td> |
| </tr> |
| <tr> |
| <td width="25%"><b>Project Management</b></td> |
| <td width="25%" valign="top">managed as part of a larger effort</td> |
| <td width="25%" valign="top">managed separately<sup>1</sup></td> |
| <td width="25%" valign="top">managed separately</td> |
| </tr> |
| <tr> |
| <td width="25%"><b>Shipping and Releases</b></td> |
| <td width="25%" valign="top">MUST ship at the same time as the other pieces</td> |
| <td width="25%" valign="top">USUALLY ships at the same time as the other |
| pieces</td> |
| <td width="25%" valign="top">shipping deadlines are unrelated to other |
| pieces</td> |
| </tr> |
| <tr> |
| <td width="25%"><b>Code Size</b></td> |
| <td width="25%" valign="top">Small</td> |
| <td width="25%" valign="top">Medium to large</td> |
| <td width="25%" valign="top">Large and larger</td> |
| </tr> |
| </table> |
| <p>The next step in establishing a new project at Eclipse is to contact the Eclipse Management Organization |
| (<a href="mailto:emo@eclipse.org">EMO</a>) and begin working towards a Project Proposal and a Project Declaration. |
| The goal of this phase is to ensure that the proposal is clear, understandable, |
| and is a good fit with the Purposes.</p> |
| <p>A declaration is a short email which is distributed by the EMO to the Eclipse membership-at-large stating that someone wants to start a project at Eclipse. Before a declaration is sent, the EMO will want to talk about the technology areas you are planning on working on, which Project Management Committee (PMC) the new project would best fit in, who you think will be working on the project, etc. |
| The EMO will also want to see a nearly complete draft of the proposal as our |
| experience is that good proposals more than a week to write.</p> |
| <p>The declaration has the following form:</p> |
| <blockquote>As per the Eclipse Development Process, we are notifying the Eclipse Membership-at-Large of the intent of |
| Company Q to propose the XYZ Project as part of the Technology PMC.<br> |
| <br> |
| A brief description of the project is below. A draft project proposal has been posted on |
| http://www.eclipse.org/proposals/.../index.html and will become public in a |
| few days.<br> |
| <br> |
| ------------------------------------------------------------------------<br> |
| <br> |
| *Project Declaration for the "XYZ Project"*<br> |
| <br> |
| The goal of this project is to add comprehensive support blah blah blah... </blockquote> |
| <p>History has shown that companies who are starting 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.</p> |
| <p>The declaration is emailed to the membership more or less a week in advance of the |
| proposal being posted. This provides a benefit of membership and allows members |
| to raise concerns about projects before they become public.</p> |
| <p>The goals of the proposal document itself include:</p> |
| <ul> |
| <li><b>Clear and concise description.</b> <br> |
| It is important that the description 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. |
| <ul> |
| <li>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.<sup>2</sup></li> |
| </ul> |
| </li> |
| <li><b>Resources committed.</b><br> |
| 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.</li> |
| <li><b>Tools versus Run-time.<br> |
| </b>Currently the Eclipse Bylaws, section 1.1, state that "the Eclipse |
| technology is a vendor-neutral, open development platform supplying |
| frameworks and exemplary, extensible tools". |
| <ul> |
| <li>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. </li> |
| <li> 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.</li> |
| <li>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.</li> |
| <li> 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.</li> |
| </ul> |
| </li> |
| <li> |
| <p align="left"><b>Consistent With The Purposes.<br> |
| </b>Eclipse projects, and hence all proposals, must be consistent with the <a href="/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf">Purposes</a>. |
| </li> |
| <li><b>Project Name.<br> |
| </b>Naming and branding are challenging issues. In order to provide a consistent |
| brand for Eclipse, projects must follow <a href="project-naming-policy.php">the project naming |
| guidelines</a>, summarized here. The best names are descriptive but |
| at the same time memorable. The policy for project names is: |
| <ul> |
| <li><b>Descriptive Name.</b> A descriptive name is one that is useful |
| when placed into a box on <a href="/org/councils/AC/arch2.jpg">the |
| Eclipse architecture diagram</a>. For example "<a href="/gmf">Graphical |
| Modeling Framework</a>", "Trust Framework" or |
| "Component Assembly Tools". We want to avoid having to |
| create a <a href="http://www.apache.org/foundation/projects.html" target="_top"> |
| separate web page to explain which names correspond to which |
| technology</a>. |
| <ul> |
| <li>Descriptive names do not include "Eclipse" or |
| "Project". The name should work with or without the |
| prefix and suffix. For example, "The Eclipse Graphical |
| Modeling Framework Project" as well as "Graphical |
| Modeling Framework".</li> |
| <li>Descriptive names may optionally include "Framework" |
| or "Tools" if the project has more of an emphasis on |
| extensible frameworks, or more on exemplary tools. Eclipse |
| projects always provide both but may be tailored more toward one |
| or the other. When choosing to use these words, the team should |
| consider that "Framework" and "Tools" |
| mean different things to different people and may even be |
| becoming overused. </li> |
| <li>Top-level projects may optionally include "Platform" |
| instead of "Framework".</li> |
| </ul> |
| </li> |
| <li><b>An optional Nickname.</b> Some teams like to have a clever |
| nicknames, for example "Higgins" or "Buckminister".</li> |
| <li><b>Project Name. </b>The full name includes the optional nickname, e.g., "The |
| Eclipse Component Assembly Project (Buckminister)".</li> |
| <li><b>Acronym.</b> Most descriptive names are sufficiently long |
| that it can be convenient to abbreviate them in some way. For |
| example, the Eclipse Communication Framework shortens to ECF.</li> |
| </ul> |
| </li> |
| <li><b>Vendor neutral.<br> |
| </b>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.</li> |
| <li> |
| <p align="left"><b>Place in the Eclipse architecture.</b><br> |
| 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? |
| </li> |
| </ul> |
| <p>The proposal itself is a static HTML page (with a small fragment of PHP) using the standard Eclipse Proposal |
| CSS style sheet (<a href="/proposals/templates/proposal-template.zip">please use |
| the template we provide</a>). 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. The proposal should include a list of interested and committed |
| persons and companies and their affiliations, but should not include corporate |
| or group logos.</p> |
| <p>Past proposals are available from the <a href="/proposals/">archived |
| proposals page</a>. Three particularly good examples to emulate are: <a href="/proposals/eclipse-mylar/">Mylar</a>, |
| <a href="/proposals/eclipse-gmf/">GMF</a>, and <a href="/proposals/eclipse-dsdp/">DSDP</a>.</p> |
| <p>The Pre-Proposal Phase ends when the proposal is made publicly available <a href="/proposals/"> on |
| the eclipse.org website</a>. The specific mechanics are: (these will eventually be |
| entered via a webform)</p> |
| <ol> |
| <li>The project short name is confirmed. The short name is the subset, |
| abbreviation, or acronym that the project will most common be known by. For |
| example the <a href="/tptp/">Test and Performance Tools Platform Project</a>'s |
| short name is TPTP.</li> |
| <li>The proposal is placed on the website.</li> |
| <li>The proposal is linked both the dedicated <i><a href="/proposals">proposals</a></i> area of the |
| website and from the hosting PMC's website, both described until the one |
| paragraph project description.</li> |
| <li>A newsgroup for discussion is created. |
| <ul> |
| <li> The newsgroup name will be <code>eclipse.[toplevel].[shortname]</code>. |
| The short name can be an abbreviation of the Descriptive Name, or an Acronym, e.g., |
| eclipse.technology.ecf, or it can be the optional Nickname, e.g., |
| eclipse.technology.buckminister.</li> |
| <li>A three |
| line newsgroup description is used for <a href="/newsgroups/">the |
| newsgroups page</a>.</li> |
| <li>The newsgroup is created last for several reasons. Many newsreaders actively |
| inform their users of the existence of a new newsgroup so when we first |
| created all the infrastructure in a single big bang, the project leaders |
| didn't have enough time to populate the main web page of the proposal before |
| it was "pre-announced" by the newsreader software. We now wait for |
| the main web page to be complete before the newsgroups are created. We then |
| post an initial message, inviting people to visit the newly created project |
| page to learn more about the project.</li> |
| </ul> |
| </li> |
| </ol> |
| <p>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&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.</p> |
| <p>If you do decide to issue a press release, the Eclipse Foundation Marketing |
| Director must help you coordinate the announcement. (<a href="mailto:emo@eclipse.org">Email |
| the EMO</a> for further information.)</p> |
| <p>The next phase is the <a href="proposal-phase.php">Proposal Phase</a>.</p> |
| |
| <h3>Legal Paperwork To Start Now</h3> |
| <p>It is important for the proposers to begin moving the various <a href="/legal/newcommitter.html">Committer |
| Agreements</a> through their company's legal department as it always seems to |
| take longer for this paperwork than one would like. The project cannot be provisioned |
| (provisioning happens after the Proposal Phase) without the Questionnaires and signed Agreements.</p> |
| |
| <hr> |
| <p><sup>1</sup> Projects often have seats on the top-level PMC, although the |
| exact policy depends on the PMC.<sup><br> |
| 2 </sup>This thought experiment may become EMO policy in the future.</p> |
| |
| <?php |
| include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php"); |
| ?> |
