<?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

$pageTitle 		= "Pre-Proposal Phase";
$pageKeywords	= "development process";
$pageAuthor		= "Bjorn Freeman-Benson Nov 20/05";

ob_start();
?>
    <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%">&nbsp;</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
Person X (Company Q) to propose the XYZ&nbsp; Project as a Technology incubator.<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 &quot;XYZ Project"*<br>
<br>
The goal of this project is to add comprehensive support blah blah blah...&nbsp;</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>&nbsp;<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 &quot;if I
        randomly choose five Committers from the entire Eclipse Committer pool,
        will those five people understand what this project is about?&quot; 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 &quot;the Eclipse
    technology is a vendor-neutral, open development platform supplying
    frameworks and exemplary, extensible tools&quot;.&nbsp;
    <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.&nbsp;</li>
      <li> Currently, the
    policy is that &quot;plumbing&quot;, 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 &quot;<a href="/gmf">Graphical
                Modeling Framework</a>&quot;, &quot;Trust Framework&quot; or
                &quot;Component Assembly Tools&quot;. 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 &quot;Eclipse&quot; or
                &quot;Project&quot;. The name should work with or without the
                prefix and suffix. For example, &quot;The Eclipse Graphical
                Modeling Framework Project&quot; as well as &quot;Graphical
                Modeling Framework&quot;.</li>
                  <li>Descriptive names may optionally include &quot;Framework&quot;
                or &quot;Tools&quot; 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 &quot;Framework&quot; and &quot;Tools&quot;
                    mean different things to different people and may even be
                    becoming overused.&nbsp;</li>
                  <li>Top-level projects may optionally include &quot;Platform&quot;
                instead of &quot;Framework&quot;.</li>
                </ul>
              </li>
              <li><b>An optional Nickname.</b> Some teams like to have a clever
                nicknames, for example &quot;Higgins&quot; or &quot;Buckminister&quot;.</li>
              <li><b>Project Name. </b>The full name includes the optional nickname, e.g., &quot;The
                Eclipse Component Assembly Project (Buckminister)&quot;.</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?&nbsp; Does it
    build on top of other projects?&nbsp; What are the dependencies?&nbsp; Does
    it overlap with existing projects?&nbsp;&nbsp;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.&nbsp;
    <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 &quot;pre-announced&quot; 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.&nbsp; 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.</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>
</div>
</div>
<?php
	# Paste your HTML content between the EOHTML markers!	
	$html = ob_get_contents();
	ob_end_clean();

	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
?>