Phoenix Release, 1.0
diff --git a/dev_process/index.php b/dev_process/index.php
new file mode 100644
index 0000000..9cfb423
--- /dev/null
+++ b/dev_process/index.php
@@ -0,0 +1,260 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Eclipse Development Process";
+$pageKeywords = "development process";
+$pageAuthor = "Bjorn Freeman-Benson Nov 20/05";
+
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-after-definitions.php");
+?>
+ <div id="maincontent">
+ <div id="midcolumn">
+
+<h1>Eclipse Development Process</h1>
+<p><i>version 028 - November 29, 2005 (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.html#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.html#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>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
