dev_process/index.php - www.eclipse.org/projects - Git at Google

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

 ob_start();
 ?>
     <div id="maincontent">
 	<div id="midcolumn">

 <h1>Eclipse Development Process</h1>
 <p><i>version 033 - January 26, 2006 (see the <a href="changelog.php">change log</a>
 for version information)</i></p>
 <h2>Goals</h2>
 <p align="left">These guidelines extend and augment the <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf"> Eclipse Development
 Process</a>. The
 primary goal of these guidelines is to provide guidance and clarity to individuals and companies who
 are proposing, leading, or participating in an Eclipse open source project. Like
 all new endeavors, the Process takes time to learn and practice to implement
 effectively. The purpose of these guidelines is to help you navigate the
 complexities, avoid the pitfalls, and become successful quickly. These
 guidelines do not substitute for a thorough reading of the <a href="/org/documents/"> Eclipse
 process</a> and <a href="/legal/">legal documents</a> including the <a href="/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf"> Eclipse
 Bylaws</a>, <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf"> Development
 Process</a>, and <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> IP
 Policy</a>.</p>
 <h2>Guiding Principles</h2>
 <p>There are a number of guiding principles around Eclipse:</p>
 <ul>
   <li><b>Quality</b> - In this context, quality means extensible frameworks and
     exemplary tools developed in an open, inclusive, and predictable process
     involving the entire community.&nbsp;
     <ul>
       <li>From the &quot;consumption perspective,&quot; Eclipse Quality means
         good for users (exemplary tools - cool/compelling to use, indicative of
         what is possible) and ready for plug-in developers (deliver usable
         building blocks - with APIs).&nbsp;</li>
       <li> From the &quot;creation perspective,&quot;
         Eclipse Quality means working with an open, transparent and permeable process, open
         (and welcoming) to participation from technical leaders, regardless of
         affiliation.</li>
       <li>From the &quot;community perspective,&quot; Eclipse Quality is that
         the community perceives quality, i.e., if the frameworks and tools are
         good enough to be used, then they have sufficient quality.</li>
       <li><b>Open </b>- Eclipse is open to all; Eclipse provides the same
         opportunity to all. Everyone participates with the same rules; there are
         no rules to exclude any potential contributors which includes, of
         course, direct competitors in the marketplace.</li>
       <li><b>Transparent </b>- The project is visible from the outside. The
         code, plans, minutes, etc. are all available to be read.</li>
       <li><b>Permeable</b> - Projects are open to new ideas; not just in words,
         but in fact. In other words, those outside the core can, and do, affect
         the project.</li>
     </ul>
   </li>
   <li><b>Collective Reputation</b> - Having the Eclipse name on a project
     provides a certain &quot;goodness&quot; to the project. And having great and
     amazing projects under the Eclipse banner provides a certain
     &quot;goodness&quot; to Eclipse. Correspondingly, having a highly-visible
     poor and/or failing project under the Eclipse banner detracts from that
     reputation.&nbsp;
     <ul>
       <li>A certain number of failures are expected in any research and
         development effort, thus we do not let the fear of failure prevent us
         from accepting interesting project. However, it is in the community's
         best interest to have a well-defined processes for identifying and
         dealing with failures when they occur.</li>
     </ul>
   </li>
   <li><b>Meritocracy</b> - Eclipse is a meritocracy. The more you contribute the more responsibility you will earn.
     Leadership roles in Eclipse are also merit-based and earned by peer acclaim.
     (See end of page for more explanation.)</li>
   <li><b>Evolving</b> - the frameworks, tools, projects, processes, community,
     and even the definition of Quality continues to, and will continue to,
     evolve. Creating rules or processes that force a static snapshot of any of
     these is detrimental to the health, growth, and ecosystem impact of Eclipse.</li>
   <li><b>Just Enough Process</b><i> </i>- The Eclipse Development Process should
     be &quot;just enough&quot; to ensure that the community's goals (quality,
     openness, etc), but no more - we want to make it easy and inviting for
     high-quality teams to build interesting tools at Eclipse. The entry bar
     should be &quot;just high enough&quot; to keep Eclipse great, but no more -
     we want to make it easy to experiment and explore new ideas while
     simultaneously supporting the ecosystem with strong releases. The entry bar
     should be &quot;just high enough&quot; to prevent Eclipse from growing too
     fast (because too rapid growth places too much of a strain on the mentoring
     capacity of the existing community) and &quot;definitely low enough&quot; to
     prevent it from stagnating.
     <ul>
       <li>The processes and goals should make projects:
         <ol>
           <li>Easy to propose</li>
           <li>Fairly easy to create</li>
           <li>Kinda hard to validate (e.g., exit incubation)</li>
           <li>Pretty tough to ship</li>
         </ol>
       </li>
       <li>The processes are designed to enhance the middle ground of continued
         quality growth in Eclipse projects by eliminating the two undesirable
         endpoints:
         <ul>
           <li>no entry bar results in a wild mish-mash of projects, and</li>
           <li>an entry bar so high that nothing new ever gets started</li>
         </ul>
       </li>
     </ul>
   </li>
   <li><b>Culture of Quality</b> - The Eclipse projects are managed by different
     people and different companies, most already experienced in software
     engineering. We want to ensure that we share the best practices of all our
     experts so that all projects benefit. We need to ensure that we have an
     &quot;Eclipse committer community&quot; rather than dozens of smaller
     &quot;project committer communities&quot;.</li>
   <li><b>Eclipse Ecosystem</b>  - The Eclipse open source projects are distinct
     from the Eclipse membership in spite of the majority of the resources on the
     projects being donated by the members. The projects are managed
     for the benefit of both the open source community and the ecosystem members;
     these groups will, at times, have different goals. Eclipse benefits when
     their interests align; Eclipse benefits when their interests provide
     cognitive dissonance that provokes creativity; and Eclipse suffers when one side of this duality
     takes precedence over the other side.</li>
 </ul>
 <h2>The Project Lifecycle</h2>
 <p>The <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
 Development Process</a> has projects go though a number of phases:</p>
 <ul>
   <li>
     <b><a href="pre-proposal-phase.php">Pre-proposal</a></b> - An individual or company declares their interest in,
     and rationale for, establishing a project.
     <ul>
       <li>The pre-proposal phase ends when the proposal is posted on the
         eclipse.org website.</li>
     </ul>
   </li>
   <li>
     <b><a href="proposal-phase.php">Proposal</a></b> - The
     proposers, in conjunction with the destination PMC and the community-at-large,
     collaborate in public to enhance, refine, and clarify the proposal. The proposal phase ends with a
     <a href="proposal-phase.php#Creation Review"> Creation Review</a>.
   </li>
   <li><b><a href="validation-phase.php">Validation</a></b> - After the project has
     been created, the purpose of the validation phase is to establish a
     fully-functioning open-source project. In this context, validation (also
     known as incubation) is about
     developing the process, the community, and the technology.&nbsp;
     <ul>
       <li>While it might seem easy, history
     has shown that it takes experience to run an open, transparent, inviting,
         permeable, 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 and committers around a new project.</li>
       <li>Similarly, the validation phase is about developing the technology to <a href="eclipse-quality.php">Eclipse
     Quality</a>. 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.</li>
       <li>Validation/incubation is a phase rather than a place - new projects
         may be incubated under any existing top-level project. This is different
         from the way <a href="http://incubator.apache.org/">Apache</a> uses a place to
         encapsulate the phase. Incubating under an existing top-level project is
         a significant investment in time and energy by the top-level PMC, so
         most projects incubate under the Technology top-level project due to
         Technology's experience in this area.</li>
       <li>Validation ends with an <a href="validation-phase.php#Checkpoint Review">Checkpoint
         Review</a>.</li>
     </ul>
   </li>
   <li><b><a href="implementation-phase.php">Implementation</a></b> - The
     project team has demonstrated that they are an open-source project with an
     open and transparent process; an actively involved and growing community;
     and <a href="eclipse-quality.php">Eclipse
     Quality</a> technology. The project is now a mature member of the Eclipse Community. Major
     releases continue to go through <a href="release-review.php">Release
     Reviews</a>.
   </li>
   <li><b><a href="archived-phase.php">Archived</a> </b>- Projects that become inactive, either
     through dwindling resources or by reaching their natural conclusion, are archived. Projects
     can reach their natural conclusion by, for example, becoming so popular that
     they are absorbed into one of the underlying platform frameworks.</li>
 </ul>
 <h3>Top-Level Projects</h3>
 <p>Top-level Projects are more significant than normal Eclipse Projects because
 they encompass an area or category of the tooling space. The responsibilities of
 a top-level project are greater and thus the criteria for approval are higher.
 The organization of a top-level project is a little different than a normal
 project because it has a PMC that manages a set of projects rather than a
 project lead that manages a single team. More than that, however, a top level
 PMC must:</p>
 <ul>
   <li>Provide technical leadership to Eclipse in their specific area. Leadership
     includes helping to create and define the Eclipse direction via
     participating in <a href="/org/foundation/council.php">the Councils</a> and creating the Eclipse
     Roadmap. Leadership includes outreach activities and supportive marketing
     activities. The consequence of the leadership required is that a top-level
     PMC is more than just a project management committee - it's almost a small
     startup in itself.</li>
   <li>Gather and create an active and diverse community of contributors. These
     communities do not just happen, thus a top-level PMC must actively recruit
     additional companies and individuals.&nbsp;</li>
 </ul>
 <p>Top-level projects go through the same phases as sub-projects: Pre-proposal,
 Proposal, Validation, Mature (and perhaps even Archived), but they do so to the higher
 standards of demonstrating <i>leadership</i> as well as <i>competence</i>.</p>
 <p>Because Top-Level Projects are the technical leadership of Eclipse, it is
 important that the PMC members &quot;get&quot; what Eclipse is about. It isn't
 possible or useful to write down a strict set of rules that define what is
 Eclipse, although we can write a few generalities:</p>
 <ul>
   <li>Eclipse is a diversity of cultures</li>
   <li>Eclipse has well-defined processes that its members follow</li>
   <li>Eclipse has well-defined goals and objectives at which its members strive
     to excel</li>
   <li>Eclipse accepts and encourages differences in execution amongst its
     members</li>
 </ul>
 <p>There are a number of techniques for knowledge transfer:</p>
 <ol>
   <li><b>Reading</b> - the Eclipse culture is transferred to a new PMC through
     the new PMC members reading the &quot;what is our culture&quot;
     documentation. This documentation does not currently exist so this is not a
     practical choice.</li>
   <li><b>Immersion</b> - members of new PMCs are assigned to existing (mature)
     PMCs where they participate as full-fledged PMC members. They learn by
     doing, helping the existing PMC and thus learning the culture that they can
     take back to their PMC.</li>
   <li><b>Mentoring </b>- members of existing (mature) PMCs volunteer to be
     assigned to the
     new PMCs as mentors. The mentors attend the weekly PMC meetings, providing
     advice and counsel.</li>
   <li><b>Recruitment</b> - Mentoring/guidance, but using EMO personnel instead of
     existing PMCs.</li>
 </ol>

 <p>We should note that, historically, Top-Level Projects work better when led by
 a Strategic Developer - it seems to take a commitment of Strategic size to start
 and run a Top-Level Project.</p>
 <h2>Meritocracy</h2>
 <p>There are currently three mechanisms for earning the respect and acclaim
 necessary to become an Eclipse Committer.</p>
 <ul>
   <li>Starting a new Eclipse project is an effort and a contribution and
     (obviously) allows you to be a committer on that project. As the project
     grows in reliability, predictability, and results, your reputation in the
     community increases.</li>
   <li>Your employer commits you to an Eclipse project on a full-time basis -
     working full-time on the project allows you to quickly gain the respect of
     your peers and become a committer.</li>
   <li>You contribute on a part-time basis, working on a particular aspect of a
     project. While we would like to make this easier, it is currently the
     hardest way to become a Committer, at least on the top-level projects. The
     main barrier to entry is that because the top-level projects have large
     full-time populations of Committers, the projects move very rapidly and that
     makes it hard for a part-time developer to keep up. Part-time contributions
     are successful in corners of the space such as writing tutorials and
     articles, updating the website, coding non-critical-path components, etc.</li>
 </ul>
 </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);
 ?>
	<?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 = "Eclipse Development Process";
	$pageKeywords = "development process";
	$pageAuthor = "Bjorn Freeman-Benson Nov 20/05";

	ob_start();
	?>
	<div id="maincontent">
	<div id="midcolumn">

	<h1>Eclipse Development Process</h1>
	<p><i>version 033 - January 26, 2006 (see the <a href="changelog.php">change log</a>
	for version information)</i></p>
	<h2>Goals</h2>
	<p align="left">These guidelines extend and augment the <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf"> Eclipse Development
	Process</a>. The
	primary goal of these guidelines is to provide guidance and clarity to individuals and companies who
	are proposing, leading, or participating in an Eclipse open source project. Like
	all new endeavors, the Process takes time to learn and practice to implement
	effectively. The purpose of these guidelines is to help you navigate the
	complexities, avoid the pitfalls, and become successful quickly. These
	guidelines do not substitute for a thorough reading of the <a href="/org/documents/"> Eclipse
	process</a> and <a href="/legal/">legal documents</a> including the <a href="/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf"> Eclipse
	Bylaws</a>, <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf"> Development
	Process</a>, and <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> IP
	Policy</a>.</p>
	<h2>Guiding Principles</h2>
	<p>There are a number of guiding principles around Eclipse:</p>
	<ul>
	<li><b>Quality</b> - In this context, quality means extensible frameworks and
	exemplary tools developed in an open, inclusive, and predictable process
	involving the entire community.
	<ul>
	<li>From the "consumption perspective," Eclipse Quality means
	good for users (exemplary tools - cool/compelling to use, indicative of
	what is possible) and ready for plug-in developers (deliver usable
	building blocks - with APIs). </li>
	<li> From the "creation perspective,"
	Eclipse Quality means working with an open, transparent and permeable process, open
	(and welcoming) to participation from technical leaders, regardless of
	affiliation.</li>
	<li>From the "community perspective," Eclipse Quality is that
	the community perceives quality, i.e., if the frameworks and tools are
	good enough to be used, then they have sufficient quality.</li>
	<li><b>Open </b>- Eclipse is open to all; Eclipse provides the same
	opportunity to all. Everyone participates with the same rules; there are
	no rules to exclude any potential contributors which includes, of
	course, direct competitors in the marketplace.</li>
	<li><b>Transparent </b>- The project is visible from the outside. The
	code, plans, minutes, etc. are all available to be read.</li>
	<li><b>Permeable</b> - Projects are open to new ideas; not just in words,
	but in fact. In other words, those outside the core can, and do, affect
	the project.</li>
	</ul>
	</li>
	<li><b>Collective Reputation</b> - Having the Eclipse name on a project
	provides a certain "goodness" to the project. And having great and
	amazing projects under the Eclipse banner provides a certain
	"goodness" to Eclipse. Correspondingly, having a highly-visible
	poor and/or failing project under the Eclipse banner detracts from that
	reputation.
	<ul>
	<li>A certain number of failures are expected in any research and
	development effort, thus we do not let the fear of failure prevent us
	from accepting interesting project. However, it is in the community's
	best interest to have a well-defined processes for identifying and
	dealing with failures when they occur.</li>
	</ul>
	</li>
	<li><b>Meritocracy</b> - Eclipse is a meritocracy. The more you contribute the more responsibility you will earn.
	Leadership roles in Eclipse are also merit-based and earned by peer acclaim.
	(See end of page for more explanation.)</li>
	<li><b>Evolving</b> - the frameworks, tools, projects, processes, community,
	and even the definition of Quality continues to, and will continue to,
	evolve. Creating rules or processes that force a static snapshot of any of
	these is detrimental to the health, growth, and ecosystem impact of Eclipse.</li>
	<li><b>Just Enough Process</b><i> </i>- The Eclipse Development Process should
	be "just enough" to ensure that the community's goals (quality,
	openness, etc), but no more - we want to make it easy and inviting for
	high-quality teams to build interesting tools at Eclipse. The entry bar
	should be "just high enough" to keep Eclipse great, but no more -
	we want to make it easy to experiment and explore new ideas while
	simultaneously supporting the ecosystem with strong releases. The entry bar
	should be "just high enough" to prevent Eclipse from growing too
	fast (because too rapid growth places too much of a strain on the mentoring
	capacity of the existing community) and "definitely low enough" to
	prevent it from stagnating.
	<ul>
	<li>The processes and goals should make projects:
	<ol>
	<li>Easy to propose</li>
	<li>Fairly easy to create</li>
	<li>Kinda hard to validate (e.g., exit incubation)</li>
	<li>Pretty tough to ship</li>
	</ol>
	</li>
	<li>The processes are designed to enhance the middle ground of continued
	quality growth in Eclipse projects by eliminating the two undesirable
	endpoints:
	<ul>
	<li>no entry bar results in a wild mish-mash of projects, and</li>
	<li>an entry bar so high that nothing new ever gets started</li>
	</ul>
	</li>
	</ul>
	</li>
	<li><b>Culture of Quality</b> - The Eclipse projects are managed by different
	people and different companies, most already experienced in software
	engineering. We want to ensure that we share the best practices of all our
	experts so that all projects benefit. We need to ensure that we have an
	"Eclipse committer community" rather than dozens of smaller
	"project committer communities".</li>
	<li><b>Eclipse Ecosystem</b> - The Eclipse open source projects are distinct
	from the Eclipse membership in spite of the majority of the resources on the
	projects being donated by the members. The projects are managed
	for the benefit of both the open source community and the ecosystem members;
	these groups will, at times, have different goals. Eclipse benefits when
	their interests align; Eclipse benefits when their interests provide
	cognitive dissonance that provokes creativity; and Eclipse suffers when one side of this duality
	takes precedence over the other side.</li>
	</ul>
	<h2>The Project Lifecycle</h2>
	<p>The <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
	Development Process</a> has projects go though a number of phases:</p>
	<ul>
	<li>
	<b><a href="pre-proposal-phase.php">Pre-proposal</a></b> - An individual or company declares their interest in,
	and rationale for, establishing a project.
	<ul>
	<li>The pre-proposal phase ends when the proposal is posted on the
	eclipse.org website.</li>
	</ul>
	</li>
	<li>
	<b><a href="proposal-phase.php">Proposal</a></b> - The
	proposers, in conjunction with the destination PMC and the community-at-large,
	collaborate in public to enhance, refine, and clarify the proposal. The proposal phase ends with a
	<a href="proposal-phase.php#Creation Review"> Creation Review</a>.
	</li>
	<li><b><a href="validation-phase.php">Validation</a></b> - After the project has
	been created, the purpose of the validation phase is to establish a
	fully-functioning open-source project. In this context, validation (also
	known as incubation) is about
	developing the process, the community, and the technology.
	<ul>
	<li>While it might seem easy, history
	has shown that it takes experience to run an open, transparent, inviting,
	permeable, 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 and committers around a new project.</li>
	<li>Similarly, the validation phase is about developing the technology to <a href="eclipse-quality.php">Eclipse
	Quality</a>. 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.</li>
	<li>Validation/incubation is a phase rather than a place - new projects
	may be incubated under any existing top-level project. This is different
	from the way <a href="http://incubator.apache.org/">Apache</a> uses a place to
	encapsulate the phase. Incubating under an existing top-level project is
	a significant investment in time and energy by the top-level PMC, so
	most projects incubate under the Technology top-level project due to
	Technology's experience in this area.</li>
	<li>Validation ends with an <a href="validation-phase.php#Checkpoint Review">Checkpoint
	Review</a>.</li>
	</ul>
	</li>
	<li><b><a href="implementation-phase.php">Implementation</a></b> - The
	project team has demonstrated that they are an open-source project with an
	open and transparent process; an actively involved and growing community;
	and <a href="eclipse-quality.php">Eclipse
	Quality</a> technology. The project is now a mature member of the Eclipse Community. Major
	releases continue to go through <a href="release-review.php">Release
	Reviews</a>.
	</li>
	<li><b><a href="archived-phase.php">Archived</a> </b>- Projects that become inactive, either
	through dwindling resources or by reaching their natural conclusion, are archived. Projects
	can reach their natural conclusion by, for example, becoming so popular that
	they are absorbed into one of the underlying platform frameworks.</li>
	</ul>
	<h3>Top-Level Projects</h3>
	<p>Top-level Projects are more significant than normal Eclipse Projects because
	they encompass an area or category of the tooling space. The responsibilities of
	a top-level project are greater and thus the criteria for approval are higher.
	The organization of a top-level project is a little different than a normal
	project because it has a PMC that manages a set of projects rather than a
	project lead that manages a single team. More than that, however, a top level
	PMC must:</p>
	<ul>
	<li>Provide technical leadership to Eclipse in their specific area. Leadership
	includes helping to create and define the Eclipse direction via
	participating in <a href="/org/foundation/council.php">the Councils</a> and creating the Eclipse
	Roadmap. Leadership includes outreach activities and supportive marketing
	activities. The consequence of the leadership required is that a top-level
	PMC is more than just a project management committee - it's almost a small
	startup in itself.</li>
	<li>Gather and create an active and diverse community of contributors. These
	communities do not just happen, thus a top-level PMC must actively recruit
	additional companies and individuals. </li>
	</ul>
	<p>Top-level projects go through the same phases as sub-projects: Pre-proposal,
	Proposal, Validation, Mature (and perhaps even Archived), but they do so to the higher
	standards of demonstrating <i>leadership</i> as well as <i>competence</i>.</p>
	<p>Because Top-Level Projects are the technical leadership of Eclipse, it is
	important that the PMC members "get" what Eclipse is about. It isn't
	possible or useful to write down a strict set of rules that define what is
	Eclipse, although we can write a few generalities:</p>
	<ul>
	<li>Eclipse is a diversity of cultures</li>
	<li>Eclipse has well-defined processes that its members follow</li>
	<li>Eclipse has well-defined goals and objectives at which its members strive
	to excel</li>
	<li>Eclipse accepts and encourages differences in execution amongst its
	members</li>
	</ul>
	<p>There are a number of techniques for knowledge transfer:</p>
	<ol>
	<li><b>Reading</b> - the Eclipse culture is transferred to a new PMC through
	the new PMC members reading the "what is our culture"
	documentation. This documentation does not currently exist so this is not a
	practical choice.</li>
	<li><b>Immersion</b> - members of new PMCs are assigned to existing (mature)
	PMCs where they participate as full-fledged PMC members. They learn by
	doing, helping the existing PMC and thus learning the culture that they can
	take back to their PMC.</li>
	<li><b>Mentoring </b>- members of existing (mature) PMCs volunteer to be
	assigned to the
	new PMCs as mentors. The mentors attend the weekly PMC meetings, providing
	advice and counsel.</li>
	<li><b>Recruitment</b> - Mentoring/guidance, but using EMO personnel instead of
	existing PMCs.</li>
	</ol>

	<p>We should note that, historically, Top-Level Projects work better when led by
	a Strategic Developer - it seems to take a commitment of Strategic size to start
	and run a Top-Level Project.</p>
	<h2>Meritocracy</h2>
	<p>There are currently three mechanisms for earning the respect and acclaim
	necessary to become an Eclipse Committer.</p>
	<ul>
	<li>Starting a new Eclipse project is an effort and a contribution and
	(obviously) allows you to be a committer on that project. As the project
	grows in reliability, predictability, and results, your reputation in the
	community increases.</li>
	<li>Your employer commits you to an Eclipse project on a full-time basis -
	working full-time on the project allows you to quickly gain the respect of
	your peers and become a committer.</li>
	<li>You contribute on a part-time basis, working on a particular aspect of a
	project. While we would like to make this easier, it is currently the
	hardest way to become a Committer, at least on the top-level projects. The
	main barrier to entry is that because the top-level projects have large
	full-time populations of Committers, the projects move very rapidly and that
	makes it hard for a part-time developer to keep up. Part-time contributions
	are successful in corners of the space such as writing tutorials and
	articles, updating the website, coding non-critical-path components, etc.</li>
	</ul>
	</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);
	?>