dev_process/validation-phase.php

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

ob_start();
?>
    <div id="maincontent">
	<div id="midcolumn">
		
<h1>Validation Phase</h1>
<p><i>version 023 - August 19, 2005</i></p>
<p><a href="index.php">[This is one page of the larger document.]</a></p>
<h2>Validation (Incubation) Phase</h2>

<p>The purpose of the validation phase is to establish a
    fully-functioning open-source project. In this context, validation (incubation) is about
    developing the process and the community. While it might seem easy, history
    has shown that it takes experience to run an open, transparent, welcoming, and predictable software development process. And history has shown that it
    takes a significant investment of time and energy to nurture a community of
    tool users and framework users around a new project.</p>

<p>The validation phase includes typical software project management issues such
as identifying critical use cases, producing a high level design, acquiring the
necessary rights to all requirement intellectual property, and so on. The
validation phase also includes creating viable user, plug-in developer, and
committer communities around the project.</p>

<h3><a name="Three Communities">Three Communities</a></h3>

<p>The Eclipse Bylaws section 1.1 describes the purpose of the Eclipse projects
as &quot;a vendor-neutral, open development platform supplying frameworks and
exemplary, extensible tools... [the] tools are extensible in that their
functionality is accessible via documented programmatic interfaces.&quot;
Essential to that purpose is the development of three inter-related communities
around each project:</p>

<ul>
  <li><b>Committers</b> - an active, open, transparent, inclusive, and diverse community
    of Committers, developers, and other non-Committer contributors is essential for the health of
    the project. Attracting new contributors and committers to an open source
    project is time consuming and requires active recruiting, not just passive
    &quot;openness&quot;. The project leadership must go out of its way to
    encourage and nurture new contributors.&nbsp; A Committer community
    comprised entirely, or even in the majority, from a single company is
    contra-indicated for a project's long-term success as an open source
    project.&nbsp;</li>
  <li><b>Users</b> - an active and engaged user community is proof-positive that
    the project's exemplary tools are useful and needed. Furthermore, a large
    user community is one of the key factors in creating a viable ecosystem
    around an Eclipse project, thus bringing additional open source and
    commercial organizations on board. Like all good things, a user community
    takes time and effort to bring to fruition, but once established is nicely
    self-sustaining.</li>
  <li><b>Plug-in Developers</b> - an active and engaged plug-in developer
    community is only way to prove that an Eclipse project is providing
    extensible frameworks and extensible tools accessible via documented APIs.
    Reuse of the frameworks within the companies that are contributing to the
    project is necessary, but not sufficient to demonstrate a plug-in community.
    Again, creating, encouraging, and nurturing a plug-in developer community
    outside of the project's developers takes time, energy, and creativity by
    the project leadership, but is essential to the project's long-term open
    source success.</li>
</ul>
<p>The Eclipse community considers the absence of any one or more of these
communities as proof that the project is not sufficiently open, transparent,
permeable, and
inviting, and/or that it has emphasized tools at the expense of extensible
frameworks or vice versa.</p>
<p>Many Eclipse projects are proposed and initiated by companies and personnel
with extensive software development experience. No doubt these teams already
understand that each organization has a slightly different way of doing things
and that the Validation/Incubation Phase is useful for &quot;learning the
ropes&quot; of Eclipse open source projects.</p>

<h3>Initial Code and Development</h3>

<p>The Validation Phase is also when initial code contributions are gathered,
designs and prototypes are created, and a project plan is formulated. This is
also when the first APIs are being designed, spec'd and distributed to the
community for feedback and review. A few of the issues to consider in phase are:</p>

<ol>
  <li>All code contributions, including initial code contributions, must be
    vetted against the IP Policy by the EMO. This is one of the issues discussed
    in the <a href="/legal/committerguidelines.phpl">Due Diligence Guidelines</a>,
    and is begun by filling out one or more <a href="/legal/ContributionQuestionnairePart1-v1.0.php">Contribution
    Questionnaire</a> (also see the <a href="/legal/EclipseLegalProcessPoster-v1.2.2.pdf">descriptive process flowchart poster</a>). Note that the due diligence process takes, on average,
    four to six weeks, thus it is important not to delay starting the process.</li>
  <li><a href="eclipse-quality.php">Platform quality APIs</a> are extremely
    important for Eclipse and Platform quality APIs take a lot of hard work to
    create. Thus it is essential that all new Eclipse projects start their API
    design, specification, and review process as they start
    committing code to their CVS repository.</li>
  <li> The project will most likely produce a number of 0.N releases
    during this phase in order to garner feedback from the community on their
    APIs and tools. This feedback loop is essential to bootstrapping the three
    communities.</li>
</ol>

<p>The mechanics and obligations of running a Validation Phase project (adding committers,
adding mailing lists, etc) are similar to those of running an Implementation Phase
project so the reader is directed to <a href="implementation-phase.php">the
Implementation Phase page for their descriptions</a>.</p>
<h4>Project Log</h4>
<p style="border-style: dotted; border-width: 2; padding-left: 5; padding-right: 5; padding-top: 2; padding-bottom: 2">The <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> Eclipse IP Policy</a> requires
    <a href="/legal/committerguidelines.php"> certain due
    diligence and record keeping</a>.
    Small contributions in the form of bugzilla patches and the like can be
    committed directly to the code base (after the appropriate contributor
    information is recorded). Medium, large, and all third-party (non-EPL
    licensed) contributions require the <a href="/legal/ContributionQuestionnairePart1-v1.0.htm"> Code Contribution
    Questionnaire</a> and
    additional record keeping (also see the <a href="/legal/EclipseLegalProcessPoster-v1.2.2.pdf">descriptive process flowchart poster</a>). Maintaining a current and accurate <a href="project-log.php"> Project Log</a> is
    the best way to keep this information up-to-date.</p>
<h4>Bugzilla</h4>
<p>A common question new projects ask is &quot;how should we use Bugzilla
effectively?&quot;. There are many schemes for using Bugzilla, but a common one
is described on <a href="bugzilla-use.php">another page</a>.</p>
<h4>Heartbeat Builds</h4>
<p>We have learned that projects cannot successfully build their three
communities without regular milestone releases (we recommend six to eight week
periods), nor can it do so without regular, successful, heartbeat builds (we
recommend at least nightly). Projects need regular milestones and builds so that
their three communities can continuously pick up, integrate, test, use, and
provide feedback on the latest features and improvements. Projects that do not
provide frequent builds are effectively working in the closed rather than in the
open.</p>

<p>Projects often make use of the PDE project's <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.releng.basebuilder/readme.html?rev=HEAD">PDE
BUILD tools</a> to help automate the builds.</p>

<ul>
  <li>We recommend that the automated build system use anonymous pserver CVS
    commands rather than extssh because it's faster, it's more secure (no
    developer password), and build system errors cannot accidentally modify any
    files.</li>
</ul>

<h4><b>Brand graphics and watermarks</b></h4>

<p>Projects in proposal and validation/incubation stages must use the
    appropriate Eclipse-branded graphics in place of the usual Eclipse graphic (i.e.,
    the Eclipse Proposal graphic and the Eclipse Incubation graphic<sup>1</sup> respectively) on
    their webpage. Projects in the proposal phase must use the appropriate watermark on their web
    pages.</p>

<h3><a name="Exiting Validation">Exiting Validation/Incubation</a></h3>

<p>The criteria for exiting Validation include:</p>

<ul>
  <li>A working and demonstrable code base.</li>
  <li>Active communities:
    <ul>
      <li>An active framework user (plug-in provider) community.<sup>2</sup>
      </li>
      <li>An active tool user community.</li>
      <li>An active multi-organization committer/contributor/developer community.<sup>3</sup>
      </li>
    </ul>
  </li>
  <li>The project is operating fully in the open using open source rules of
    engagement, e.g.,
    <ul>
      <li>Open and transparent Bugzilla with a described and documented bug process.</li>
      <li>Open and transparent project schedules.</li>
      <li>The project has working policies and procedures for developing,
    specifying, testing, and getting feedback on APIs.</li>
      <li>The project decision making processes are published, and all project
        decisions are being made in public.</li>
    </ul>
  </li>
  <li>The project team members have learned the ropes and logistics of being an
    Eclipse project. In <a href="http://incubator.apache.org/incubation/Incubation_Policy.html">Apache
    parlance</a>, the project &quot;gets the Eclipse way&quot;.
    <ul>
      <li>Conforming to the entire Eclipse Development Process.</li>
      <li>Adherence to the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> Eclipse IP Policy</a> including self-assessment
    by each Committer on the <a href="/legal/committerguidelines.php"> committer responsibilities and due
        diligence</a>.</li>
      <li>Participating in the larger Eclipse community. For example, teaching
    tutorials at EclipseCon, writing articles, commenting on other projects at
    Reviews and other times, etc.</li>
      <li>Working with other projects in its destination PMC.</li>
      <li>The project is a credit to Eclipse and is functioning well within the
        Eclipse community.</li>
    </ul>
  </li>
  <li>An in-depth review of the technical architecture of the project, and its
    dependencies and interactions with other projects.</li>
</ul>
<p>Projects are responsible for requesting a Checkpoint Review when the project
leadership believes the project meets the exit criteria. The EMO will evaluate
the request and act appropriately. Projects that are not making sufficient
progress towards a Review will be at first gently, then, over time more
forcefully, reminded that inaction is the same as negative action.</p>
<h3><a name="Checkpoint Review">Checkpoint Review</a></h3>
<p>The validation/incubation phase ends with a Checkpoint Review. <a href="review-mechanisms.php"> Like all
Reviews</a>, the
validation review starts with a presentation by the project leadership followed
by questions from the membership.</p>
<p>The Checkpoint Review is basically a <a href="release-review.php">Release
Review</a>, but with added responsibility of verifying that <a href="#Exiting Validation"> the
exit criteria listed above</a> are met. This is a very important Review because this is the last time
that the entire Eclipse community will provide a first-level review of the
project. Historically, future reviews, such as Release Reviews, tend to be second-order
reviews - reviews that examine the surface appearance of the project/release
rather than the deep details of the project/release. This is not for a lack of
desire, but rather for a lack of resources. Thus future Reviews rely on
self-certification by the project teams that they are following the Eclipse
principles and standards.&nbsp; The Validation Review is where the community
ascertains to its own satisfaction that the project team understands and has
adopted the principles and practices of the Eclipse Development Process.</p>
<p>The next phase is the <a href="implementation-phase.php">Implementation Phase</a>.</p>

<hr>
<p align="left"><sup>2</sup> It is essential for an Eclipse project to have
both an extensible framework and exemplary tools. However, if one had to
prioritize between the two, an extensible framework is more important -
Eclipse is about enabling the ecosystem rather than just about giving away free
tools.<br>
<sup>3</sup> We note that there is evidence that having a single
company with a focused, well socialized team, is a good way to start up a
challenging new project. We do not want to discourage this start-up method, but
we do want to ensure that for a project to move into the Implementation Phase,
it has an expanded committer community.</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);
?>