| <?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 "right answers". 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. </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? 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 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? 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. |
| </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 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); |
| ?> |