<?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 		= "Proposal Phase";
$pageKeywords	= "development process";
$pageAuthor		= "Bjorn Freeman-Benson Nov 20/05";

ob_start();
?>
    <div id="maincontent">
	<div id="midcolumn">
		
<h1>Proposal Phase</h1>
<p><i>version 033 - January 26, 2006</i></p>
<p><a href="index.php">[This is one page of the larger document.]</a></p>
<h2>Proposal Phase</h2>
<p>The Proposal Phase is when the proposers, in conjunction with the destination PMC and the community-at-large,
    collaborate in public to enhance, refine, and clarify the proposal.
Historically, the proposal phase has been approximately two months for simpler
projects and longer than that for complex or controversial projects. When the
proposers believe that the requirements listed here have been met, they ask the
EMO to schedule a <a href="#Creation Review">Creation Review</a>.</p>
<p>In addition to the proposal characteristics described on the pre-proposal
phase page, the further requirements for exiting the Proposal Phase (i.e., for
creating the project) are as follows. Note that these requirements are almost
entirely qualitative and thus there are no &quot;right answers&quot;. The
expectation is that projects will have good answers and explanations for these
items in order to pass the <a href="#Creation Review">Creation Review</a>..</p>
<ul>
  <li><b>Description.</b><br>
    Refining the project description based on feedback from the community. The
    community may find certain aspects confusing or unclear and the goal of the
    Proposal Phase is to make those clear. This is a hard and fast requirement:
    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 marketing-speak-free.&nbsp;</li>
  <li><b>Maturity Plan.</b><br>
    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?&nbsp; 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)?&nbsp; Etc. Note that this is a plan,
    not a commitment, but it does need to be a realistic plan.</li>
  <li><b>Community.</b><br>
    Does the project have a community of contributors and committers 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.</li>
  <li><b>Diversity.</b><br>
    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. Proposals are not required to be diverse, but projects cannot
    graduate from incubation without diversity.</li>
  <li><b>Collaborations.</b><br>
    Successful Eclipse projects extend and enhance the Eclipse tool suite, and
    thus successful Eclipse projects are those that collaborate with existing
    Eclipse, or other open source, projects. Again, it can be hard to start a
    collaboration before demonstrating the technology, but at the same time it
    is never too early to start discussing collaborations with other projects.
    Additionally, it never hurts to join and help an existing project to start
    establishing those social networks that will make future collaborations on
    the new project possible.</li>
  <li><b>Extensible frameworks and exemplary tools.</b><br>
    Is this project visibly committed to producing both extensible
    frameworks and exemplary tools built on top of those frameworks?
    Eclipse is dependent on its projects producing both frameworks for the
    ecosystem to extend, and end-user tools to attract the critical mass of
    users which enable the ecosystem to exist.</li>
  <li><b>Technical.</b><br>
    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.</li>
  <li>
<b> Place in the Eclipse architecture.
    </b> <br>
For each place this project overlaps an existing Eclipse project, what does
    the overlapee say about the potential overlap?&nbsp; Note that the
    overlapee's opinion does not have to be positive, but that it is important
    for new projects to understand where they fit and for existing project to
    understand what new developments might be coming along.&nbsp;
  </li>
  <li>
<b>Advocates.</b><br>
While not required, it is advantageous for new proposals to be advocated or
championed. A proposal should have at least two advocates. The advocates (or
lack of advocates) should be listed in the proposal, along with their
affiliations and (if applicable) their Eclipse projects.
  </li>
  <li>
<b>Use brand graphics and watermarks correctly.<br>
    </b>Projects in proposal and validation/incubation stages must use the
    appropriate <a href="/projects/gazoo.php">Eclipse-branded graphics</a> (i.e.,
    the Eclipse Proposal graphic and the Eclipse Incubation graphic respectively) on
    their webpage. Projects in the proposal phase must use the appropriate watermark on their web
    pages.
  </li>
  <li>
<b>Follow the press guidelines.<br>
</b>Projects must follow the <a href="/org/press-release/pressguidelines.htm">Eclipse
Foundation press guidelines</a> in the preparation, wording, and dissemination
of press releases.
  </li>
</ul>
<h3>Legal Paperwork To Start Now</h3>
<p>If haven't already started moving the various <a href="/legal/newcommitter.html">Committer
Agreements</a> through the proposers' company's legal departments, now is the
time to start. It always seems to
take longer for this paperwork than one would like and the project cannot be provisioned
without the Questionnaires and signed Agreements.</p>
<h3>Feedback From the Members and Committers</h3>
<p>The proper functioning of the Eclipse Development Process is contingent on
the active participation of the Eclipse Members and Committers. The process is
positive biased in that Reviews require negative votes (vetos) to fail rather
than positive votes to proceed. Thus a Member or Committer who does not read,
review, and comment on a proposal <i><b>implicitly</b></i> endorses that
proposal. Thus it behooves all in the community to take an active role in
reading proposals and review material in order to make that endorsement
explicitly rather than implicitly.<sup>2,3</sup></p>
<p>One should also note that due to the social dynamics of the Eclipse projects
and membership, it is unlikely that negative votes (vetos) will occur without
prior notice at Reviews. Thus negative or critical comments are most useful in
advance, in the newsgroups and mailing lists associated with the proposal or
review.</p>
<h3><a name="Creation Review">Creation Review</a></h3>
<p>The proposal phase ends with a Creation Review. The proposed project lead is expected to make
a brief presentation to the review committee as well as any interested Eclipse
members; the <a href="review-mechanisms.php">Review Mechanisms page</a>
describes the Review itself. The presentation should include:</p>
<ol>
  <li>Brief summary of the project proposal</li>
  <li>Comments about the community response to the proposal</li>
  <li>Current project participants</li>
  <li>Initial implementation focus</li>
  <li>Confirmation that the project members have read and understand the Eclipse
    Development Process and these guidelines</li>
  <li>Future directions. </li>
</ol>
<p>See the successful
presentations in the <a href="/proposals/">Proposals Archive</a> for
examples.</p>
<p>After a successful Creation Review, the project is considered <i>created</i>,
and the proposers fill out the <a href="/projects/project_provisioning_request.php">Validation
Phase Provisioning Request</a> form to create their CVS repository, mailing
lists, website, download area, etc. The next phase is the <a href="validation-phase.php">Validation
Phase</a>.
</p>

<h3>Top-Level Projects
</h3>

<p>Top-level projects have Charters (sub-projects exist under the Charter of
their parent top-level project). Thus new top-level projects have their Charters
reviewed at their Creation Review. Writing a new Charter, especially writing a
Scope definition that is not overly broad, is a difficult task. New top-level
projects should start by referencing the <a href="Eclipse_Standard_TopLevel_Charter_v1.0.php">Standard
Top-Level Charter</a> and then plan to spend many hours across a number of
calendar weeks refining the statement to the satisfaction of the Board and the
entire Eclipse community.
</p>

<hr>
<p><sup>
2</sup> Note that this implicit positive endorsement is different from
the way the top-level project Charters define the process for adding new
Committers and code contributions to a project. The Charters are negative biased
because they require&nbsp; three positive votes.<sup><br>
3</sup> The EMO is considering a number of schemes for proposal and project
reviews. One proposal, assuming there are not sufficient resources to review all
proposals, is to put together small ad-hoc committees of committers to review a
random sampling of proposals and projects.</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);
?>