Phoenix Release, 1.0
diff --git a/dev_process/.cvsignore b/dev_process/.cvsignore
new file mode 100644
index 0000000..553e3a8
--- /dev/null
+++ b/dev_process/.cvsignore
@@ -0,0 +1 @@
+_vti_cnf
diff --git a/dev_process/Eclipse Quality APIs v2.pdf b/dev_process/Eclipse Quality APIs v2.pdf
new file mode 100644
index 0000000..22abf23
--- /dev/null
+++ b/dev_process/Eclipse Quality APIs v2.pdf
Binary files differ
diff --git a/dev_process/Eclipse_Standard_TopLevel_Charter_v1.0.php b/dev_process/Eclipse_Standard_TopLevel_Charter_v1.0.php
new file mode 100644
index 0000000..f3d874f
--- /dev/null
+++ b/dev_process/Eclipse_Standard_TopLevel_Charter_v1.0.php
@@ -0,0 +1,278 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Eclipse Standard Top-Level Charter v1.0";
+$pageKeywords = "project";
+$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><?= $pageTitle ?></h1>
+
+<p><i>This
+document defines standard terms for Eclipse Top Level Project Charters. It is
+intended that the Charters for Top Level Projects reference this document rather
+than inheriting by copy-and-paste.</i></p>
+
+<h2>Overview</h2>
+</b><i>To be defined in the individual Top
+Level Project Charter.</i></p>
+
+<h2>Mission</h2>
+<i>To be defined in the individual Top Level Project Charter.</i></p>
+
+<h2>Scope</h2>
+<i>To be defined in the individual Top Level Project Charter.</i></p>
+
+<h2>Project Management Committee</h2>
+</b>The Projects under this Charter are managed by a group known as the Project
+Management Committee (the "PMC").</p>
+<p>PMCs are expected to ensure that:</p>
+<ul>
+ <li>
+ All Projects operate effectively by providing leadership to guide the
+ Project's overall direction and by removing obstacles, solving problems, and
+ resolving conflicts.</p>
+ </li>
+ <li>
+ All Project plans, technical documents and reports are publicly available</p>
+ </li>
+ <li>
+ All Projects operate using open source rules of engagement: meritocracy,
+ transparency, and open participation. These principles work together. In
+ principle, anyone can participate in a Project.
+ </li>
+</ul>
+<p>The PMC has the following responsibilities:</p>
+<ul>
+ <li>Providing the leadership and vision to guide the Project's overall
+ direction in a manner consistent with the Eclipse Foundation Roadmap.</li>
+ <li>Providing assistance and support to the developers working on the Project
+ by removing obstacles, solving problems, and resolving conflicts.</li>
+ <li>Ensuring that Project plans are produced, and presenting these plans to
+ the EMO.</li>
+ <li>Working with the Eclipse Management Organization (the "EMO") to
+ establish the processes and infrastructure needed for the project teams to
+ be effective.</li>
+ <li>Recommending new Projects to the EMO.</li>
+ <li>Recommending the initial set of Project committers for each new Project
+ overseen by the PMC, and establishing the procedures consistent with this
+ Charter for voting in new committers.</li>
+ <li>Helping to ensure that the Projects overseen by the PMC have enough
+ contributors, and working to fill vacancies in roles.</li>
+ <li>Producing "how to get involved" guidelines to help new potential
+ contributors get started.</li>
+ <li>Coordinating relationships with other Eclipse Foundation Projects.</li>
+ <li>Facilitating code or other donations by individuals or companies.</li>
+ <li>Making recommendations to the Eclipse Foundation Board regarding
+ contributions proposed under licenses other than the EPL.</li>
+ <li>Working with the EMO and Committers to ensure in-bound contributions are
+ made in accordance with the Eclipse Foundation IP Policy.</li>
+ <li>Acting as a focal point for the community in representing the Projects it
+ oversees.</li>
+</ul>
+<p>The PMC Lead is appointed by the Board. The initial PMC is selected by the
+PMC Lead. Thereafter, to become a member of the PMC, an individual must be
+nominated by another member of the PMC, and unanimously approved by all PMC
+members. </p>
+<p>In the unlikely event that a member of the PMC becomes disruptive to the
+process or ceases to contribute for an extended period, the member may be
+removed by unanimous vote of remaining PMC members. PMC members may resign at
+any time by delivering notice of their resignation to the PMC Lead.</p>
+<p>The PMC is responsible for producing and maintaining the Project Charter.
+Development activities must conform to any rules or processes outlined in the
+Charter, so a change to these processes may necessitate a change to the Charter.
+Changes to the Charter are approved by the Board.</p>
+<p>The work of the PMC is shared by the PMC members. All PMC members are
+expected to contribute actively. In particular, PMC members are expected to take
+responsibility for overseeing certain areas of work in the Project, and
+reporting to the PMC on these areas. Because of the diversity amongst individual
+projects, PMC members are not expected to maintain anything other than general
+currency with projects outside their assigned technical areas.</p>
+<p>Active participation in the user newsgroups and the appropriate developer
+mailing lists is a responsibility of all PMC members, and is critical to the
+success of the Project. PMC members are required to monitor the main Project
+mailing list, and the developer mailing lists for all Projects and components
+they are overseeing.</p>
+
+<h2>Roles</h2>
+The Projects under this Charter are operated as meritocracies -- the more you
+contribute, and the higher the quality of your contribution, the more you are
+allowed to do. However with this comes increased responsibility.</span></p>
+
+<h3>Users</h3>
+</b>Users are the people who use the output from the Project. Output will
+typically consist of software in form of extensible frameworks and exemplary
+tools. Software in this context means intellectual property in electronic form,
+including source and binary code, documentation, courseware, reports and
+whitepapers. </p>
+
+<h3>Developers</h3>
+</b>Users who contribute software, documentation, or other materially useful
+content become developers. Developers are encouraged to participate in the user
+newsgroup(s), and should monitor the developer mailing list associated with
+their area of contribution. When appropriate, developers may also contribute to
+development design discussions related to their area of contribution. Developers
+are expected to be proactive in reporting problems in the bug tracking system.</p>
+
+<h3>Committers</h3>
+</b>Developers who give frequent and valuable contributions to a Project, or
+component of a Project (in the case of large Projects), can have their status
+promoted to that of a "Committer" for that Project or component
+respectively. A Committer has write access to the source code repository for the
+associated Project (or component), and gains voting rights allowing them to
+affect the future of the Project (or component).</p>
+<p>In order for a Developer to become a Committer on a particular Project
+overseen by the PMC, another Committer for the same Project (or component as
+appropriate) can nominate that Developer or the Developer can ask to be
+nominated. Once a Developer is nominated, the Committers for the Project (or
+component) will vote for a PMC-designated voting period, and that period shall
+be no less than one week. If there are at least 3 positive votes and no negative
+votes within the voting period, the Developer is recommended to the PMC for
+commit privileges. The PMC may waive the 3 vote minimum requirement in
+exceptional cases (e.g., there are fewer than 3 active committers on the
+project). If the PMC also approves, and the Developer signs the appropriate New
+Committer agreements established by the EMO (wherein, at the very least, the
+Developer agrees to abide by the Eclipse Intellectual Property Policy), the
+Developer is converted into a Committer and given write access to the source
+code and/or web repository for that Project (or component). Becoming a Committer
+is a privilege that is earned by contributing and showing discipline and good
+judgment. It is a responsibility that should be neither given nor taken lightly.</p>
+<p>At times, Committers may become inactive for a variety of reasons. The
+decision making process of the Project relies on active committers who respond
+to discussions and vote in a constructive and timely manner. The PMC is
+responsible for ensuring the smooth operation of the Project. A Committer who is
+disruptive, does not participate actively, or has been inactive for an extended
+period may have his or her commit status revoked by the PMC.</p>
+<p>Active participation in the user newsgroup and the appropriate developer
+mailing lists is a responsibility of all Committers, and is critical to the
+success of the Project. Committers are required to monitor and contribute to the
+user newsgroup.</p>
+<p>Committers are required to monitor the mailing lists associated with all
+Projects and components for which they have commit privileges. This is a
+condition of being granted commit rights to the Project or component. It is
+mandatory because committers must participate in votes (which in some cases
+require a certain minimum number of votes) and must respond to the mailing list
+in a timely fashion in order to facilitate the smooth operation of the Project.
+When a Committer is granted commit rights they will be added to the appropriate
+mailing lists. A Committer must not be unsubscribed from a developer mailing
+list unless their associated commit privileges are also revoked.</p>
+<p>Committers are required to track, participate in, and vote on, relevant
+discussions in their associated Projects and components. There are three voting
+responses: +1 (yes), -1 (no, or veto), and 0 (abstain).</p>
+<p>Committers are responsible for proactively reporting problems in the bug
+tracking system, and annotating problem reports with status information,
+explanations, clarifications, or requests for more information from the
+submitter. Committers are responsible for updating problem reports when they
+have done work related to the problem.</p>
+
+<h2>Projects</h2>
+</b>The work under this Top Level Project is further organized into Projects.
+New Projects must be consistent with the mission of the Top Level Project, be
+recommended by the PMC, and confirmed by the EMO. Projects can be discontinued
+by recommendation of the PMC, and confirmed by the EMO.</p>
+<p>When a new Project is created, the PMC nominates a Project lead to act as the
+technical leader and nominates the initial set of Committers for the Project,
+and these nominations are approved by the EMO. Project leads are accountable to
+the PMC for the success of their Project.</p>
+
+<h3>Project Organization</h3>
+</b>Given the fluid nature of Eclipse Projects, organizational changes are
+possible, in particular: dividing a Project into components; dividing a Project
+into two or more independent Projects; and merging two or more Projects into a
+single Project. In each case, the initiative for the change may come either from
+within the Project or from the PMC, but the PMC must approve any change, and
+approval must be confirmed by the EMO.</p>
+<p>If a Project wishes to divide into components, commit privileges are normally
+granted at the component level, and the committers for a given component vote on
+issues specific to that component. Components are established and discontinued
+by the PMC. When the PMC creates a component, it appoints a component lead to
+act as the technical leader and names the initial set of Committers for the
+component. The component lead is designated as a committer for the Project and
+represents the component in discussions and votes pertaining to the Project as a
+whole. Component committers do not participate in votes at the level of the
+Project as a whole, unless they are also the component lead.</p>
+<p>In cases where new Projects are being created, either by splitting or by
+merging, the usual procedures as set forth in this Charter are followed. In
+particular, developers will not necessarily have the same rights after an
+organizational change that they enjoyed in the previous structure.</p>
+
+<h2>Infrastructure</h2>
+</b>The PMC works with the EMO to ensure the required infrastructure for the
+Project. The Project infrastructure will include, at minimum:</p>
+<ul>
+ <li>Bug Database - Bugzilla database for tracking bugs and feature requests.</li>
+ <li>Source Repository -- One or more CVS repositories containing all the
+ software for the Projects.</li>
+ <li>Website - A website will contain information about the Project, including
+ documentation, reports and papers, courseware, downloads of releases, and
+ this Charter.</li>
+ <li>General Mailing List - Mailing list for discussions pertaining to the
+ Project as a whole or that cross Projects. This mailing list is open to the
+ public.</li>
+ <li>Project Mailing Lists - Mailing list for technical discussions related to
+ the Project. This mailing list is open to the public.</li>
+ <li>Component Mailing Lists - Mailing list for technical discussions related
+ to the component. This mailing list is open to the public.</li>
+ <li>Newsgroups - Newsgroups where users, developers, and committers can
+ interact regarding general questions and issues about the project. The
+ newsgroup is open to the public.</li>
+</ul>
+
+<h2>The Development Process</h2>
+</b>Each Project lead must produce a development plan for the release cycle, and
+the development plan must be approved by a majority of Committers of the
+Project. The plan must be submitted to the PMC for review. The PMC may provide
+feedback and advice on the plan but approval rests with the Project Committers.</p>
+<p>Each Project must identify, and make available on its web site, the
+requirements and prioritizations it is working against in the current release
+cycle. In addition, each Project must post a release plan showing the date and
+content of the next major release, including any major milestones, and must keep
+this plan up to date.</p>
+<p>The Committers of a Project or component decide which changes may be
+committed to the master code base of a Project or component respectively. The
+PMC defines the decision process, but that process must include the ability for
+Committers to veto the change. The decision process employed may change with the
+phase of development. Common decision processes include:</p>
+<ul>
+ <li>Retroactive - changes are proactively made by Committers but can be vetoed
+ by a single Committer. </li>
+ <li>Proactive - for efficiency, some code changes from some
+contributors (e.g. feature additions, bug fixes) may be approved in advance, or
+approved in principle based on an outline of the work, in which case they may be
+committed first and changed as needed, with conflicts resolved by majority vote
+of the Committers of the Project or component, as applicable.</li>
+ <li>Three Positive - No code is committed without a vote; three
++1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a code
+change. </li>
+</ul>
+<p> Vetoes must be followed by an explanation for the veto within 24 hours
+or the veto becomes invalid. All votes are conducted via the developer mailing
+list associated with the Project or component. Special rules may be established by the PMC for Projects or components with
+fewer than three Committers. </p>
+<p>The master copy of the code base must reside on the Project web site where it
+is accessible to all users, developers and committers. Committers must check
+their changes and new work into the master code base as promptly as possible
+(subject to any check-in voting rules that may be in effect) in order to foster
+collaboration among widely distributed groups and so that the latest work is
+always available to everyone. The PMC is responsible for working with the
+Eclipse Foundation to establish a release engineering and build process to
+ensure that builds can be reliably produced on a regular and frequent basis from
+the master code base and made available for download from the Project web site.
+Builds in this context are intended to include not only code but also reports,
+documentation, and courseware.</p>
+<p>Each Project is responsible for establishing test plans and the level of
+testing appropriate for the Project.</p>
+<p>All development technical discussions are conducted using the development
+mailing lists. If discussions are held offline, then a summary must be posted to
+the mailing list to keep the other committers, and any other interested parties,
+
+<h2>Licensing</h2>
+</b>All contributions to Projects under this Charter must adhere to the Eclipse
+Foundation Intellectual Property Policy.
+
+<?
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
diff --git a/dev_process/_projectCommon.php b/dev_process/_projectCommon.php
new file mode 100644
index 0000000..86c3fe8
--- /dev/null
+++ b/dev_process/_projectCommon.php
@@ -0,0 +1,5 @@
+<?php
+
+include("../_projectCommon.php");
+
+?>
diff --git a/dev_process/archived-phase.php b/dev_process/archived-phase.php
new file mode 100644
index 0000000..9327f4f
--- /dev/null
+++ b/dev_process/archived-phase.php
@@ -0,0 +1,50 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Archived Phase";
+$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>Archived Phase</h1>
+<p><i>version 016 - July 29, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Archived Phase</h2>
+
+<p> Projects that reach their natural conclusion, or that become inactive
+through dwindling resources, 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.</p>
+
+<p>Projects are archived as follows:</p>
+<ul>
+ <li>The project leaders write a short description of the project, its goals,
+ its accomplishments, and (if any) the remaining work.</li>
+ <li>The mailing lists, newsgroups, website, and complete CVS repository are
+ stored in an archive (a zip or tar.gz) on the eclipse.org servers.</li>
+ <li>The mailing lists are disabled but the archives are retained.</li>
+ <li>The newsgroups are removed but the archive are retained.</li>
+ <li>The CVS repository is removed.</li>
+ <li>All but the last download is removed from the website.</li>
+ <li>The project website is replaced with a single page describing the archived
+ status of the project and contain links to the archive zip and the final
+ download. The page explains that members are welcome to return the project
+ to active status - at which point the archive zip would be used to restore
+ the state.</li>
+ <li>The project is removed from the main links of its hosting PMC and placed
+ on a separate archived projects page.</li>
+</ul>
+<p>Archiving is not a value judgment of the project; rather, an archived project
+is one that has reached its natural conclusion. No project lasts forever and
+there is a natural ebb and flow to technology. Projects that are less actively
+maintained are more likely to end in the archived state, but projects that are
+highly successful also end up being archived after being absorbed into the
+mainstream of an existing top-level project.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/bugzilla-use.php b/dev_process/bugzilla-use.php
new file mode 100644
index 0000000..005c02d
--- /dev/null
+++ b/dev_process/bugzilla-use.php
@@ -0,0 +1,132 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Bugzilla Use";
+$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>Bugzilla Use</h1>
+<p><i>version 028 - November 29, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Bugzilla</h2>
+
+<p>A common question new projects ask is "how should we use Bugzilla
+effectively?". The <a href="http://www.bugzilla.org/docs/2.18/html/using.html">Bugzilla
+documentation</a> describes the basic mechanics and outlines the bug lifecycle
+that is designed into Bugzilla:</p>
+
+<p align="center"><img border="0" src="images/bzLifecycle.png" width="496" height="579"></p>
+
+<p>The Eclipse projects have different schemes for using Bugzilla, but a common one
+is as follows:</p>
+<ul>
+ <li>Users "own": component, version, platform, OS, severity,
+ summary, and description</li>
+ <li>The Committers "own": status, resolution, and priority.</li>
+ <li>Users may not change the Committer owned fields - this is enforced by
+ social convention.</li>
+ <li>Bugzilla provides a mechanism to watch another email address and
+ developers are expected to use this to watch the component owner's address
+ to monitor the incoming bugs for their projects/components.</li>
+ <li>At the start of each day, each project/component team lead does bug
+ triage. He or she assesses each NEW bug:
+ <ul>
+ <li>Validation
+ <ul>
+ <li> verify if the bug is really a bug or if it belongs to this component</li>
+ <li>if the bug needs more information to be validated as a bug, add a request for more information/steps to reproduce, etc.
+ The bug remains in the NEW state until enough information is received
+ to validate it.<sup>1</sup></li>
+ <li>if there is no response within a week, close the bug (RESOLVED
+ INVALID or WONTFIX) telling the submitter to re-open once they have
+ more info</li>
+ <li>the bug may get moved to another component/product</li>
+ <li>the bug may be a user problem, or may be intended behavior - these
+ get annotated with the reason/information and RESOLVED to INVALID or WONTFIX
+ or WORKSFORME (generally, INVALID means the report is just bogus,
+ WORKSFORME means the report is not a problem, and WONTFIX is used for things
+ that are valid requests, but that the team can't do).</li>
+ <li>once a bug is validated, it goes to prioritization</li>
+ </ul>
+ </li>
+ <li>Prioritization
+ <ul>
+ <li>If the bug is a feature request, change the severity to <i> enhancement</i></li>
+ <li>If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set
+ appropriately.<sup>2</sup></li>
+ <li>If the fix is critical, the target will be the next milestone (like 3.1M3), otherwise it will go into the general 3.1 milestone, meaning we intend to address in this release</li>
+ <li>If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER</li>
+ <li>Set the priority with these guidelines:
+ <ul>
+ <li>P1 - stop ship fix, need immediate attention</li>
+ <li>P2 - must fix before the release, but can make progress without fix</li>
+ <li>P3 - should/would like to fix for the next release</li>
+ <li>P4 - would be nice, but not critical, can ship without fixing</li>
+ </ul>
+ </li>
+ <li>The severity tags aren't used much, except to distinguish enhancements from bugs.
+ Typically the users specify severities as they see fit.</li>
+ <li>The bug will stay as ASSIGNED to the "inbox" account until a developer takes the bug, or
+ the team lead assign it to them</li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>The developers then work on the bug
+ <ul>
+ <li>When a developer fixes the bug, the status is set to RESOLVED - FIXED, and it is assigned to another committer on the team to
+ verify. It is important that the verifier be a different person than the
+ fixer because the fixer is too close to the code and thus may not be as
+ diligent at testing the corner cases.</li>
+ <li>When a developer commits code, she includes the bug#(s) in the commit
+ message.</li>
+ <li>It is possible for a bug to be RESOLVED to LATER or WONTFIX or INVALID as well if
+ the developer discovers that the fix is too complex/risky or that it is not really a bug</li>
+ </ul>
+ </li>
+ <li>Verify
+ <ul>
+ <li>All bugs should be verified before the next integration build</li>
+ <li>When a committer verifies a fix, the status is changed to VERIFIED</li>
+ </ul>
+ </li>
+ <li>When the project does a major release, the VERIFIED bugs are changed to
+ CLOSED.</li>
+</ul>
+<h3>Managing Requirements</h3>
+<p>Projects should be using Bugzilla as part of their requirements process. A
+future version of this document will describe recommended techniques for doing
+so.</p>
+<h3>Writing Good Bug Reports</h3>
+<p>There are many ways to write a good bug report and even more ways to write a
+bad one. The community suggests that these are some of the best bug reports
+submitted to date:</p>
+<ul>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=22122">22122</a> -
+ in this bug, not only is the problem accurately described, but a patch is provided to
+ <i>our</i> core test suites that tests various permutations of the failure condition.</li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=76541">76541</a> - feature request with screen
+ cast</li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=95401">95401</a></li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=97221">97211</a></li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=113206">113206</a>
+ - note the flash movie in comment #5 that illustrates the problem, complete with text overlays and pauses during the movie to illustrate the error condition.</li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=114496">114496</a></li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=116682">116682</a>
+ - describes the expected behavior and contains a patch</li>
+ <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=117181">117181</a>
+ - contains build ID and simple self-contained steps to reproduce the problem in a very short time</li>
+</ul>
+<p>We should all strive to emulate these authors when writing bug reports.</p>
+<p><sup>1</sup> Some projects move bugs that need more information to the
+RESOLVED REMIND state rather than leaving them in the inbox.<br>
+<sup>2</sup> Some projects do not set the target milestone here; instead they
+use a milestone planning meeting to set them all at once.</p>
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/bugzillacomponent.jpg b/dev_process/bugzillacomponent.jpg
new file mode 100644
index 0000000..a1d58f9
--- /dev/null
+++ b/dev_process/bugzillacomponent.jpg
Binary files differ
diff --git a/dev_process/changelog.php b/dev_process/changelog.php
new file mode 100644
index 0000000..b0dc844
--- /dev/null
+++ b/dev_process/changelog.php
@@ -0,0 +1,23 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Change Log";
+$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>Change Log</h1>
+<p><i>version 028 - November 29, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Changes</h2>
+
+<ul>
+ <li>028 (November 29, 2005): first official blessed release</li>
+</ul>
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/eclipse-quality.php b/dev_process/eclipse-quality.php
new file mode 100644
index 0000000..1260236
--- /dev/null
+++ b/dev_process/eclipse-quality.php
@@ -0,0 +1,179 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Eclipse Quality";
+$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 Quality</h1>
+<p><i>version 017 - August 6, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Eclipse Quality</h2>
+
+<p><i>Eclipse Quality</i> means extensible frameworks and exemplary tools
+developed in an open, inclusive, and predictable process involving the entire
+community. 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). From the "creation perspective," Eclipse Quality means
+working with a transparent and open process, open and welcoming to participation
+from technical leaders, regardless of affiliation.</p>
+<p><i>Eclipse Quality </i>is not a binary statement. Rather, quality is a
+spectrum and Eclipse projects are expected to, release-by-release, improve their
+quality. Eclipse Quality is an evolution over the life of the project and the
+evaluation of a project's quality must be appropriate to the project's maturity
+level. For example, a project in the <a href="validation-phase.php">Validation Phase</a> will have more Provisional APIs and fewer Platform APIs than a project
+in the <a href="implementation-phase.php">Implementation Phase</a>. Similarly, a 1.0 Release
+will have fewer API clients than a 2.0 Release; and a 3.0 Release will have a
+better release-to-release migration plan than a 2.0 Release; etc.</p>
+<p>Note the Eclipse Quality is about both extensible frameworks and exemplary tools - great tools are important for attracting the users,
+who then attract the ecosystem, that then provide members, who then contribute
+resources, who then create additional valuable frameworks and tools. Neither
+frameworks without users nor tools without frameworks are interesting points
+along the software development spectrum.</p>
+<p>Eclipse Quality goals:</p>
+<ul>
+ <li>Platform quality frameworks. (note that "Platform quality" here
+ refers to high quality <a href="http://en.wikipedia.org/wiki/API">APIs</a>
+ (such as <a href="http://openide.netbeans.org/nonav/tutorial/api-design.html#api">a
+ module API in NetBeans</a> or a <a href="http://java.sun.com/j2se/javadoc/writingapispecs/index.html">Java
+ platform API</a> or the <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_api_start_page.asp">Windows
+ API</a>) and <i>not</i> to the Eclipse Platform project).</li>
+ <li>Platform quality tools.<sup>1</sup></li>
+ <li>All exemplary tools are built on platform APIs.</li>
+ <li>Performance and scalability to enterprise class use.</li>
+ <li>Automated tests and a quality plan that can be used by any Eclipse
+ developer.<br>
+ We want any Eclipse user to be able to run all the tests and verify that
+ they have a working and correct installation of the frameworks and tools.</li>
+ <li>A release-to-release migration plan potentially including automated tools
+ for conversions. Release-to-release migration includes not only the APIs,
+ but also the artifacts generated by the tools (e.g., configuration files,
+ persisted tables, etc).</li>
+ <li>API stability.</li>
+ <li>Predictable behavior and a predictable rate of change.</li>
+ <li>Demonstrated community involvement.</li>
+ <li>IP due diligence as per the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
+ IP Policy</a> and <a href="/legal/committerguidelines.php">other</a>
+ <a href="/legal/">Eclipse</a> <a href="/org/documents/main.html">processes</a>.
+ (This is the only required Quality element, the rest are goals.)</li>
+</ul>
+<h3>APIs, Provisional or Not</h3>
+<p>In an earlier draft document, <i><a href="Eclipse%20Quality%20APIs%20v2.pdf">Eclipse
+Quality APIs</a></i>, a platform API was defined to have:</p>
+<ul>
+ <li><b>A specification.</b> A description of the cover story and the necessary
+ details. Specifications should be clear about what is defined and what is
+ not defined. Furthermore, specifications should indicate what areas are
+ likely to change in the future (e.g., this two-valued parameter will
+ probably have N-values in the future). A specification is a difficult
+ document to write, and it is more than just a paragraph or two about the
+ component.</li>
+ <li><b>A test suite.</b></li>
+ <li><b>An implementation.</b></li>
+ <li><b>One or more clients. </b>Usually, just having a client is not
+ sufficient an Eclipse quality API client is ideally developed by a
+ separate team. A client (API user) that is written by the same team that
+ also creates the API implementation usually suffers from information leakage
+ and thus is not a good test of the API. Even better is two or more clients,
+ each developed by a separate team, all of whom communicate only through the
+ API documents.</li>
+ <li><b>A support promise. </b>An implicit or explicit promise about how stable
+ the API will be from release to release.</li>
+</ul>
+<p>Note that the <a href="http://en.wikipedia.org/wiki/API">API</a> (Application
+Programming Interface) is the entire public programming surface of the
+framework, thus it includes not only Java classes, packages, and interfaces, but
+also extension points, file formats, generated meta-data, and even objects that
+are passed through to internal packages.</p>
+<p>The question arises of what to do about code that is intended to become API
+in a future release, but is not up to these standards in the current release. We
+can consider the following cases:</p>
+<div align="center">
+ <center>
+ <table border="1" cellspacing="0" cellpadding="2">
+ <tr>
+ <td> </td>
+ <td align="center"><b>Specification</b></td>
+ <td align="center"><b>Test Suite</b></td>
+ <td align="center"><b>Implementation</b></td>
+ <td align="center"><b>Clients</b></td>
+ <td align="center"><b>Support Promise</b></td>
+ <td align="center"><b>Package</b></td>
+ </tr>
+ <tr>
+ <td><b>Platform API</b></td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">public</td>
+ </tr>
+ <tr>
+ <td><b>Provisional</b></td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center"><i>not quite</i></td>
+ <td align="center">public</td>
+ </tr>
+ <tr>
+ <td><b>Incomplete</b></td>
+ <td align="center"><i>incomplete</i></td>
+ <td align="center"><i>incomplete</i></td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">public</td>
+ </tr>
+ <tr>
+ <td><b>Experimental</b></td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ <td align="center">?</td>
+ <td align="center">internal.provisional</td>
+ </tr>
+ <tr>
+ <td><b>Non-API</b></td>
+ <td align="center">-</td>
+ <td align="center">-</td>
+ <td align="center">yes</td>
+ <td align="center">-</td>
+ <td align="center">none</td>
+ <td align="center">internal</td>
+ </tr>
+ </table>
+ </center>
+</div>
+<p>Provisional, Incomplete, and Experiment APIs are collectively referred to as <i>Transient
+APIs</i>. The interesting cases are <i>Provisional</i> and <i>Incomplete</i>. Under
+this definition, Provisional API is real API in all senses (good specification,
+good Javadoc, good tests, etc) but the project does not feel that it has had
+sufficient community feedback to completely freeze the APIs yet. The <a href="/tptp"> TPTP</a>
+project uses Provisional APIs for all new API introductions: the new API is
+released as provisional in release X and then hardened into platform APIs in
+release X+1.</p>
+<p>Incomplete APIs are those where the project wrote the code before defining
+the APIs and thus the documentation and/or test suite is incomplete, but the
+project intends to support the API. Incomplete APIs may appear in milestone
+releases (although the lack of documentation will make it difficult for the
+plug-in developer community to adopt and verify those APIs), but Incomplete APIs
+must not appear in releases.</p>
+
+<hr>
+<p><sup>1</sup> Admittedly, there is not a good definition for "platform
+quality tools" yet. A future version of this document will try to clarify
+this.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/images/bzLifecycle.png b/dev_process/images/bzLifecycle.png
new file mode 100644
index 0000000..f2bf2c5
--- /dev/null
+++ b/dev_process/images/bzLifecycle.png
Binary files differ
diff --git a/dev_process/images/confidential-draft.gif b/dev_process/images/confidential-draft.gif
new file mode 100644
index 0000000..8a57d76
--- /dev/null
+++ b/dev_process/images/confidential-draft.gif
Binary files differ
diff --git a/dev_process/images/draft.gif b/dev_process/images/draft.gif
new file mode 100644
index 0000000..34dfe2a
--- /dev/null
+++ b/dev_process/images/draft.gif
Binary files differ
diff --git a/dev_process/images/guidelines-final.css b/dev_process/images/guidelines-final.css
new file mode 100644
index 0000000..69179f8
--- /dev/null
+++ b/dev_process/images/guidelines-final.css
@@ -0,0 +1,15 @@
+
+body {
+font-family: arial, helvetica, geneva; font-size: 10pt;
+clip: rect( );
+margin-top: 5mm;
+margin-left: 3mm;
+}
+
+td {
+font-family: arial, helvetica, geneva; font-size: 10pt;
+}
+
+code {
+font-size: 11pt;
+}
diff --git a/dev_process/images/guidelines.css b/dev_process/images/guidelines.css
new file mode 100644
index 0000000..0e2c197
--- /dev/null
+++ b/dev_process/images/guidelines.css
@@ -0,0 +1,17 @@
+
+body {
+font-family: arial, helvetica, geneva; font-size: 10pt;
+clip: rect( );
+margin-top: 5mm;
+margin-left: 3mm;
+background-image: url('draft.gif');
+background-repeat: repeat-y
+}
+
+td {
+font-family: arial, helvetica, geneva; font-size: 10pt;
+}
+
+code {
+font-size: 11pt;
+}
diff --git a/dev_process/images/pdf.gif b/dev_process/images/pdf.gif
new file mode 100644
index 0000000..d664fa0
--- /dev/null
+++ b/dev_process/images/pdf.gif
Binary files differ
diff --git a/dev_process/images/print_icon.gif b/dev_process/images/print_icon.gif
new file mode 100644
index 0000000..923f46c
--- /dev/null
+++ b/dev_process/images/print_icon.gif
Binary files differ
diff --git a/dev_process/implementation-phase.php b/dev_process/implementation-phase.php
new file mode 100644
index 0000000..6ce8024
--- /dev/null
+++ b/dev_process/implementation-phase.php
@@ -0,0 +1,275 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Implementation Phase";
+$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>Implementation 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>Implementation (Mature) Phase</h2>
+<p>The project has demonstrated process, community, and technology and is now a
+mature member of the Eclipse Community. </p>
+<p>During the Implementation Phase, the project and project leadership maintain the
+project's infrastructure and continue to participate in the Eclipse Community
+using these, and other, mechanisms. The more frequent are:</p>
+<ul>
+ <li><b>Status Reports.</b><br>
+ All projects are required to report their status quarterly, if not more
+ often. Currently that status report is currently done with two mechanisms,
+ although eventually these will be combined into a single XML file.
+ <ol>
+ <li>
+ Three files in the root of the project's web space:
+ <ol>
+ <li>The <a href="/projects/timeline/how-things-work.php"><b><code>.dates.txt</code></b>
+ file</a> that creates the <a href="/projects/timeline/">master
+ timeline</a>.</li>
+ <li>The <b><code>project-page-paragraph.html</code></b> file to be
+ displayed on the <a href="/projects/">master project page</a> (if
+ the project is a top-level project) or the <a href="/technology/">Technology
+ page</a> (if the project is a Technology sub-project).</li>
+ <li>The <b><code>home-page-one-liner.html</code></b> file to be
+ displayed on the Eclipse home page.</li>
+ </ol>
+ </li>
+ <li>
+ The quarterly status email. This email to the <a href="mailto:emo@eclipse.org">EMO</a>
+ contains:
+ <ul>
+ <li>
+ Project name</li>
+ <li>
+ Project leaders</li>
+ <li>
+ Product description</li>
+ <li>
+ Executive summary <i>(this is the most important
+ part)</i></li>
+ <li>
+ List of currently shipping releases</li>
+ <li>
+ URL of current planning document</li>
+ </ul>
+ </li>
+ <li>In the near future<sup>1</sup>, the quarterly status email will be
+ merged with .dates.txt file, and will be replaced by <a href="status-and-planning-reporting.php">an
+ XML file stored in each project's CVS repository</a>. Automated reminder
+ scripts will convince the project leaders to update the status file at
+ least once per quarter.</li>
+ </ol>
+ </li>
+ <li><b>Milestone Releases.</b> Interim milestone and release candidate
+ releases will be named n.nMn (e.g., 3.3M4) or n.nRCn (e.g., 4.1RC2). The n.n
+ release numbering is reserved for the final Reviewed release. Additionally,
+ all nightly, integration, milestone, release candidate, and final releases
+ will be available via a download link found on the project's home page.</li>
+ <li><b>Use the Correct Servers.</b> The eclipse.org infrastructure is solid
+ and capable, but it is also capable of being brought to its knees by poor
+ file placement. Projects will follow these guidelines:
+ <ul>
+ <li>Do not use viewcvs links in any web pages. Use normal links instead.
+ Your project's web pages are stored in CVS and can be committed via CVS,
+ but the links need to be normal links to reduce server load and enable
+ load sharing.</li>
+ <li>Do not place downloads or large files on the dev.eclipse.org
+ machine (the web pages or the CVS). Use the download.eclipse.org
+ machine for all downloads - these machines are load balanced, mirrored,
+ and have a separate bandwidth allotment.
+ <ul>
+ <li>Large files that change often should be placed on download
+ servers.</li>
+ <li>Files larger than 5Mbs should be placed on the download servers.</li>
+ <li>All zip and gzip files should be placed on the download servers.</li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li><b>Release Reviews.</b><br>
+ Each major release (where <i>major</i> is defined as any release whose N or
+ M version number changes in the N.M.P version number) must go through a <a href="release-review.php">Release
+ Review</a>. Please schedule enough time to complete the Review and any
+ potential remedial actions so as not to impact the project's release
+ schedule.</li>
+ <li><b>Continue encouraging the three communities.</b><br>
+ As the project has completed its Validation Phase, this should already be
+ happening, but I include it here for completeness. Continue
+ to use the public mailing lists, respond in the newsgroups, write articles,
+ staff code camps, triage the bugzilla, attend the Eclipse community events (<a href="http://www.eclipsecon.org/">EclipseCon</a>,
+ <a href="/org/foundation/council.php">Council meetings</a>, ...) and so on.</li>
+ <li>
+ <p align="left" style="border-style: dotted; border-width: 2; padding-left: 5; padding-right: 5; padding-top: 2; padding-bottom: 2"><b>Following the Eclipse IP Policy.<br>
+ </b>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<sup>2</sup>, 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. Maintaining a current and accurate <a href="project-log.php"> Project Log</a> is
+ the best way to keep this information up-to-date.<br>
+ The due diligence process for new contributions takes, on average, four to
+ six calendar weeks to complete. Thus we recommend limiting large and
+ third-party contributions to the beginning of a release cycle rather than
+ waiting to the end.</li>
+ <li><b>Changing eclipse.org content.</b><br>
+ The eclipse.org site has various news and announcement pages, as well as
+ pages that describe the projects and top-level PMCs. To request an
+ announcement or news or changes to these pages, send email to the <a href="mailto:emo@eclipse.org">EMO</a>.</li>
+ <li><b>Add a new Committer.</b><br>
+ After the Committer has been voted in using the top-level PMC's voting
+ process, follow the <a href="/legal/newcommitter.html">New
+ Committer Process</a>.</li>
+ <li><b>Active Progress.</b><br>
+ Project are expected to continue to be active: in development, in releases,
+ in newsgroup and mailing list responses, and in the community more
+ generally. Projects that become inactive will be reviewed and probably <a href="archived-phase.php">archived</a>.
+ </li>
+ <li><b>Use project name correctly.<br>
+ </b>Every public use of the project name - in a web page, a presentation, a
+ press release, an article, etc. - must follow the <a href="project-naming-policy.php">project
+ naming guidelines</a>:
+ <ul>
+ <li>The first use of the project name uses the entire descriptive name
+ and may include the optional nickname. For
+ example, "The Eclipse Component Assembly
+ Project (Buckminister)". Subsequent references to the project may use the
+ nickname, e.g., "Buckminister".</li>
+ <li>If the project is in <a href="proposal-phase.php">the Proposal Phase</a>
+ or the <a href="validation-phase.php">Validation Phase</a>, that fact
+ must be mentioned early in the document. For example, "The proposed
+ Eclipse Phoenix project ..." or "The Buckminister project,
+ being incubated at Eclipse, is releasing version 0.2 of their framework
+ for early alpha feedback from the community."</li>
+ </ul>
+ </li>
+ <li><b>Use brand graphics and watermarks correctly.<br>
+ </b>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 respectively) on
+ their webpage and communications. Projects in the proposal and
+ validation/incubation stages must use the appropriate watermark on their web
+ pages.</li>
+</ul>
+<p>The less frequent are:</p>
+<ul>
+ <li><b>Remove a Committer.</b><br>
+ After the Committer has been removed using the top-level PMC's process, send
+ email to the <a href="mailto:emo@eclipse.org">EMO</a> with: the name of the
+ project and hosting top-level project, the full name and email address of
+ the Committer, and the list of CVS packages to which commit accesses will be
+ removed.</li>
+ <li><b>Change a Committer's access.</b><br>
+ The logical combination of Add and Remove accomplished via email by the
+ top-level PMC to the <a href="mailto:webmaster@eclipse.org">Eclipse
+ sysadmins</a>. Soon there will be a work request tracking system instead of
+ emails, but for now emails will suffice.</li>
+ <li><b>Change access rights on download server.</b><br>
+ Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse sysadmins</a>
+ with the names of the Committers to be added/removed to/from the download
+ server.</li>
+ <li><b>Change root CVS components.</b><br>
+ Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse sysadmins</a>
+ with the list of component changes and the list of Committers for the
+ components.</li>
+ <li><b>Marking stale CVS components.</b><br>
+ As the projects evolve, some CVS modules become stale and cause confusion to
+ new comers when they are browsing the repositories. These modules cannot be
+ deleted from the repository, because they contain history and they have been
+ part of a build at one point.<br>
+ In order to limit confusion and not lose history, the HEAD of stale modules
+ should be replaced by a README file describing the status of the project.
+ This file should also contain when the development has been stopped, against
+ which version of eclipse it was working, and the CVS tag with the last
+ working copy of the code.</li>
+ <li><b>Changing Bugzilla components, milestones, targets, owners, etc.<br>
+ </b>Send email to the Eclipse sysadmins with detailed instructions. When
+ adding components, be sure to include: component name, component
+ description, initial owner. For more details, see <a href="https://dev.eclipse.org/committers/help/howdoi.php">the
+ Committer Self Service page</a>.</li>
+ <li><b>Add new newsgroup.</b><br>
+ Most projects have a single newsgroup, but in the exceptional case where an
+ additional newsgroup is required, send email to the <a href="mailto:webmaster@eclipse.org">Eclipse
+ sysadmins</a> with the newsgroup name in format eclipse.[top-level
+ project].[shortname] and the newsgroup description.</li>
+ <li><b>Add new mailing list.</b><br>
+ <a href="https://dev.eclipse.org/mailman/listinfo/">Mailing lists</a> are
+ resources used by committers to facilitate group communication. Normally, a
+ single mailing list is created for a project; however, projects with several
+ components can have several mailing lists. The main project mailing list is
+ normally called projectname-dev, and component lists are called projectname-component.
+ To add an additional mailing list, see <a href="https://dev.eclipse.org/committers/help/howdoi.php">the
+ Committer Self-Service page</a> and then send email to the <a href="Eclipse%20sysadmins">Eclipse
+ sysadmins</a> with the mailing list name, the long description (<a href="http://dev.eclipse.org/mailman/%20listinfo/platform-dev">see
+ example</a>) and the short description (<a href="/mail/">see
+ example</a>).</li>
+ <li><b>Changing a mailing list.</b><br>
+ A project can ask the <a href="Eclipse%20sysadmins">Eclipse
+ sysadmins</a> for mailing list changes (filters, digests, the sort of thing
+ that mailman can do), or the project can ask the <a href="Eclipse%20sysadmins">Eclipse
+ sysadmins</a> to provide the project lead with self-service access to the
+ list.</li>
+ <li><b>Removing a newsgroup or mailing list.<br>
+ </b>Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse
+ sysadmins</a>.</li>
+ <li><b>Other.</b><br>
+ The <a href="https://dev.eclipse.org/committers/">Committer self-service
+ page</a> provides infrastructure reports, password changes, etc.</li>
+</ul>
+<h3>Schedule</h3>
+<p>There are many things that make Eclipse great. One is that there has been a
+strong emphasis on <a href="eclipse-quality.php">quality</a>; another is the
+equally strong emphasis on predictability. Even more important than having a
+schedule is having an honest schedule, so while projects should do their best
+not to change the schedule, they should work even harder to ensure that the
+schedule in an honest one. This is especially critical for Eclipse projects
+because the projects release extensible frameworks that other Eclipse members -
+individuals and ecosystem companies - build products and tools on top of. Those
+members make plans based on the Eclipse plans and thus changing the Eclipse
+plans can materially affect a large number of downstream players.</p>
+<p>The best scheduling algorithm for this kind of "bottom of the dependency
+pile" development is to under-promise and over-deliver. Promise less and
+promise it later than the team thinks it can be delivered, then deliver more and
+deliver earlier. This is especially important in open-source because the project
+wants to allow enough time for the community to provide lots of good feedback -
+feedback that will result in a really great framework and outstanding exemplary
+tools.</p>
+<h3>Release Review</h3>
+<p>Major releases continue to go through <a href="release-review.php">Release
+Reviews</a>. A major release is defined as a change in N or M of the N.M.P
+release numbering.</p>
+<ul>
+ <li>A side note about release numbering: the Eclipse standard for release
+ numbers is that the major number (N) changes upon breaking changes to the APIs,
+ the minor number (M) changes when
+ the APIs are the same but there is substantial new function, and the
+ incremental number (P) changes
+ for fix packs. Fix packs are API compatible, i.e., no change to the APIs.<br>
+ The major number (N) may also change for significant new features without
+ having breaking API changes. For example, if framework Foo versions 4.0,
+ 4.1, 4.2, and 4.3 has been available for a couple years, the latest release
+ might have enough new significant features to justify version 5.0 even
+ though the API compatibility would indicate version 4.4.</li>
+ <li>A clarification of the interpretation of the Eclipse Development Process.
+ The Process has a loop-back from the Release Review to the
+ Validation/Incubation Phase (see figure 2 in the document). We have revised
+ that loop-back to return to the Implementation/Mature Phase, i.e., baring
+ any regression in openness, transparency, and process conformance, once a
+ project has reached the Implementation/Mature Phase, it remains there.</li>
+</ul>
+
+<hr>
+<p><sup>1</sup> This will be implemented by the end of 4Q2005.<br>
+<sup>2</sup> The threshold for "major" is somewhere less than 100
+LOC.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
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");
+?>
diff --git a/dev_process/old_provisioning/bugzillacomponent.jpg b/dev_process/old_provisioning/bugzillacomponent.jpg
new file mode 100644
index 0000000..a1d58f9
--- /dev/null
+++ b/dev_process/old_provisioning/bugzillacomponent.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/changes.html b/dev_process/old_provisioning/changes.html
new file mode 100644
index 0000000..a7f01c9
--- /dev/null
+++ b/dev_process/old_provisioning/changes.html
@@ -0,0 +1,272 @@
+<html><head>
+<link rel="stylesheet" href="../default_style.css"><title>Changes to Project Provisioning</title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
+<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
+<table border="0" cellpadding="2" cellspacing="5" height="129" width="100%">
+ <tbody><tr>
+ <td align="left" width="60%"><font class="indextop">changes to project provisioning</font><br>
+ <font class="indexsub">infrastructure for projects </font></td>
+ <td width="40%"> </td>
+ </tr>
+</tbody></table>
+<table width="100%" cellspacing="3" cellpadding="2">
+ <tr>
+ <td align="center" valign="top" colspan="2">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+</table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for projects and that are in
+ the validation or implementation phase of their project at eclipse.org. It
+ describes the process for ongoing provisioning activities such as changes
+ to committer lists and updates to Bugzilla components.<br>
+ <br>
+ In general all inquiries related to project provisioning can be sent to
+ the <a href="mailto:emo@eclipse.org">Eclipse Management Organization</a>
+ (EMO). <br>
+ </p>
+ </td> </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Eclipse project implementation phase infrastructure</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+<tr>
+ <td> <img src="implementation.jpg"></td>
+
+ <td colspan="4" width="100%">
+ <p>If you need changes to your infrastructure, you'll need to send the requests
+ to the webmaster or the EMO. <br>
+ <br>
+ The <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a> should
+ be contacted for:</p>
+ <ul>
+ <li> password reset</li>
+ <li> creating new components</li>
+ <li> changes to Bugzilla components</li>
+ <li> changes to committer component access</li>
+ <li>adding or archiving (read-only) mailing lists</li>
+ <li>adding or archiving (read-only) newsgroups</li>
+ </ul>
+ <p>The <a href="mailto:emo@eclipse.org">emo@eclipse.org</a> should be contacted
+ for: </p>
+ <ul>
+ <li> content related changes such as changes to web elements on www.eclipse.org
+ </li>
+ <li>adding new committers</li>
+ <li>removing committers</li>
+ </ul>
+ <p>When sending requests, please clearly identify the Top-Level Project
+ and Project you are working on so that requests that require PMC approval
+ or clarification can be properly routed to the correct PMC by the infrastructure
+ team. Please consult the checklist below for items required for implementing
+ provisioning changes. </p>
+ </td>
+ </tr>
+</table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Implementation phase provisioning checklist</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="1" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td width="19%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="32%"><b> Description</b></td>
+ <td width="34%"><b>Project team deliverable</b></td>
+ <td width="15%"><b>Review by</b></td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding new committers</td>
+ <td width="32%">
+ <p>Once a new committer is voted in (see<b> </b>the individual Top-Level
+ Project Charters for details about voting for new committers) the process
+ is the same as for the initial set of committers. <br>
+ </p>
+ </td>
+
+ <td width="34%">
+ <p>Email <a href="mailto:emo@eclipse.og">emo@eclipse.og</a>, along with the relevant Top-Level PMC approval,
+ the name(s) of the new committers with the following information:<br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which the committer will have update privileges</p>
+ </td>
+
+ <td width="15%">
+ <p>- voted in by relevant project committers<br>
+ - approved by PMC<br>
+ - agreements and information validated by EMO </p>
+ </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="32%">
+ <p>The EMO is responsible for ensuring that documentation is in place for
+ new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="34%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="15%"> </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Removing committers</td>
+
+ <td width="32%">Removing a committer requires the approval of the PMC.<br>
+ </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will be removed</td>
+ <td width="15%">approved by PMC and review by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access privileges on a specific component</td>
+
+ <td width="32%">A committer needs commit-access to a component, or no longer
+ needs commit-access to a component.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will change</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new component to CVS </td>
+
+ <td width="32%">CVS components, or modules, are created as subdirectories
+ in the project's CVS repository location, in the HEAD branch. Component
+ names follow the<i> org.eclipse.component.name</i> naming convention.<br>
+ <p> </p>
+ </td>
+ <td width="34%">Email to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - a list of the new components along with a list of committers who will
+ have access to which component<br>
+ - suggested formats:<br>
+ [module x] "same committers as [module y]<br>
+ or <br>
+ <i>module:userid1,iserid2,userid3,userid4...</i><br>
+ <i>module:e@mail,e@mail,e@mail<br>
+ module:Name Surname,Name Surname, Name Surname</i> </td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access rights to download.eclipse.org</td>
+
+ <td width="32%">Any access rights changes to the downloads area.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.or">webmaster@eclipse.or</a>g<br>
+ - names of committers to be granted update rights to the download site</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changes to content on www.eclipse.org</td>
+
+ <td width="32%">Newsgroup and mailing list main pages, Tools or Technology
+ top-level project pages, and other non-project specific pages</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - email requested changes to <a href="mailto:emo@eclipse.org">emo@eclipse.rog</a></td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new newsgroup</td>
+
+ <td width="32%">One newsgroup is created per project. Newsgroup names follow
+ the convention: eclipse.toplevelname.projectshortname </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - newsgroup description/invitation to participate </td>
+
+ <td width="15%">review by PMC </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new mailing list</td>
+
+ <td width="32%">Mailing lists are resources used by committers to facilitate
+ group communication. Mail posted to a mailing list is archived and searchable
+ from the website. Normally, a single mailing list is created for a project;
+ however, projects with several components can have several mailing lists.
+ The main project mailing list is normally called projectname-dev, and component
+ lists are called projectname-component. A list of mailing lists can be found
+ here: <a href="https://dev.eclipse.org/mailman/listinfo/">https://dev.eclipse.org/mailman/listinfo/</a></td>
+
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a><br>
+ - short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Archiving a newsgroup or mailing list </td>
+ <td width="32%">Newsgroup content, as well as e-mails sent to a mailing list
+ are archived and searchable from the eclipse.org website. The newsgroup
+ or mailing list becomes read-only. </td>
+ <td width="34%">- request to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a></td>
+
+ <td width="15%">review by PMC</td>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td >
+ <p><b>Send us updates to your committers list!</b><br>
+ The committer lists are used to determine the developer's voting rights
+ on eclipse.org, so please help us to keep them up to date! Information
+ includes the committer's address and contact information. Send any
+ changes or updates to the committers list, including adding new committers,
+ to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body></html>
\ No newline at end of file
diff --git a/dev_process/old_provisioning/devproc.jpg b/dev_process/old_provisioning/devproc.jpg
new file mode 100644
index 0000000..2a6f3d9
--- /dev/null
+++ b/dev_process/old_provisioning/devproc.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/implementation.jpg b/dev_process/old_provisioning/implementation.jpg
new file mode 100644
index 0000000..6593fd0
--- /dev/null
+++ b/dev_process/old_provisioning/implementation.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/index.html b/dev_process/old_provisioning/index.html
new file mode 100644
index 0000000..83be888
--- /dev/null
+++ b/dev_process/old_provisioning/index.html
@@ -0,0 +1,26 @@
+
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<title>Eclipse Foundation</title>
+</head>
+<frameset rows="48,*" frameborder=0 framespacing=0 border="0">
+ <frame name="banner" scrolling="no" noresize target="home"
+ src="../banner.html" marginwidth="0" marginheight="0" frameborder="NO">
+ <frameset cols="126,*" frameborder=0 framespacing=0 border="0">
+ <frameset rows="220, *" frameborder=0 framespacing=0 border="0">
+ <frame name="home_nav" scrolling="no" noresize target="main"
+ src="../home_nav.html" marginwidth="0" marginheight="0" frameborder="NO">
+ <frame name="nav" scrolling="no" noresize target="main"
+ src="/projects/nav.html" marginwidth="0" marginheight="0" frameborder="NO">
+ </frameset>
+ <frame name="main" marginwidth=10 marginheight=10 noresize frameborder="NO" src="main.html">
+ </frameset>
+ <noframes>
+ <body>
+ <p>This page uses frames, but your browser doesn't support them.</p>
+ </body>
+ </noframes>
+</frameset>
+</html>
diff --git a/dev_process/old_provisioning/main.html b/dev_process/old_provisioning/main.html
new file mode 100644
index 0000000..8ac42ff
--- /dev/null
+++ b/dev_process/old_provisioning/main.html
@@ -0,0 +1,163 @@
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+<title>Project Provisioning</title>
+<link rel="stylesheet" href="../default_style.css">
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table border=0 cellspacing=3 cellpadding=2 width="100%" >
+ <tr>
+ <td ALIGN=LEFT colspan="3"><font class=indextop>eclipse project
+ <br>
+ provisioning
+ </font> </td>
+ <td align=left rowspan="2" width="30%" > </td>
+ </tr>
+ <tr>
+ <td align=left width="21%"><a href="#Overview" class=jump> overview
+ of project lifecycle</a></td>
+ <td align=left width="23%"><a href="#Starting" class=jump>starting
+ a project</a></td>
+ <td align=left width="26%"><a href="#validation" class=jump>validation
+ and implementation phase</a></td>
+ </tr>
+ </table>
+<table width="100%" cellspacing=3 cellpadding=2>
+ <tr>
+ <td align="center" valign="top" colspan="2">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+ <tr>
+ <td align="left" valign="top" colspan="2" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"><a name="Overview"></a>
+ Overview of eclipseproject lifecycle</font></b></td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ <p>Eclipse has a well defined development process based on a specific project
+ lifecycle made up of <em>phases</em> and <em>reviews</em>. Each phase
+ is a period of time where work gets done. Reviews are events.<br>
+ <br>
+ Throughout the Project Provisioning documents, we refer to a "reviewer"
+ for the deliverables, that is either the Eclipse Management Organization
+ (EMO) or the Top-Level Project Management Committee (PMC). Project provisioning
+ is a cooperative and iterative process, where you'll find that your 'reviewers'
+ will help you to work your way through the details of the things you need
+ to provide (or find someone who can help you). This section is meant to
+ clarify the steps in the process and we invite you to send your feedback
+ on both the process and the description to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>.
+ <br>
+ <br>
+ The following diagram shows a high-level view of the Eclipse development
+ process. For complete details on our process, you need to read the <a href="../org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse
+ Development Process document</a>. <br>
+ </p>
+ </td> </tr>
+ <tr>
+ <td width="51%">
+ <p> </p>
+ <p align="center"><img src="devproc.jpg" width="254" height="331"><br>
+ </p>
+ </td> <br>
+ <td width="49%">
+ <p>Related Documents</p>
+ <ul>
+ <li><a href="../org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse
+ Development Process</a></li>
+ </ul>
+ <p>Proposal Phase</p>
+ <ul>
+ <li><a href="projectproposal.html">Project Proposal Provisioning</a></li>
+ </ul>
+ <p>Validation Phase</p>
+ <ul>
+ <li><a href="projectvalidation.html">Project Validation Phase Provisioning</a></li>
+ </ul>
+ <p>Implementation Phase</p>
+ <ul>
+ <li><a href="changes.html">Changes to Project Provisioning</a></li>
+ </ul>
+ </td>
+ <br>
+</tr>
+</table>
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
+
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"><a name="Starting"></a>
+ Starting an eclipse project </font></b></td>
+ </TR>
+ <tr colspan="2">
+ <td>
+ <p>The first step in establishing a new project at Eclipse is to contact
+ the <a href="mailto:emo@eclipse.org">Eclipse Management Organization</a>
+ (<b>EMO</b>), to work towards issuing a Project Declaration. Basically,
+ a declaration is a short email which is distributed to the Eclipse membership-at-large
+ stating that someone wants to start a project at Eclipse. Before a declaration
+ is sent, the EMO will want to talk about the technology areas you are
+ planning on working on, which Project Management Committee (PMC) the new
+ project would best fit in, who you think will be working on the project,
+ etc. In other words, we need to believe that the proposed project is a
+ reasonably good fit with Eclipse.</p>
+ <p>In many cases we start new projects off under the Technology Top-Level
+ Project. In some cases we decide together that it makes sense to propose
+ the creation of a new top-level project with its own PMC. Note that establishing
+ a new top-level project is a somewhat more heavy-weight operation. For
+ example, top-level projects have charters which are approved by the Board
+ of Directors.</p>
+ <p>Once the declaration has been sent, the EMO works with the proponents
+ of the project on their proposal. The length and level of detail of proposals
+ can vary, but the intent is to provide a document which will allow the
+ broad Eclipse community to get an idea of the scope and focus of the proposed
+ project. Once the document is ready, it will be put on our website on
+ the <a href="../proposals/main.php">Proposals</a> page, and a newsgroup
+ will be created for feedback. </p>
+ <p>You'll find a description of what needs to be done to launch a project
+ proposal on the <a href="projectproposal.html">Project Proposal Phase
+ Provisioning</a> page..</p>
+ <p>The proposal phase ends with a creation review, which is an evaluation of the proposal and the community feedback. The two key criteria in successfully passing the creation review are: </p>
+ <ol>
+ <li>does the project have a community of contributors and committers who are willing to work towards making this a success? <br>
+ </li>
+ <li>does the project have a technology scope and focus which will have a reasonable likelihood of success?</li>
+ </ol>
+
+ </td>
+ </tr>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"><a name="validation"></a>
+ Eclipse project validation and implementation phases</font></b></td>
+ </TR>
+ <tr colspan="2">
+ <td>
+ <p>After the creation review, the project is set up for development. The
+ CVS repositories, Bugzilla database, the developer mailing lists, etc.
+ are all set up at the beginning of the <i>validation phase</i><b>.</b>
+ It is during the validation phase the the real work of building some working
+ software starts. During this phase, the initial code contributions are
+ gathered, designs and prototypes are created and a project plan is formulated.
+ </p>
+ <p>For a description of the work that goes into setting up a project, take
+ a look at the <a href="projectvalidation.html">Project Validation Phase
+ provisioning</a> page.</p>
+ <p>For the rest of the life of the project, there are numerous administrative
+ items that the project leaders need to be aware of. The <a href="changes.html">Changes
+ to Project Provisioning</a> document has information on how and when the
+ project can set up new committers, add new components to CVS, maintain
+ their web pages, etc.</p>
+ </td>
+ </tr>
+ <tr colspan="2">
+ <td> </td>
+ </tr>
+</table>
+
+<p align="right"></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/bugzillacomponent.jpg b/dev_process/old_provisioning/old1/bugzillacomponent.jpg
new file mode 100644
index 0000000..a1d58f9
--- /dev/null
+++ b/dev_process/old_provisioning/old1/bugzillacomponent.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/old1/changes.html b/dev_process/old_provisioning/old1/changes.html
new file mode 100644
index 0000000..a4d1ae9
--- /dev/null
+++ b/dev_process/old_provisioning/old1/changes.html
@@ -0,0 +1,260 @@
+<html><head>
+<link rel="stylesheet" href="../default_style.css"><title>Changes to Project Provisioning</title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
+<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
+<table border="0" cellpadding="2" cellspacing="5" height="129" width="100%">
+ <tbody><tr>
+ <td align="left" width="60%"><font class="indextop">changes to project provisioning</font><br>
+ <font class="indexsub">infrastructure for projects </font></td>
+ <td width="40%"> </td>
+ </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for projects and that are in
+ the validation or implementation phase of their project at eclipse.org.
+ It describes the process for ongoing provisioning activities such as changes
+ to committer lists and updates to Bugzilla components.<br>
+ <br>
+ In general all inquiries related to project provisioning can be sent to the <a href="mailto:emo@eclipse.org">Eclipse Management Organization</a> (EMO). <br>
+ </p>
+ </td> </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Eclipse project implementation phase infrastructure</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+<tr>
+ <td> <img src="implementation.jpg"></td>
+
+ <td colspan="4" width="100%">
+ <p>If you need changes to your infrastructure, you'll need to send the requests
+ to the webmaster or the EMO. <br>
+ <br>
+ The <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a> should
+ be contacted for:</p>
+ <ul>
+ <li> password reset</li>
+ <li> creating new components</li>
+ <li> changes to Bugzilla components</li>
+ <li> changes to committer component access</li>
+ <li>adding or archiving (read-only) mailing lists</li>
+ <li>adding or archiving (read-only) newsgroups</li>
+ </ul>
+ <p>The <a href="mailto:emo@eclipse.org">emo@eclipse.org</a> should be contacted
+ for: </p>
+ <ul>
+ <li> content related changes such as changes to web elements on www.eclipse.org
+ </li>
+ <li>adding new committers</li>
+ <li>removing committers</li>
+ </ul>
+ <p>When sending requests, please clearly identify the Top-Level Project
+ and Project you are working on so that requests that require PMC approval
+ or clarification can be properly routed to the correct PMC by the infrastructure
+ team. Please consult the checklist below for items required for implementing
+ provisioning changes. </p>
+ </td>
+ </tr>
+</table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Implementation phase provisioning checklist</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="1" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td width="19%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="32%"><b> Description</b></td>
+ <td width="34%"><b>Project team deliverable</b></td>
+ <td width="15%"><b>Review by</b></td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding new committers</td>
+ <td width="32%">
+ <p>Once a new committer is voted in (see<b> </b>the individual Top-Level
+ Project Charters for details about voting for new committers) the process
+ is the same as for the initial set of committers. <br>
+ </p>
+ </td>
+
+ <td width="34%">
+ <p>Email <a href="mailto:emo@eclipse.og">emo@eclipse.og</a>, along with the relevant Top-Level PMC approval,
+ the name(s) of the new committers with the following information:<br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which the committer will have update privileges</p>
+ </td>
+
+ <td width="15%">
+ <p>- voted in by relevant project committers<br>
+ - approved by PMC<br>
+ - agreements and information validated by EMO </p>
+ </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="32%">
+ <p>The EMO is responsible for ensuring that documentation is in place for
+ new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="34%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="15%"> </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Removing committers</td>
+
+ <td width="32%">Removing a committer requires the approval of the PMC.<br>
+ </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will be removed</td>
+ <td width="15%">approved by PMC and review by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access privileges on a specific component</td>
+
+ <td width="32%">A committer needs commit-access to a component, or no longer
+ needs commit-access to a component.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will change</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new component to CVS </td>
+
+ <td width="32%">CVS components, or modules, are created as subdirectories
+ in the project's CVS repository location, in the HEAD branch. Component
+ names follow the<i> org.eclipse.component.name</i> naming convention.<br>
+ <p> </p>
+ </td>
+ <td width="34%">Email to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - a list of the new components along with a list of committers who will
+ have access to which component<br>
+ - suggested formats:<br>
+ [module x] "same committers as [module y]<br>
+ or <br>
+ <i>module:userid1,iserid2,userid3,userid4...</i><br>
+ <i>module:e@mail,e@mail,e@mail<br>
+ module:Name Surname,Name Surname, Name Surname</i> </td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access rights to download.eclipse.org</td>
+
+ <td width="32%">Any access rights changes to the downloads area.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.or">webmaster@eclipse.or</a>g<br>
+ - names of committers to be granted update rights to the download site</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changes to content on www.eclipse.org</td>
+
+ <td width="32%">Newsgroup and mailing list main pages, Tools or Technology
+ top-level project pages, and other non-project specific pages</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - email requested changes to <a href="mailto:emo@eclipse.org">emo@eclipse.rog</a></td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new newsgroup</td>
+
+ <td width="32%">One newsgroup is created per project. Newsgroup names follow
+ the convention: eclipse.toplevelname.projectshortname </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - newsgroup description/invitation to participate </td>
+
+ <td width="15%">review by PMC </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new mailing list</td>
+
+ <td width="32%">Mailing lists are resources used by committers to facilitate
+ group communication. Mail posted to a mailing list is archived and searchable
+ from the website. Normally, a single mailing list is created for a project;
+ however, projects with several components can have several mailing lists.
+ The main project mailing list is normally called projectname-dev, and component
+ lists are called projectname-component. A list of mailing lists can be found
+ here: <a href="https://dev.eclipse.org/mailman/listinfo/">https://dev.eclipse.org/mailman/listinfo/</a></td>
+
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a><br>
+ - short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Archiving a newsgroup or mailing list </td>
+ <td width="32%">Newsgroup content, as well as e-mails sent to a mailing list
+ are archived and searchable from the eclipse.org website. The newsgroup
+ or mailing list becomes read-only. </td>
+ <td width="34%">- request to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a></td>
+
+ <td width="15%">review by PMC</td>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td >
+ <p><b>Send us updates to your committers list!</b><br>
+ The committer lists are used to determine the developer's voting rights
+ on eclipse.org, so please help us to keep them up to date! Information
+ includes the committer's address and contact information. Send any
+ changes or updates to the committers list, including adding new committers,
+ to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body></html>
\ No newline at end of file
diff --git a/dev_process/old_provisioning/old1/devproc.jpg b/dev_process/old_provisioning/old1/devproc.jpg
new file mode 100644
index 0000000..2a6f3d9
--- /dev/null
+++ b/dev_process/old_provisioning/old1/devproc.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/old1/implementation.jpg b/dev_process/old_provisioning/old1/implementation.jpg
new file mode 100644
index 0000000..6593fd0
--- /dev/null
+++ b/dev_process/old_provisioning/old1/implementation.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/old1/main.html b/dev_process/old_provisioning/old1/main.html
new file mode 100644
index 0000000..88529f4
--- /dev/null
+++ b/dev_process/old_provisioning/old1/main.html
@@ -0,0 +1,155 @@
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+<title>Project Provisioning</title>
+<link rel="stylesheet" href="../default_style.css">
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table border=0 cellspacing=3 cellpadding=2 width="100%" >
+ <tr>
+ <td ALIGN=LEFT colspan="3"><font class=indextop>eclipse project
+ <br>
+ provisioning
+ </font> </td>
+ <td align=left rowspan="2" width="30%" > </td>
+ </tr>
+ <tr>
+ <td align=left width="21%"><a href="#Overview" class=jump> overview
+ of project lifecycle</a></td>
+ <td align=left width="23%"><a href="#Starting" class=jump>starting
+ a project</a></td>
+ <td align=left width="26%"><a href="#validation" class=jump>validation
+ and implementation phase</a></td>
+ </tr>
+ </table>
+<table width="100%" cellspacing=3 cellpadding=2>
+ <tr>
+ <td align="left" valign="top" colspan="2" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"><a name="Overview"></a>
+ Overview of eclipseproject lifecycle</font></b></td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ <p>Eclipse has a well defined development process based on a specific project
+ lifecycle made up of <em>phases</em> and <em>reviews</em>. Each phase
+ is a period of time where work gets done. Reviews are events.<br>
+ <br>
+ Throughout the Project Provisioning documents, we refer to a "reviewer"
+ for the deliverables, that is either the Eclipse Management Organization
+ (EMO) or the Top-Level Project Management Committee (PMC). Project provisioning
+ is a cooperative and iterative process, where you'll find that your 'reviewers'
+ will help you to work your way through the details of the things you need
+ to provide (or find someone who can help you). This section is meant to
+ clarify the steps in the process and we invite you to send your feedback
+ on both the process and the description to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>.
+ <br>
+ <br>
+ The following diagram shows a high-level view of the Eclipse development
+ process. For complete details on our process, you need to read the <a href="../org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse
+ Development Process document</a>. <br>
+ </p>
+ </td> </tr>
+ <tr>
+ <td width="51%">
+ <p> </p>
+ <p align="center"><img src="devproc.jpg" width="254" height="331"><br>
+ </p>
+ </td> <br>
+ <td width="49%">
+ <p>Related Documents</p>
+ <ul>
+ <li><a href="../org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse
+ Development Process</a></li>
+ </ul>
+ <p>Proposal Phase</p>
+ <ul>
+ <li><a href="projectproposal.html">Project Proposal Provisioning</a></li>
+ </ul>
+ <p>Validation Phase</p>
+ <ul>
+ <li><a href="projectvalidation.html">Project Validation Phase Provisioning</a></li>
+ </ul>
+ <p>Implementation Phase</p>
+ <ul>
+ <li><a href="changes.html">Changes to Project Provisioning</a></li>
+ </ul>
+ </td>
+ <br>
+</tr>
+</table>
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
+
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"><a name="Starting"></a>
+ Starting an eclipse project </font></b></td>
+ </TR>
+ <tr colspan="2">
+ <td>
+ <p>The first step in establishing a new project at Eclipse is to contact
+ the <a href="mailto:emo@eclipse.org">Eclipse Management Organization</a>
+ (<b>EMO</b>), to work towards issuing a Project Declaration. Basically,
+ a declaration is a short email which is distributed to the Eclipse membership-at-large
+ stating that someone wants to start a project at Eclipse. Before a declaration
+ is sent, the EMO will want to talk about the technology areas you are
+ planning on working on, which Project Management Committee (PMC) the new
+ project would best fit in, who you think will be working on the project,
+ etc. In other words, we need to believe that the proposed project is a
+ reasonably good fit with Eclipse.</p>
+ <p>In many cases we start new projects off under the Technology Top-Level
+ Project. In some cases we decide together that it makes sense to propose
+ the creation of a new top-level project with its own PMC. Note that establishing
+ a new top-level project is a somewhat more heavy-weight operation. For
+ example, top-level projects have charters which are approved by the Board
+ of Directors.</p>
+ <p>Once the declaration has been sent, the EMO works with the proponents
+ of the project on their proposal. The length and level of detail of proposals
+ can vary, but the intent is to provide a document which will allow the
+ broad Eclipse community to get an idea of the scope and focus of the proposed
+ project. Once the document is ready, it will be put on our website on
+ the <a href="../proposals/main.html">Proposals</a> page, and a newsgroup
+ will be created for feedback. </p>
+ <p>You'll find a description of what needs to be done to launch a project
+ proposal on the <a href="projectproposal.html">Project Proposal Phase
+ Provisioning</a> page..</p>
+ <p>The proposal phase ends with a creation review, which is an evaluation of the proposal and the community feedback. The two key criteria in successfully passing the creation review are: </p>
+ <ol>
+ <li>does the project have a community of contributors and committers who are willing to work towards making this a success? <br>
+ </li>
+ <li>does the project have a technology scope and focus which will have a reasonable likelihood of success?</li>
+ </ol>
+
+ </td>
+ </tr>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF"><a name="validation"></a>
+ Eclipse project validation and implementation phases</font></b></td>
+ </TR>
+ <tr colspan="2">
+ <td>
+ <p>After the creation review, the project is set up for development. The
+ CVS repositories, Bugzilla database, the developer mailing lists, etc.
+ are all set up at the beginning of the <i>validation phase</i><b>.</b>
+ It is during the validation phase the the real work of building some working
+ software starts. During this phase, the initial code contributions are
+ gathered, designs and prototypes are created and a project plan is formulated.
+ </p>
+ <p>For a description of the work that goes into setting up a project, take
+ a look at the <a href="projectvalidation.html">Project Validation Phase
+ provisioning</a> page.</p>
+ <p>For the rest of the life of the project, there are numerous administrative
+ items that the project leaders need to be aware of. The <a href="changes.html">Changes
+ to Project Provisioning</a> document has information on how and when the
+ project can set up new committers, add new components to CVS, maintain
+ their web pages, etc.</p>
+ </td>
+ </tr>
+ <tr colspan="2">
+ <td> </td>
+ </tr>
+</table>
+
+<p align="right"></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/projectimplementation.html b/dev_process/old_provisioning/old1/projectimplementation.html
new file mode 100644
index 0000000..370adb9
--- /dev/null
+++ b/dev_process/old_provisioning/old1/projectimplementation.html
@@ -0,0 +1,260 @@
+<html><head>
+<link rel="stylesheet" href="../default_style.css"><title>Project Implementation Phase Provisioning</title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
+<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
+<table border="0" cellpadding="2" cellspacing="5" height="129" width="100%">
+ <tbody><tr>
+ <td align="left" width="60%"><font class="indextop">project implementation phase
+ provisioning</font><br>
+ <font class="indexsub">infrastructure for projects </font></td>
+ <td width="40%"> </td>
+ </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for projects and that are in
+ the validation or implementation phase of their project at eclipse.org.
+ It describes the process for ongoing provisioning activities such as changes
+ to committer lists and updates to Bugzilla components.<br>
+ <br>
+ In general all inquiries related to project provisioning can be sent to the <a href="mailto:emo@eclipse.org">Eclipse Management Organization</a> (EMO). <br>
+ </p>
+ </td> </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Eclipse project implementation phase infrastructure</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+<tr>
+ <td> <img src="implementation.jpg"></td>
+
+ <td colspan="4" width="100%">
+ <p>If you need changes to your infrastructure, you'll need to send the requests
+ to the webmaster or the EMO. <br>
+ <br>
+ The <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a> should
+ be contacted for:</p>
+ <ul>
+ <li> password reset</li>
+ <li> creating new components</li>
+ <li> changes to Bugzilla components</li>
+ <li> changes to committer component access</li>
+ <li>adding or archiving (read-only) mailing lists</li>
+ <li>adding or archiving (read-only) newsgroups</li>
+ </ul>
+ <p>The <a href="mailto:emo@eclipse.org">emo@eclipse.org</a> should be contacted
+ for: </p>
+ <ul>
+ <li> content related changes such as changes to web elements on www.eclipse.org
+ </li>
+ <li>adding new committers</li>
+ <li>removing committers</li>
+ </ul>
+ <p>When sending requests, please clearly identify the PMC and project you
+ are working on so that requests that require PMC approval or clarification
+ can be properly routed to the correct PMC by the infrastructure team.
+ Please consult the checklist below for items required for implementing
+ provisioning changes. </p>
+ </td>
+ </tr>
+</table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Implementation phase provisioning checklist</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="1" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td width="19%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="32%"><b> Description</b></td>
+ <td width="34%"><b>Project team deliverable</b></td>
+ <td width="15%"><b>Review by</b></td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding new committers</td>
+ <td width="32%">
+ <p>Once a new committer is voted in (see<b> </b>the individual Top-Level
+ Project Charters for details about voting for new committers) the process
+ is the same as for the initial set of committers. <br>
+ </p>
+ </td>
+
+ <td width="34%">
+ <p>Email <a href="mailto:emo@eclipse.og">emo@eclipse.og</a>, along with the relevant Top-Level PMC approval,
+ the name(s) of the new committers with the following information:<br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which the committer will have update privileges</p>
+ </td>
+
+ <td width="15%">
+ <p>- voted in by relevant project committers<br>
+ - approved by PMC<br>
+ - agreements and information validated by EMO </p>
+ </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="32%">
+ <p>The EMO is responsible for ensuring that documentation is in place for
+ new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="34%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="15%"> </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Removing committers</td>
+
+ <td width="32%">Removing a committer requires the approval of the PMC.<br>
+ </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will be removed</td>
+ <td width="15%">approved by PMC and review by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access privileges on a specific component</td>
+
+ <td width="32%">A committer needs commit-access to a component, or no longer
+ needs commit-access to a component.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will change</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new component to CVS </td>
+
+ <td width="32%">CVS components, or modules, are created as subdirectories
+ in the project's CVS repository location, in the HEAD branch. Component
+ names follow the<i> org.eclipse.component.name</i> naming convention.<br>
+ <p> </p>
+ </td>
+ <td width="34%">Email to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - a list of the new components along with a list of which committers have
+ access to which components <br>
+ - the following format is preferred:<br>
+ <i>module:userid1,iserid2,userid3,userid4...</i><br>
+ - You may also use the formats: <br>
+ <i>module:e@mail,e@mail,e@mail<br>
+ module:Name Surname,Name Surname, Name Surname</i> </td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access rights to download.eclipse.org</td>
+
+ <td width="32%">Any access rights changes to the downloads area.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.or">webmaster@eclipse.or</a>g<br>
+ - names of committers to be granted update rights to the download site</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changes to content on www.eclipse.org</td>
+
+ <td width="32%">Newsgroup and mailing list main pages, Tools or Technology
+ top-level project pages, and other non-project specific pages</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - email requested changes to <a href="mailto:emo@eclipse.org">emo@eclipse.rog</a></td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new newsgroup</td>
+
+ <td width="32%">One newsgroup is created per project. Newsgroup names follow
+ the convention: eclipse.toplevelname.projectshortname </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - newsgroup description/invitation to participate </td>
+
+ <td width="15%">review by PMC </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new mailing list</td>
+
+ <td width="32%">Mailing lists are resources used by committers to facilitate
+ group communication. Mail posted to a mailing list is archived and searchable
+ from the website. Normally, a single mailing list is created for a project;
+ however, projects with several components can have several mailing lists.
+ The main project mailing list is normally called projectname-dev, and component
+ lists are called projectname-component. A list of mailing lists can be found
+ here: <a href="https://dev.eclipse.org/mailman/listinfo/">https://dev.eclipse.org/mailman/listinfo/</a></td>
+
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a><br>
+ - short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Archiving a newsgroup or mailing list </td>
+ <td width="32%">Newsgroup content, as well as e-mails sent to a mailing list
+ are archived and searchable from the eclipse.org website. The newsgroup
+ or mailing list becomes read-only. </td>
+ <td width="34%">- request to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a></td>
+
+ <td width="15%">review by PMC</td>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td >
+ <p><b>Send us updates to your committers list!</b><br>
+ The committer lists are used to determine the developer's voting rights
+ on eclipse.org, so please help us to keep them up to date! Information
+ includes the committer's address and contact information. Send any
+ changes or updates to the committers list, including adding new committers,
+ to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body></html>
\ No newline at end of file
diff --git a/dev_process/old_provisioning/old1/projectproposal.html b/dev_process/old_provisioning/old1/projectproposal.html
new file mode 100644
index 0000000..7719cc2
--- /dev/null
+++ b/dev_process/old_provisioning/old1/projectproposal.html
@@ -0,0 +1,207 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Project Proposal Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>project proposal provisioning</font><br>
+ <font class=indexsub>project proposal provisioning </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for Project Proposals (proposals
+ for new projects within an existing Top-Level Project) at eclipse.org. The <a href="toplevelproposal.html">Top-Level
+ Project Proposal Provisioning</a> document describes the process for projects
+ that propose a new PMC. These documents follow the Eclipse Project Lifecyle
+ as described in the <a href="../org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> . <br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse project proposal review infrastructure</font></b></td>
+ </TR>
+ <tr>
+ <td> <img src="proposal.jpg" width="180" height="310"></td>
+ <td>
+ <p>When a declaration is made to the EMO, the initiating individual works
+ with a PMC to create a proposal which begins the proposal phase. See the
+ <a href="main.html">Project Provisioning</a> document and review archives
+ of previous successful proposals on the <a href="../proposals/main.html">Proposals</a>
+ page for more details about this process. During the proposal phase the
+ project is provisioned with two items:<br>
+ <br>
+ 1 - a website in the proposals directory on eclipse.org, and <br>
+ 2 - a <a href="#newsgroups">newsgroup</a> to open discussions. <br>
+ <br>
+ Please consult the <a href="#checklist">checklist</a> below for items
+ required to create the proposal website and the newsgroup. Each of the
+ deliverables can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>.
+ <br>
+ <br>
+ At the end of the Proposal Phase is the <a href="#creationreview">Creation
+ Review</a>. During the proposal phase you may consider an <a href="#pr">Announcment
+ Press Release</a>, or you may decide to do the release after the Creation
+ Review and as part of the launch of the <a href="projectvalidation.html">Project
+ Validation</a> phase. <br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Proposal newsgroups</font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td colspan "4"> In this phase, the newsgroup is created last for several
+ reasons. Many newsreaders actively inform their users of the existance of
+ a new newsgroup so when we first created all the infrastructure in a single
+ big bang, the project leaders didn't have enough time to populate the main
+ web page of the proposal before it was "pre-announced" by the
+ newsreader software. We now wait for the main web page to be complete before
+ the newsgroups are created. We then post an initial message, inviting people
+ to visit the newly created project page to learn more about the project.
+ <br>
+</td>
+</tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="pr"></a>Announcement press release </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The press release is optional. The release could be issued by Eclipse,
+ or it could be a joint release with the project's stakeholders, and includes
+ Q&A's, messages and preparation of the stakeholder spokespeople. The
+ discipline of creating a press release ensures that all stakeholders have
+ agreed on messages, positioning and have identified spokepersons.<br>
+ <br>
+ If you do decide to issue a press release, the Eclipse Foundation Marketing
+ Director can help you coordinate the announcement. (Email the <a href="mailto:emo@eclipse.org">EMO</a>
+ for further information.)<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="creationreview"></a>Creation review </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The creation review is scheduled roughly one to two months after the
+ proposal is made public to ensure sufficient time to receive and respond
+ to feedback received from the community. The creation review meeting will
+ include the proposed project lead, members of the hosting Top-Level Project
+ PMC and staff of the Eclipse Foundation. The review format is teleconference,
+ and is open to the eclipse membership at large (but not the general public).
+ Notifications of creation review meetings are sent to the eclipse membership
+ mailing list by the EMO. <br>
+ <br>
+ The two key criteria in successfully passing the creation review are:
+ <ol>
+ <li>does the project have a community of contributors and committers who
+ are willing to work towards making this a success? <br>
+ </li>
+ <li>does the project have a technology scope and focus which will have
+ a reasonable likelihood of success</li>
+ </ol>
+ <p> Although the creation review is a relatively informal meeting, the proposed
+ project leads will be expected to make a brief presentation to the review
+ committee. The presentation should include a brief summary of the project
+ proposal, in addition to comments about the community response to the
+ proposal, current project participants, initial implementation focus and
+ future directions. The presentation slides will be posted to the proposal
+ site before the review. You can view previous sucessful creation review
+ slide presentations in the <a href="../proposals/main.html">Proposal Archives</a>.
+ <br>
+ <br>
+ Upon a successful review the PMC will recommend creation of the project
+ for the EMO's final approval.
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Project proposal provisioning checklist </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="21%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="23%"><b> Description</b></td>
+ <td width="43%"><b>Project team deliverable</b></td>
+ <td width="13%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="21%" >Proposal published on static web pages </td>
+ <td width="23%">pages published in eclipse.org/proposals directory, linked
+ from projects main page</td>
+ <td width="43%">-HTML documents (where possible) <br>
+ - in this stage no access is granted to the static webpages, therefore an
+ approved draft for posting should be delivered 48 hours before launch date.
+ The project team then has a one-day cycle to review the proposal as it will
+ be published. </td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Short Name</td>
+ <td width="23%">The name for the proposal subdirectory on which the newsgroup,
+ mailing list, and CVS addresses will be based </td>
+ <td width="43%">- a 3-6 character short name or acronym for the project title
+ </td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Description</td>
+ <td width="23%">a brief description of the project (1 paragraph) for the top-level
+ project home page</td>
+ <td width="43%">- one paragraph description of the proposal</td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup</td>
+ <td width="23%">the initial newsgroup for soliciting feedback on the proposal</td>
+ <td width="43%">- confirmation of newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - the newsgroup is the last item to be released on launch day<br>
+ - the preparation cycle is 3-6 hours, therefore a confirmed name 24 hours
+ before the launch is preferred. </td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup description </td>
+ <td width="23%">3 line newsgroup description that appears on the <a href="../newsgroups/index.html" target="_top">Newsgroups
+ main page </a></td>
+ <td width="43%">- newsgroup description/invitation to participate</td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+
+</table>
+
+<p></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/projectvalidation-old.html b/dev_process/old_provisioning/old1/projectvalidation-old.html
new file mode 100644
index 0000000..69f1afa
--- /dev/null
+++ b/dev_process/old_provisioning/old1/projectvalidation-old.html
@@ -0,0 +1,439 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Project Validation Phase Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<style>
+body {
+background-image: url('../images/archive.gif');
+background-repeat: repeat-y
+}
+</style>
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>project validation phase provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><br><font size="+1">
+ Please use the <a href="/org/processes/project_validation_provisioning_request.html">new
+ combination web-form & document</a>.</font>
+ </p>
+ <p>
+ This document describes the infrastructure for projects that have completed
+ a successful Creation Review and are beginning the Validation Phase of
+ their project (under an existing Top-Level Project) at eclipse.org. The <a href="toplevelvalidation.html">Top-Level
+ Project Validation Phase Provisioning</a> document describes the process
+ for projects that propose a new PMC. These documents follow the Eclipse
+ Project Lifecyle as described in the <a href="../org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> .<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse project validation phase infrastructure</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td> <img src="validation.jpg" width="180" height="310"></td>
+
+ <td colspan="4" width="100%">
+ <p>After a successful Creation Review, the project enters the Validation
+ Phase and additional infrastructure is created to support the initial
+ work on the project:</p>
+ <ul>
+ <li>CVS commit rights</li>
+ <li> CVS component structure</li>
+ <li>download site </li>
+ <li>a developer mailing list and</li>
+ <li> the project website<br></li>
+ </ul>
+ Please consult the <a href="#checklist">checklist</a> below for items
+ required to implement this core infrastructure. Each of the deliverables
+ can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ The project is 'created' in two steps:
+ <ol>
+ <li>CVS, user accounts, mailing-list, master home page (links to your
+ page in the <a href="#web">website CVS</a>), <a href="#downloadspace">download
+ space</a> on download.eclipse.org, and bugzilla </li>
+ <li> Developer mailing lists, hosting Top-Level Project main page and any additional
+ <a href="#newsgroups">newsgroups</a> are then connected to your project
+ making it "live".</li>
+ </ol>
+ <p> This ensures that all the core infrastructure is ready and that the
+ data and an initial project structure are in place, before the project
+ goes 'live". <br>
+ <br>
+ Ongoing <a href="#changes">changes</a> to the project's core infrastructure
+ are expected especially during the Validation Phase, as the project matures.
+ Please consult the <a href="changes.html">Project Implementation Phase
+ Provisioning</a> document for pointers on how to implement these changes.
+ <br>
+ </p>
+ </td>
+</tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Project newsgroup</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p>At this stage, the proposal newsgroup can be repositioned as the project
+ newsgroup, or the team can archive the existing newsgroup (so it becomes
+ read-only) and start a new project newsgroup. <br><br>
+ </p>
+ </td>
+</tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ </font><a name="web"></a><font face="Arial,Helvetica" color="#FFFFFF">Project
+ website</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p>Each project has a web presense on www.eclipse.org. The content for a
+ project web pages is stored in a separate CVS repository on dev.eclipse.org.
+ The repository is automatically checked out to www.eclipse.org, and thereby
+ enables website authors to use HTML and PHP to author websites directly
+ on www.eclipse.org, does not require viewcvs, and paves the way for an
+ eventual MySQL database backend. Only those committers designated by their
+ project PMC will be granted update rights to the project website CVS.
+ As a bootstrap mechanism, the PMC will have committer access to assist
+ with web maintenance.<br>
+ <br>
+ A directory of the form <b>www.eclipse.org/[shortname]</b> will be created
+ by the webmaster for each new project. This also becomes the url for the
+ project home page. A default index.html page containing the required frames
+ is created in the website CVS repository. </p>
+ <p>Here's how it works:</p>
+ <p>1 - In Eclipse, create a new CVS Repository location:</p>
+ <blockquote>
+ <blockquote>
+ <p><b>Server</b>: dev.eclipse.org<br>
+ <b>Path</b>: /home/cvs/org.eclipse<br>
+ <b>Username/Password</b>: your committer credentials are also used
+ for website authoring<br>
+ <b>Website url</b>: www.eclipse.org/[shortname]</p>
+ </blockquote>
+ </blockquote>
+ <p>2 - Checkout the "www" project, and you will see the project directories.
+ Each of these directories has a single index.html file that sets up the
+ frames and opens up main.html.<br>
+ <br>
+ 3 - It may take up to one minute to transfer committed content to www.eclipse.org
+ but essentially committed changes are live.</p>
+ <p>There are some images which you may use in your web pages. These can
+ be viewed at www.eclipse.org/images/.
+ </p>
+ <p>The Tools and Technology Top-Level Projects have modelled the following
+ conventions for project websites. </p>
+ <table width="75%" border="1">
+ <tr>
+ <td>
+ <div align="center"><b>Filename</b></div>
+ </td>
+ <td>
+ <div align="center"><b>Purpose</b></div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/main.html</div>
+ </td>
+ <td>
+ <div align="center">the content for the main project page </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/faq.html</div>
+ </td>
+ <td>
+ <div align="center">the project faq page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/download.html</div>
+ </td>
+ <td>
+ <div align="center">the project downloads page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/plan.html</div>
+ </td>
+ <td>
+ <div align="center">the project plan page</div>
+ </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="downloadspace"></a><font face="Arial,Helvetica" color="#FFFFFF">Builds
+ and downloads</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p><b>Builds </b><br>
+ The project leads are responsible for builds and maintenance on eclipse.org.
+ The frequency of these is dependent on the project needs. For more information
+ see: </p>
+ <blockquote>
+ <p>Eclipse project development - <a href="http://www.eclipse.org/eclipse/development/main.html">http://www.eclipse.org/eclipse/development/main.html</a><br>
+ Platform release engineering - <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html">http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html</a></p>
+ </blockquote>
+ <b>Downloads </b><br>
+ The project lead and their appointed committers will receive an account
+ and password on download1.eclipse.org which is a high-bandwidth download
+ server. For projects under the Tools Top-Level Project, for example, the directory will
+ be /home/www/tools/xyz. For mirroring purposes, however, the link to download
+ a file is http://www.eclipse.org/downloads/download.php?file=/tools/xyz/fileName.
+ This will allow mirror site selection based on the file requested. We ask
+ that you not link directly to "download.eclipse.org" or "download1.eclipse.org"
+ <p>Because the downloads space is mirrored to several servers worldwide,
+ we ask you use this space wisely, taking extra care when placing large
+ files in this space, and performing regular file cleanups. Large directories
+ use bandwidth while mirroring and deter new mirror sites because of high
+ disk space requirements. Also, HTML and PHP files must not be placed on
+ the download server.</p>
+ <p>Uploads to this space are via SFTP (preferred) or FTP. Use any SFTP client,
+ such as CoreFTP, to connect to download1.eclipse.org. Although you are
+ connecting to download1.eclipse.org, links to files must be done to download.eclipse.org.
+ <br>
+ <br>
+ RSYNC transfers can be arranged. Please consult the <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a>
+ for details on setting this up.</p>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="changes"></a><font face="Arial,Helvetica" color="#FFFFFF">Changes
+ </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><b> For more information see the <a href="changes.html">Project Implementation
+ Phase Provisioning</a> document. <br>
+ <br>
+ Getting changes to your infrastructure</b></p>
+ <p>If you need changes to your infrastructure, you need to send an email
+ to webmaster@eclipse.org or to the emo@eclipse.org. In general things
+ like password reset and creating new components are taken care of by the
+ webmaster. Other content related changes such as changes to web elements
+ on www.eclipse.org should be sent to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>.
+ When sending requests, please clearly identify the Top-Level Project and
+ Project you are working on so that requests that require PMC approval
+ or clarification can be properly routed to the correct PMC by the infrastructure
+ team.</p>
+ <p><b>Changes to your committers list</b><br>
+ Changes to the committers list, including adding new committers, is done
+ through <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>. We also
+ track the committer's address and contact information. We use these lists
+ to determine the developer's voting rights on eclipse.org, so please help
+ us to keep them up to date! For more information see the <a href="changes.html">Project
+ Implementation Phase Provisioning</a> document. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Project validation phase provisioning checklist
+ </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="11%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="43%"><b> Description</b></td>
+ <td width="33%"><b>Project team deliverable</b></td>
+ <td width="13%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="11%" >Committers list</td>
+ <td width="43%">
+ <p>A list of the initial committers for the project.<br>
+ </p>
+ </td>
+
+ <td width="33%">A list of the initial committers with the following information:<br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - if available, the list of CVS components or modules to which the committer
+ will have update privileges</td>
+ <td width="13%">- nominated by PMC <br>
+ - approved by EMO </td>
+ </tr>
+ <tr>
+
+ <td width="11%" >Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="43%">
+ <p>The EMO is responsible for ensuring that documentation is in place for
+ new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="33%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="13%"> </td>
+ </tr>
+ <tr>
+ <td width="11%" >List of initial CVS components or modules</td>
+
+ <td width="43%">
+ <p>Typical components are:<br>
+ org.eclipse.[shortname].[component]<br>
+ </p>
+ </td>
+
+ <td width="33%">- a list of components along with a list of committers who
+ will have access to each component<br>
+ </td>
+ <td width="13%">review by PMC and EMO</td>
+ </tr>
+ <tr>
+
+ <td width="11%" >Project website moves to website CVS</td>
+
+ <td width="43%">- <i><a href="#web">See Website section above</a></i> <br>
+ - the project receives a website address on www.eclipse.org in the format
+ www.eclipse.org/[shortname]/<br>
+ -the website content is checked into the corresponding repository by
+ the project committers <br>
+ Note: Only those committers designated by their project PMC will be
+ granted update rights to the project website CVS. As a bootstrap mechanism,
+ the PMC will have committer access to assist with web maintenance.<br>
+ </td>
+
+ <td width="33%">- a list of which committers have access to the website CVS<br>
+ - the new committers can coordinate the release of their new site with the
+ release of links from the hosting top-level project pages, newsgroups and
+ mailing list pages, etc. </td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Project description</td>
+ <td width="43%">the project description is modified on the top-level project
+ main page to reflect change in status</td>
+ <td width="33%">- any requested edits to the project description</td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Proposal archived</td>
+
+ <td width="43%">the successful proposal is archived in the proposal archive</td>
+
+ <td width="33%"> </td>
+ <td width="13%">- none</td>
+ </tr>
+ <tr>
+ <td width="11%" >Newsgroup link on newsgroups page </td>
+
+ <td width="43%">the <a href="#newsgroups">newsgroup</a> is moved from a standalone
+ position on the page to the appropriate Top-Level Project</td>
+ <td width="33%">- any requested edits to the newsgroup description</td>
+
+ <td width="13%">review by PMC </td>
+ </tr>
+ <tr>
+ <td width="11%" >Mailing list name </td>
+ <td width="43%">- typical mailing list names are in the form [shortname]-dev@eclipse.org
+ <br>
+ - when multiple components are developed independently, component lists
+ are created in the form [shortname]-[component] -dev@eclipse.org</td>
+ <td width="33%">- confirmation of list name and/or component list names</td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Mailing list short description</td>
+ <td width="43%">- the short description appears on the mailing list main page</td>
+ <td width="33%">- short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Mailing list long description </td>
+ <td width="43%">- the long description appears on the introductory page to
+ the individual mailing list </td>
+ <td width="33%">- long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a></td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="11%" >Download directory</td>
+
+ <td width="43%">
+ <p>- the project lead will submit the names of one or two committers
+ per project who will receive an account and password on download1.eclipse.org<br>
+ - <i><a href="#downloadspace">see Builds and Downloads above</a></i></p>
+ </td>
+
+ <td width="33%">- names of committers to be granted update rights to the download
+ site </td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Bugzilla </td>
+ <td width="43%">- Bugzilla product is created with sublisting for each component
+ and component milestone eg. <br>
+ <img src="bugzillacomponent.jpg" width="355" height="113"> <br>
+ </td>
+ <td width="33%">- initial list of components, milestones, and component owners</td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/projectvalidation.html b/dev_process/old_provisioning/old1/projectvalidation.html
new file mode 100644
index 0000000..d4d0c6e
--- /dev/null
+++ b/dev_process/old_provisioning/old1/projectvalidation.html
@@ -0,0 +1,29 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Project Validation Phase Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>project validation phase provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><br><font size="+1">
+ Please use the <a href="/org/processes/project_validation_provisioning_request.html">new
+ combination web-form & document</a>.</font>
+ </p>
+ <p>The <a href="projectvalidation-old.html">old version</a> of this
+ document is still available from the archives.
+ </p>
+ </td> </tr>
+</table>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/proposal.jpg b/dev_process/old_provisioning/old1/proposal.jpg
new file mode 100644
index 0000000..b021e32
--- /dev/null
+++ b/dev_process/old_provisioning/old1/proposal.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/old1/toplevelproposal.html b/dev_process/old_provisioning/old1/toplevelproposal.html
new file mode 100644
index 0000000..1a0a87e
--- /dev/null
+++ b/dev_process/old_provisioning/old1/toplevelproposal.html
@@ -0,0 +1,205 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Top-Level Project Proposal Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>top-level project proposal
+ provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for Top-Level Project proposals
+ (projects that propose a new PMC) at eclipse.org. The <a href="projectproposal.html">Project
+ Proposal Provisioning</a> document describes the infrastructure for new
+ projects under an existing Top-Level Project. These documents follow the
+ Eclipse Project Lifecyle as described in the <a href="../org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> .<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse top-level project proposal review infrastructure</font></b></td>
+ </TR>
+ <tr>
+ <td> <img src="proposal.jpg"></td>
+ <td> When a declaration is made to the EMO, the initiating individual works
+ with a PMC to create a proposal which begins the proposal phase. See the
+ <a href="main.html">Project Provisioning</a> document and review archives
+ of previous successful proposals on the <a href="../proposals/main.html">Proposals</a>
+ page for more details about this process. During the proposal phase the
+ project is provisioned with two items:<br>
+ <br>
+ 1 - a website in the proposals directory on eclipse.org, and <br>
+ 2 - a <a href="#newsgroups">newsgroup</a> to open discussions. <br>
+ <br>
+ Please consult the <a href="#checklist">checklist</a> below for items required
+ to create the proposal website and the newsgroup. Each of the deliverables
+ can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ At the end of the Proposal Phase is the <a href="#creationreview">Creation
+ Review</a>. During the proposal phase you may consider an <a href="#pr">Announcment
+ Press Release</a>, or you may decide to do the release after the Creation
+ Review and as part of the launch of the <a href="toplevelvalidation.html">Top-Level
+ Project Validation</a> phase. <br>
+ </td> </tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Proposal newsgroups </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td colspan "4"> In this phase, the newsgroup is created last for several
+ reasons. Many newsreaders actively inform their users of the existance of
+ a new newsgroup so when we first created all the infrastructure in a single
+ big bang, the project leaders didn't have enough time to populate the main
+ web page of the proposal before it was "pre-announced" by the
+ newsreader software. We now wait for the main web page to be complete before
+ the newsgroups are created. We then post an initial message, inviting people
+ to visit the newly created project page to learn more about the project.
+ <br>
+</td>
+</tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="pr"></a>Announcement press release </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The press release is optional. The release could be issued by the Foundation,
+ or it could be a joint release with the project's stakeholders, and includes
+ Q&A's, messages and preparation of the stakeholder spokespeople. The
+ discipline of creating a press release ensures that all stakeholders have
+ agreed on messages, positioning and have identified spokepersons.<br>
+ <br>
+ If you do decide to issue a press release, the Eclipse Foundation Marketing
+ Director can help you coordinate the announcement. (Email the <a href="mailto:emo@eclipse.org">EMO</a>
+ for further information.)<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="creationreview"></a>Creation review </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The creation review is scheduled roughly one to two months after the
+ proposal is made public to ensure sufficient time to receive and respond
+ to feedback received from the community. The creation review meeting will
+ include members of the proposed Top-Level Project PMC, representatives
+ from the existing eclipse PMCs and the Eclipse Foundation. The review
+ format is teleconference, and is open to the eclipse membership at large.
+ Notifications of creation review meetings are sent to the eclipse membership
+ mailing list by the EMO. <br>
+ <br>
+ The two key criteria in successfully passing the creation review are:
+ <ol>
+ <li>does the project have a community of contributors and committers who
+ are willing to work towards making this a success? <br>
+ </li>
+ <li>does the project have a technology scope and focus which will have
+ a reasonable likelihood of success</li>
+ </ol>
+ <p> Although the creation review is a relatively informal meeting, the proposed
+ top-level PMC lead will be expected to make a brief presentation to the
+ review committee. The presentation should include a brief summary of the
+ project proposal, in addition to comments about the community response
+ to the proposal, current project participants, initial implementation
+ focus and future directions. The presentation slides will be posted to
+ the proposal site before the review. You can view previous sucessful creation
+ review slide presentations in the <a href="../proposals/main.html">Proposal
+ Archives</a>. <br>
+ <br>
+ Upon a successful review the EMO will recommend creation of the project
+ for the Eclipse Foundation Board of Director's final approval.
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Top-Level project proposal provisioning checklist
+ </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="21%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="23%"><b> Description</b></td>
+ <td width="43%"><b>Project team deliverable</b></td>
+ <td width="13%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="21%" >Proposal published on static web pages </td>
+ <td width="23%">pages published in eclipse.org/proposals directory, linked
+ from proposals main page</td>
+ <td width="43%">-HTML documents (where possible) <br>
+ - in this stage no access is granted to the static webpages, therefore an
+ approved draft for posting should be delivered 48 hours before launch date.
+ The project team then has a one-day cycle to review the proposal as it will
+ be published. </td>
+ <td width="13%">EMO</td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Short Name</td>
+ <td width="23%">The name for the proposal subdirectory on which the newsgroup,
+ mailing list, and CVS addresses will be based </td>
+ <td width="43%">- a 3-6 character short name or acronym for the project title
+ </td>
+ <td width="13%">EMO </td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Description</td>
+ <td width="23%">a brief description of the project (1 paragraph) for the proposals
+ page </td>
+ <td width="43%">- a one paragraph description of the proposed project</td>
+ <td width="13%">EMO </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup</td>
+ <td width="23%">the initial newsgroup for soliciting feedback on the proposal</td>
+ <td width="43%">- confirmation of newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - the newsgroup is the last item to be released on launch day<br>
+ - the preparation cycle is 3-6 hours, therefore a confirmed name 24 hours
+ before the launch is preferred. </td>
+ <td width="13%">EMO </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup description </td>
+ <td width="23%">3 line newsgroup description that appears on the <a href="../newsgroups/index.html" target="_top">Newsgroups
+ main page </a></td>
+ <td width="43%">- newsgroup description/invitation to participate</td>
+ <td width="13%">EMO</td>
+ </tr>
+
+</table>
+
+
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/toplevelvalidation.html b/dev_process/old_provisioning/old1/toplevelvalidation.html
new file mode 100644
index 0000000..74a31c6
--- /dev/null
+++ b/dev_process/old_provisioning/old1/toplevelvalidation.html
@@ -0,0 +1,431 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Top-Level Project Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="67%"><font class=indextop>top-level project validation
+ phase provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="33%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for new Top-Level Projects
+ (projects that propose a new PMC) that have completed a sucessful creation
+ review and are beginning the validation phase of their project at eclipse.org.
+ The <a href="projectvalidation.html">Project Validation Phase Provisioning</a>
+ document describes the infrastructure for new projects under an existing
+ Top-Level Project. These documents follow the Eclipse Project Lifecyle as described
+ in the <a href="../org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> .<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse Top-Level project validation phase infrastructure</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td> <img src="validation.jpg" width="180" height="310"></td>
+ <td width="100%">
+ <p>After a successful Creation Review, the project enters the Validation
+ Phase and additional infrastructure is created to support the initial
+ work on the project:</p>
+ <ul>
+ <li>CVS commit rights</li>
+ <li> CVS component structure</li>
+ <li>download site </li>
+ <li>a developer mailing list and</li>
+ <li> the project website<br>
+ </li>
+ </ul>
+ Please consult the <a href="#checklist">checklist</a> below for items
+ required to implement this core infrastructure. Each of the deliverables
+ can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>.
+ <p>The project is 'created' in two steps: </p>
+ <ol>
+ <li>CVS, user accounts, mailing-list, master home page (links to your
+ page in the <a href="#web">website CVS</a>), <a href="#downloadspace">download
+ space</a> on download.eclipse.org, and bugzilla </li>
+ <li> Developer mailing lists, hosting Top-Level Project main page and any additional
+ <a href="#newsgroups">newsgroups</a> are then connected to your
+ project making it "live".</li>
+ </ol>
+
+ <p> This ensures that all the core infrastructure is ready and that the
+ data and an initial project structure are in place, before the project
+ goes 'live". <br>
+ <br>
+ Ongoing <a href="#changes">changes</a> to the project's core infrastructure
+ are expected especially during the Validation Phase, as the project matures.
+ Please consult the <a href="changes.html">Project Implementation Phase
+ Provisioning</a> document for pointers on how to implement these changes.
+ </p>
+ </td> </tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Project newsgroup</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p>At this stage, the proposal newsgroup can be repositioned as the project
+ newsgroup, or the team can archive the existing newsgroup (so it becomes
+ read-only) and start a new project newsgroup. <br><br>
+ </p>
+ </td>
+</tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ </font><a name="web"></a><font face="Arial,Helvetica" color="#FFFFFF">Project
+ website</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p>Each project has a web presense on www.eclipse.org. The content for
+ a project web pages is stored in a separate CVS repository on dev.eclipse.org.
+ The repository is automatically checked out to www.eclipse.org, and
+ thereby enables website authors to use HTML and PHP to author websites
+ directly on www.eclipse.org, does not require viewcvs, and paves the
+ way for an eventual MySQL database backend. Only those committers
+ designated by their project PMC will be granted update rights to the
+ project website CVS. As a bootstrap mechanism, the PMC will have committer
+ access to assist with web maintenance.<br>
+ <br>
+ A directory of the form <b>www.eclipse.org/[shortname]</b> will be
+ created by the webmaster for each new project. This also becomes the
+ url for the project home page. A default index.html page containing
+ the required frames is created in the website CVS repository. </p>
+ <p>Here's how it works:</p>
+ <p>1 - In Eclipse, create a new CVS Repository location:</p>
+ <blockquote>
+ <blockquote>
+ <p><b>Server</b>: dev.eclipse.org<br>
+ <b>Path</b>: /home/cvs/org.eclipse<br>
+ <b>Username/Password</b>: your committer credentials are also used
+ for website authoring<br>
+ <b>Website url</b>: www.eclipse.org/[shortname]</p>
+ </blockquote>
+ </blockquote>
+ <p>2 - Checkout the "www" project, and you will see the project directories.
+ Each of these directories has a single index.html file that sets up
+ the frames and opens up main.html.<br>
+ <br>
+ 3 - It may take up to one minute to transfer committed content to
+ www.eclipse.org but essentially committed changes are live.</p>
+
+ <p>There are some images which you may use in your web pages. These can
+ be viewed at www.eclipse.org/images. </p>
+
+ <p>The Tools and Technology Top-Level Projects have modelled the following
+ conventions for project websites. </p>
+ <table width="75%" border="1">
+ <tr>
+ <td>
+ <div align="center"><b>Filename</b></div>
+ </td>
+ <td>
+ <div align="center"><b>Purpose</b></div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/main.html</div>
+ </td>
+ <td>
+ <div align="center">the content for the main project page </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/faq.html</div>
+ </td>
+ <td>
+ <div align="center">the project faq page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/download.html</div>
+ </td>
+ <td>
+ <div align="center">the project downloads page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/plan.html</div>
+ </td>
+ <td>
+ <div align="center">the project plan page</div>
+ </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="downloadspace"></a><font face="Arial,Helvetica" color="#FFFFFF">Builds
+ and downloads</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p><b>Builds </b><br>
+ The project leads are responsible for builds and maintenance on eclipse.org.
+ The frequency of these is dependent on the project needs. For more information
+ see: </p>
+ <blockquote>
+ <p>Eclipse project development - <a href="http://www.eclipse.org/eclipse/development/main.html">http://www.eclipse.org/eclipse/development/main.html</a><br>
+ Platform release engineering - <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html">http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html</a></p>
+ </blockquote>
+ <b>Downloads </b><br>
+ The project lead and their appointed committers will receive an account
+ and password on download1.eclipse.org which is a high-bandwidth download
+ server. For projects under the Tools Top-Level Project, for example, the directory will
+ be /home/www/tools/xyz. For mirroring purposes, however, the link to download
+ a file is http://www.eclipse.org/downloads/download.php?file=/tools/xyz/fileName.
+ This will allow mirror site selection based on the file requested. We ask
+ that you not link directly to "download.eclipse.org" or "download1.eclipse.org"
+ <p>Because the downloads space is mirrored to several servers worldwide,
+ we ask you use this space wisely, taking extra care when placing large
+ files in this space, and performing regular file cleanups. Large directories
+ use bandwidth while mirroring and deter new mirror sites because of high
+ disk space requirements. Also, HTML and PHP files must not be placed on
+ the download server.</p>
+ <p>Uploads to this space are via SFTP (preferred) or FTP. Use any SFTP client,
+ such as CoreFTP, to connect to download1.eclipse.org. Although you are
+ connecting to download1.eclipse.org, links to files must be done to download.eclipse.org.
+ <br>
+ <br>
+ RSYNC transfers can be arranged. Please consult the <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a>
+ for details on setting this up.</p>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="changes"></a><font face="Arial,Helvetica" color="#FFFFFF">Changes
+ </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><b> For more information see the <a href="changes.html">Project Implementation
+ Phase Provisioning</a> document. <br>
+ <br>
+ Getting changes to your infrastructure</b></p>
+ <p>If you need changes to your infrastructure, you need to send an email
+ to webmaster@eclipse.org or to the emo@eclipse.org. In general things
+ like password reset and creating new components are taken care of by the
+ webmaster. Other content related changes such as changes to web elements
+ on www.eclipse.org should be sent to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>.
+ When sending requests, please clearly identify the Top-Level Project and
+ Project you are working on so that requests that require PMC approval
+ or clarification can be properly routed to the correct PMC by the infrastructure
+ team.</p>
+ <p><b>Changes to your committers list</b><br>
+ Changes to the committers list, including adding new committers, is done
+ through <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>. We also
+ track the committer's address and contact information. We use these lists
+ to determine the developer's voting rights on eclipse.org, so please help
+ us to keep them up to date! For more information see the <a href="changes.html">Project
+ Implementation Phase Provisioning</a> document. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Top-Level project validation phase provisioning
+ checklist</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="16%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="38%"><b> Description</b></td>
+ <td width="32%"><b>Project team deliverable</b></td>
+ <td width="14%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="16%" >Committers list</td>
+ <td width="38%">
+ <p>A list of the initial committers for the project.<br>
+ </p>
+ </td>
+ <td width="32%">A list of the initial committers with the following information:<br>
+ - name of the project and new top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - if available, the list of CVS components or modules to which the committer
+ will have update privileges</td>
+ <td width="14%">- nominated by PMC <br>
+ - approved by EMO </td>
+ </tr>
+ <tr>
+
+ <td width="16%" >Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="38%">
+ <p>The EMO is responsible for ensuring that documentation is in place
+ for new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="32%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="14%"> </td>
+ </tr>
+ <tr>
+ <td width="16%" >List of initial CVS components</td>
+
+ <td width="38%">Typical components are:<br>
+ org.eclipse.[shortname].[component]<br>
+ <p> </p>
+ </td>
+
+ <td width="32%">- a list of components along with a list of committers who
+ will have access to each component<br>
+ <br>
+ </td>
+
+ <td width="14%">submitted by PMC and reviewed by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="16%" >Project website moves to website CVS</td>
+
+ <td width="38%">- <i><a href="#web">See Website section above</a></i> <br>
+ - the project receives a website address on www.eclipse.org in the format
+ www.eclipse.org/[shortname]/<br>
+ -the website content is checked into the corresponding repository by
+ the project committers <br>
+ Note: Only those committers designated by their project PMC will be
+ granted update rights to the project website CVS. As a bootstrap mechanism,
+ the PMC will have committer access to assist with web maintenance.<br>
+ </td>
+
+ <td width="32%">- a list of which committers have access to the website CVS<br>
+ - the new committers can coordinate the release of their new site with the
+ release of links from the project main page, newsgroups and mailing list
+ pages, etc. </td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Project description</td>
+
+ <td width="38%">the project description is modified on the project main page
+ (www.eclipse.org/projects/index.html) to reflect change in status</td>
+ <td width="32%">- any requested edits to the project description</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Proposal archived</td>
+
+ <td width="38%">the successful proposal is archived in the proposal archive</td>
+ <td width="32%">- none</td>
+
+ <td width="14%"> </td>
+ </tr>
+ <tr>
+ <td width="16%" >Newsgroup link on newsgroups page </td>
+
+ <td width="38%">the <a href="#newsgroups">newsgroup</a> is moved from a standalone
+ position on the page a new top-level project section </td>
+ <td width="32%">- any requested edits to the newsgroup description</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Mailing list name </td>
+ <td width="38%">- typical mailing list names are in the form [shortname]-dev@eclipse.org
+ <br>
+ - when multiple components are developed independently, component lists
+ are created in the form [shortname]-[component] -dev@eclipse.org</td>
+ <td width="32%">- confirmation of list name and/or component list names</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Mailing list short description</td>
+ <td width="38%">- the short description appears on the mailing list main page</td>
+ <td width="32%">- short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Mailing list long description </td>
+ <td width="38%">- the long description appears on the introductory page to
+ the individual mailing list </td>
+ <td width="32%">- long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a></td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="16%" >Download directory</td>
+
+ <td width="38%">
+ <p>- the project lead will submit the names of one or two committers
+ per project who will receive an account and password on download1.eclipse.org<br>
+ - <i><a href="#downloadspace">see Downloads above</a></i></p>
+ </td>
+ <td width="32%">- names of committers to be granted update rights to the
+ download site </td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Bugzilla </td>
+ <td width="38%">- Bugzilla product is created with sublisting for each component
+ and component milestone eg. <br>
+ <img src="bugzillacomponent.jpg" width="355" height="113"> <br>
+ </td>
+ <td width="32%">- initial list of components, milestones and component
+ owners</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/old1/validation.jpg b/dev_process/old_provisioning/old1/validation.jpg
new file mode 100644
index 0000000..f9e1161
--- /dev/null
+++ b/dev_process/old_provisioning/old1/validation.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/projectimplementation.html b/dev_process/old_provisioning/projectimplementation.html
new file mode 100644
index 0000000..a27a74e
--- /dev/null
+++ b/dev_process/old_provisioning/projectimplementation.html
@@ -0,0 +1,269 @@
+<html><head>
+<link rel="stylesheet" href="../default_style.css"><title>Project Implementation Phase Provisioning</title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
+<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
+<table border="0" cellpadding="2" cellspacing="5" height="129" width="100%">
+ <tbody><tr>
+ <td align="left" width="60%"><font class="indextop">project implementation phase
+ provisioning</font><br>
+ <font class="indexsub">infrastructure for projects </font></td>
+ <td width="40%"> </td>
+ </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody>
+ <tr>
+ <td align="center" valign="top">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for projects and that are in
+ the validation or implementation phase of their project at eclipse.org.
+ It describes the process for ongoing provisioning activities such as changes
+ to committer lists and updates to Bugzilla components.<br>
+ <br>
+ In general all inquiries related to project provisioning can be sent to the <a href="mailto:emo@eclipse.org">Eclipse Management Organization</a> (EMO). <br>
+ </p>
+ </td> </tr>
+</tbody></table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Eclipse project implementation phase infrastructure</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+<tr>
+ <td> <img src="implementation.jpg"></td>
+
+ <td colspan="4" width="100%">
+ <p>If you need changes to your infrastructure, you'll need to send the requests
+ to the webmaster or the EMO. <br>
+ <br>
+ The <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a> should
+ be contacted for:</p>
+ <ul>
+ <li> password reset</li>
+ <li> creating new components</li>
+ <li> changes to Bugzilla components</li>
+ <li> changes to committer component access</li>
+ <li>adding or archiving (read-only) mailing lists</li>
+ <li>adding or archiving (read-only) newsgroups</li>
+ </ul>
+ <p>The <a href="mailto:emo@eclipse.org">emo@eclipse.org</a> should be contacted
+ for: </p>
+ <ul>
+ <li> content related changes such as changes to web elements on www.eclipse.org
+ </li>
+ <li>adding new committers</li>
+ <li>removing committers</li>
+ </ul>
+ <p>When sending requests, please clearly identify the PMC and project you
+ are working on so that requests that require PMC approval or clarification
+ can be properly routed to the correct PMC by the infrastructure team.
+ Please consult the checklist below for items required for implementing
+ provisioning changes. </p>
+ </td>
+ </tr>
+</table>
+<table align="center" cellpadding="3" cellspacing="0" width="100%">
+ <tbody><tr bgcolor="#999999">
+
+ <td align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">
+ Implementation phase provisioning checklist</font></b></td>
+ </tr>
+ </tbody>
+</table>
+<table align="top" border="1" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td width="19%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="32%"><b> Description</b></td>
+ <td width="34%"><b>Project team deliverable</b></td>
+ <td width="15%"><b>Review by</b></td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding new committers</td>
+ <td width="32%">
+ <p>Once a new committer is voted in (see<b> </b>the individual Top-Level
+ Project Charters for details about voting for new committers) the process
+ is the same as for the initial set of committers. <br>
+ </p>
+ </td>
+
+ <td width="34%">
+ <p>Email <a href="mailto:emo@eclipse.og">emo@eclipse.og</a>, along with the relevant Top-Level PMC approval,
+ the name(s) of the new committers with the following information:<br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which the committer will have update privileges</p>
+ </td>
+
+ <td width="15%">
+ <p>- voted in by relevant project committers<br>
+ - approved by PMC<br>
+ - agreements and information validated by EMO </p>
+ </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="32%">
+ <p>The EMO is responsible for ensuring that documentation is in place for
+ new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="34%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="15%"> </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Removing committers</td>
+
+ <td width="32%">Removing a committer requires the approval of the PMC.<br>
+ </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will be removed</td>
+ <td width="15%">approved by PMC and review by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access privileges on a specific component</td>
+
+ <td width="32%">A committer needs commit-access to a component, or no longer
+ needs commit-access to a component.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - the list of CVS packages to which commit accesses will change</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new component to CVS </td>
+
+ <td width="32%">CVS components, or modules, are created as subdirectories
+ in the project's CVS repository location, in the HEAD branch. Component
+ names follow the<i> org.eclipse.component.name</i> naming convention.<br>
+ <p> </p>
+ </td>
+ <td width="34%">Email to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - a list of the new components along with a list of which committers have
+ access to which components <br>
+ - the following format is preferred:<br>
+ <i>module:userid1,iserid2,userid3,userid4...</i><br>
+ - You may also use the formats: <br>
+ <i>module:e@mail,e@mail,e@mail<br>
+ module:Name Surname,Name Surname, Name Surname</i> </td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changing access rights to download.eclipse.org</td>
+
+ <td width="32%">Any access rights changes to the downloads area.</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.or">webmaster@eclipse.or</a>g<br>
+ - names of committers to be granted update rights to the download site</td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Changes to content on www.eclipse.org</td>
+
+ <td width="32%">Newsgroup and mailing list main pages, Tools or Technology
+ top-level project pages, and other non-project specific pages</td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - email requested changes to <a href="mailto:emo@eclipse.org">emo@eclipse.rog</a></td>
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new newsgroup</td>
+
+ <td width="32%">One newsgroup is created per project. Newsgroup names follow
+ the convention: eclipse.toplevelname.projectshortname </td>
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - newsgroup description/invitation to participate </td>
+
+ <td width="15%">review by PMC </td>
+ </tr>
+ <tr>
+
+ <td width="19%">Adding a new mailing list</td>
+
+ <td width="32%">Mailing lists are resources used by committers to facilitate
+ group communication. Mail posted to a mailing list is archived and searchable
+ from the website. Normally, a single mailing list is created for a project;
+ however, projects with several components can have several mailing lists.
+ The main project mailing list is normally called projectname-dev, and component
+ lists are called projectname-component. A list of mailing lists can be found
+ here: <a href="https://dev.eclipse.org/mailman/listinfo/">https://dev.eclipse.org/mailman/listinfo/</a></td>
+
+ <td width="34%">Email the following information, along with the relevant Top-Level
+ PMC approval to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a><br>
+ - long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a><br>
+ - short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="15%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="19%">Archiving a newsgroup or mailing list </td>
+ <td width="32%">Newsgroup content, as well as e-mails sent to a mailing list
+ are archived and searchable from the eclipse.org website. The newsgroup
+ or mailing list becomes read-only. </td>
+ <td width="34%">- request to <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a></td>
+
+ <td width="15%">review by PMC</td>
+</table>
+<table align="top" border="0" cellpadding="3" cellspacing="0" width="100%">
+ <tr>
+ <td >
+ <p><b>Send us updates to your committers list!</b><br>
+ The committer lists are used to determine the developer's voting rights
+ on eclipse.org, so please help us to keep them up to date! Information
+ includes the committer's address and contact information. Send any
+ changes or updates to the committers list, including adding new committers,
+ to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body></html>
\ No newline at end of file
diff --git a/dev_process/old_provisioning/projectproposal.html b/dev_process/old_provisioning/projectproposal.html
new file mode 100644
index 0000000..f50226a
--- /dev/null
+++ b/dev_process/old_provisioning/projectproposal.html
@@ -0,0 +1,194 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Project Proposal Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>project proposal provisioning</font><br>
+ <font class=indexsub>project proposal provisioning </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td align="center" valign="top">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for Project Proposals (proposals
+ for new projects within an existing Top-Level Project) at eclipse.org. The <a href="toplevelproposal.html">Top-Level
+ Project Proposal Provisioning</a> document describes the process for projects
+ that propose a new PMC. These documents follow the Eclipse Project Lifecyle
+ as described in the <a href="../org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> . <br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse project proposal review infrastructure</font></b></td>
+ </TR>
+ <tr>
+ <td> <img src="proposal.jpg" width="180" height="310"></td>
+ <td>
+ <p>When a declaration is made to the EMO, the initiating individual works
+ with a PMC to create a proposal which begins the proposal phase. See the
+ <a href="main.html">Project Provisioning</a> document and review archives
+ of previous successful proposals on the <a href="../proposals/main.php">Proposals</a>
+ page for more details about this process. During the proposal phase the
+ project is provisioned with two items:<br>
+ <br>
+ 1 - a website in the proposals directory on eclipse.org, and <br>
+ 2 - a <a href="#newsgroups">newsgroup</a> to open discussions. <br>
+ <br>
+ Please consult the <a href="#checklist">checklist</a> below for items
+ required to create the proposal website and the newsgroup. Each of the
+ deliverables can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>.
+ <br>
+ <br>
+ At the end of the Proposal Phase is the <a href="#creationreview">Creation
+ Review</a>. During the proposal phase you may consider an <a href="#pr">Announcment
+ Press Release</a>, or you may decide to do the release after the Creation
+ Review and as part of the launch of the <a href="projectvalidation.html">Project
+ Validation</a> phase. <br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Proposal newsgroups</font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td colspan "4"> In this phase, the newsgroup is created last for several
+ reasons. Many newsreaders actively inform their users of the existance of
+ a new newsgroup so when we first created all the infrastructure in a single
+ big bang, the project leaders didn't have enough time to populate the main
+ web page of the proposal before it was "pre-announced" by the
+ newsreader software. We now wait for the main web page to be complete before
+ the newsgroups are created. We then post an initial message, inviting people
+ to visit the newly created project page to learn more about the project.
+ <br>
+</td>
+</tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="creationreview"></a>Creation review </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The creation review is scheduled roughly one to two months after the
+ proposal is made public to ensure sufficient time to receive and respond
+ to feedback received from the community. The creation review meeting will
+ include the proposed project lead, members of the hosting Top-Level Project
+ PMC and staff of the Eclipse Foundation. The review format is teleconference,
+ and is open to the eclipse membership at large (but not the general public).
+ Notifications of creation review meetings are sent to the eclipse membership
+ mailing list by the EMO. <br>
+ <br>
+ The two key criteria in successfully passing the creation review are:
+ <ol>
+ <li>does the project have a community of contributors and committers who
+ are willing to work towards making this a success? <br>
+ </li>
+ <li>does the project have a technology scope and focus which will have
+ a reasonable likelihood of success</li>
+ </ol>
+ <p> Although the creation review is a relatively informal meeting, the proposed
+ project leads will be expected to make a brief presentation to the review
+ committee. The presentation should include a brief summary of the project
+ proposal, in addition to comments about the community response to the
+ proposal, current project participants, initial implementation focus and
+ future directions. The presentation slides will be posted to the proposal
+ site before the review. You can view previous sucessful creation review
+ slide presentations in the <a href="../proposals/main.html">Proposal Archives</a>.
+ <br>
+ <br>
+ Upon a successful review the PMC will recommend creation of the project
+ for the EMO's final approval.
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Project proposal provisioning checklist </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="21%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="23%"><b> Description</b></td>
+ <td width="43%"><b>Project team deliverable</b></td>
+ <td width="13%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="21%" >Proposal published on static web pages </td>
+ <td width="23%">pages published in eclipse.org/proposals directory, linked
+ from projects main page</td>
+ <td width="43%">-HTML documents (where possible) <br>
+ - in this stage no access is granted to the static webpages, therefore an
+ approved draft for posting should be delivered 48 hours before launch date.
+ The project team then has a one-day cycle to review the proposal as it will
+ be published. </td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Short Name</td>
+ <td width="23%">The name for the proposal subdirectory on which the newsgroup,
+ mailing list, and CVS addresses will be based </td>
+ <td width="43%">- a 3-6 character short name or acronym for the project title
+ </td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Description</td>
+ <td width="23%">a brief description of the project (1 paragraph) for the top-level
+ project home page</td>
+ <td width="43%">- one paragraph description of the proposal</td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup</td>
+ <td width="23%">the initial newsgroup for soliciting feedback on the proposal</td>
+ <td width="43%">- confirmation of newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - the newsgroup is the last item to be released on launch day<br>
+ - the preparation cycle is 3-6 hours, therefore a confirmed name 24 hours
+ before the launch is preferred. </td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup description </td>
+ <td width="23%">3 line newsgroup description that appears on the <a href="../newsgroups/index.html" target="_top">Newsgroups
+ main page </a></td>
+ <td width="43%">- newsgroup description/invitation to participate</td>
+ <td width="13%">EMO and PMC </td>
+ </tr>
+
+</table>
+
+<p></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/projectvalidation-old.html b/dev_process/old_provisioning/projectvalidation-old.html
new file mode 100644
index 0000000..f763b26
--- /dev/null
+++ b/dev_process/old_provisioning/projectvalidation-old.html
@@ -0,0 +1,447 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Project Validation Phase Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<style>
+body {
+background-image: url('../images/archive.gif');
+background-repeat: repeat-y
+}
+</style>
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>project validation phase provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td align="center" valign="top">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p><br><font size="+1">
+ Please use the <a href="/org/processes/project_validation_provisioning_request.html">new
+ combination web-form & document</a>.</font>
+ </p>
+ <p>
+ This document describes the infrastructure for projects that have completed
+ a successful Creation Review and are beginning the Validation Phase of
+ their project (under an existing Top-Level Project) at eclipse.org. The <a href="toplevelvalidation.html">Top-Level
+ Project Validation Phase Provisioning</a> document describes the process
+ for projects that propose a new PMC. These documents follow the Eclipse
+ Project Lifecyle as described in the <a href="../org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> .<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse project validation phase infrastructure</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td> <img src="validation.jpg" width="180" height="310"></td>
+
+ <td colspan="4" width="100%">
+ <p>After a successful Creation Review, the project enters the Validation
+ Phase and additional infrastructure is created to support the initial
+ work on the project:</p>
+ <ul>
+ <li>CVS commit rights</li>
+ <li> CVS component structure</li>
+ <li>download site </li>
+ <li>a developer mailing list and</li>
+ <li> the project website<br></li>
+ </ul>
+ Please consult the <a href="#checklist">checklist</a> below for items
+ required to implement this core infrastructure. Each of the deliverables
+ can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ The project is 'created' in two steps:
+ <ol>
+ <li>CVS, user accounts, mailing-list, master home page (links to your
+ page in the <a href="#web">website CVS</a>), <a href="#downloadspace">download
+ space</a> on download.eclipse.org, and bugzilla </li>
+ <li> Developer mailing lists, hosting Top-Level Project main page and any additional
+ <a href="#newsgroups">newsgroups</a> are then connected to your project
+ making it "live".</li>
+ </ol>
+ <p> This ensures that all the core infrastructure is ready and that the
+ data and an initial project structure are in place, before the project
+ goes 'live". <br>
+ <br>
+ Ongoing <a href="#changes">changes</a> to the project's core infrastructure
+ are expected especially during the Validation Phase, as the project matures.
+ Please consult the <a href="changes.html">Project Implementation Phase
+ Provisioning</a> document for pointers on how to implement these changes.
+ <br>
+ </p>
+ </td>
+</tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Project newsgroup</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p>At this stage, the proposal newsgroup can be repositioned as the project
+ newsgroup, or the team can archive the existing newsgroup (so it becomes
+ read-only) and start a new project newsgroup. <br><br>
+ </p>
+ </td>
+</tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ </font><a name="web"></a><font face="Arial,Helvetica" color="#FFFFFF">Project
+ website</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p>Each project has a web presense on www.eclipse.org. The content for a
+ project web pages is stored in a separate CVS repository on dev.eclipse.org.
+ The repository is automatically checked out to www.eclipse.org, and thereby
+ enables website authors to use HTML and PHP to author websites directly
+ on www.eclipse.org, does not require viewcvs, and paves the way for an
+ eventual MySQL database backend. Only those committers designated by their
+ project PMC will be granted update rights to the project website CVS.
+ As a bootstrap mechanism, the PMC will have committer access to assist
+ with web maintenance.<br>
+ <br>
+ A directory of the form <b>www.eclipse.org/[shortname]</b> will be created
+ by the webmaster for each new project. This also becomes the url for the
+ project home page. A default index.html page containing the required frames
+ is created in the website CVS repository. </p>
+ <p>Here's how it works:</p>
+ <p>1 - In Eclipse, create a new CVS Repository location:</p>
+ <blockquote>
+ <blockquote>
+ <p><b>Server</b>: dev.eclipse.org<br>
+ <b>Path</b>: /home/cvs/org.eclipse<br>
+ <b>Username/Password</b>: your committer credentials are also used
+ for website authoring<br>
+ <b>Website url</b>: www.eclipse.org/[shortname]</p>
+ </blockquote>
+ </blockquote>
+ <p>2 - Checkout the "www" project, and you will see the project directories.
+ Each of these directories has a single index.html file that sets up the
+ frames and opens up main.html.<br>
+ <br>
+ 3 - It may take up to one minute to transfer committed content to www.eclipse.org
+ but essentially committed changes are live.</p>
+ <p>There are some images which you may use in your web pages. These can
+ be viewed at www.eclipse.org/images/.
+ </p>
+ <p>The Tools and Technology Top-Level Projects have modelled the following
+ conventions for project websites. </p>
+ <table width="75%" border="1">
+ <tr>
+ <td>
+ <div align="center"><b>Filename</b></div>
+ </td>
+ <td>
+ <div align="center"><b>Purpose</b></div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/main.html</div>
+ </td>
+ <td>
+ <div align="center">the content for the main project page </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/faq.html</div>
+ </td>
+ <td>
+ <div align="center">the project faq page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/download.html</div>
+ </td>
+ <td>
+ <div align="center">the project downloads page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/plan.html</div>
+ </td>
+ <td>
+ <div align="center">the project plan page</div>
+ </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="downloadspace"></a><font face="Arial,Helvetica" color="#FFFFFF">Builds
+ and downloads</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p><b>Builds </b><br>
+ The project leads are responsible for builds and maintenance on eclipse.org.
+ The frequency of these is dependent on the project needs. For more information
+ see: </p>
+ <blockquote>
+ <p>Eclipse project development - <a href="http://www.eclipse.org/eclipse/development/main.html">http://www.eclipse.org/eclipse/development/main.html</a><br>
+ Platform release engineering - <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html">http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html</a></p>
+ </blockquote>
+ <b>Downloads </b><br>
+ The project lead and their appointed committers will receive an account
+ and password on download1.eclipse.org which is a high-bandwidth download
+ server. For projects under the Tools Top-Level Project, for example, the directory will
+ be /home/www/tools/xyz. For mirroring purposes, however, the link to download
+ a file is http://www.eclipse.org/downloads/download.php?file=/tools/xyz/fileName.
+ This will allow mirror site selection based on the file requested. We ask
+ that you not link directly to "download.eclipse.org" or "download1.eclipse.org"
+ <p>Because the downloads space is mirrored to several servers worldwide,
+ we ask you use this space wisely, taking extra care when placing large
+ files in this space, and performing regular file cleanups. Large directories
+ use bandwidth while mirroring and deter new mirror sites because of high
+ disk space requirements. Also, HTML and PHP files must not be placed on
+ the download server.</p>
+ <p>Uploads to this space are via SFTP (preferred) or FTP. Use any SFTP client,
+ such as CoreFTP, to connect to download1.eclipse.org. Although you are
+ connecting to download1.eclipse.org, links to files must be done to download.eclipse.org.
+ <br>
+ <br>
+ RSYNC transfers can be arranged. Please consult the <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a>
+ for details on setting this up.</p>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="changes"></a><font face="Arial,Helvetica" color="#FFFFFF">Changes
+ </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><b> For more information see the <a href="changes.html">Project Implementation
+ Phase Provisioning</a> document. <br>
+ <br>
+ Getting changes to your infrastructure</b></p>
+ <p>If you need changes to your infrastructure, you need to send an email
+ to webmaster@eclipse.org or to the emo@eclipse.org. In general things
+ like password reset and creating new components are taken care of by the
+ webmaster. Other content related changes such as changes to web elements
+ on www.eclipse.org should be sent to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>.
+ When sending requests, please clearly identify the Top-Level Project and
+ Project you are working on so that requests that require PMC approval
+ or clarification can be properly routed to the correct PMC by the infrastructure
+ team.</p>
+ <p><b>Changes to your committers list</b><br>
+ Changes to the committers list, including adding new committers, is done
+ through <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>. We also
+ track the committer's address and contact information. We use these lists
+ to determine the developer's voting rights on eclipse.org, so please help
+ us to keep them up to date! For more information see the <a href="changes.html">Project
+ Implementation Phase Provisioning</a> document. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Project validation phase provisioning checklist
+ </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="11%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="43%"><b> Description</b></td>
+ <td width="33%"><b>Project team deliverable</b></td>
+ <td width="13%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="11%" >Committers list</td>
+ <td width="43%">
+ <p>A list of the initial committers for the project.<br>
+ </p>
+ </td>
+
+ <td width="33%">A list of the initial committers with the following information:<br>
+ - name of the project and hosting top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - if available, the list of CVS components or modules to which the committer
+ will have update privileges</td>
+ <td width="13%">- nominated by PMC <br>
+ - approved by EMO </td>
+ </tr>
+ <tr>
+
+ <td width="11%" >Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="43%">
+ <p>The EMO is responsible for ensuring that documentation is in place for
+ new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="33%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="13%"> </td>
+ </tr>
+ <tr>
+ <td width="11%" >List of initial CVS components or modules</td>
+
+ <td width="43%">
+ <p>Typical components are:<br>
+ org.eclipse.[shortname].[component]<br>
+ </p>
+ </td>
+
+ <td width="33%">- a list of components along with a list of committers who
+ will have access to each component<br>
+ </td>
+ <td width="13%">review by PMC and EMO</td>
+ </tr>
+ <tr>
+
+ <td width="11%" >Project website moves to website CVS</td>
+
+ <td width="43%">- <i><a href="#web">See Website section above</a></i> <br>
+ - the project receives a website address on www.eclipse.org in the format
+ www.eclipse.org/[shortname]/<br>
+ -the website content is checked into the corresponding repository by
+ the project committers <br>
+ Note: Only those committers designated by their project PMC will be
+ granted update rights to the project website CVS. As a bootstrap mechanism,
+ the PMC will have committer access to assist with web maintenance.<br>
+ </td>
+
+ <td width="33%">- a list of which committers have access to the website CVS<br>
+ - the new committers can coordinate the release of their new site with the
+ release of links from the hosting top-level project pages, newsgroups and
+ mailing list pages, etc. </td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Project description</td>
+ <td width="43%">the project description is modified on the top-level project
+ main page to reflect change in status</td>
+ <td width="33%">- any requested edits to the project description</td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Proposal archived</td>
+
+ <td width="43%">the successful proposal is archived in the proposal archive</td>
+
+ <td width="33%"> </td>
+ <td width="13%">- none</td>
+ </tr>
+ <tr>
+ <td width="11%" >Newsgroup link on newsgroups page </td>
+
+ <td width="43%">the <a href="#newsgroups">newsgroup</a> is moved from a standalone
+ position on the page to the appropriate Top-Level Project</td>
+ <td width="33%">- any requested edits to the newsgroup description</td>
+
+ <td width="13%">review by PMC </td>
+ </tr>
+ <tr>
+ <td width="11%" >Mailing list name </td>
+ <td width="43%">- typical mailing list names are in the form [shortname]-dev@eclipse.org
+ <br>
+ - when multiple components are developed independently, component lists
+ are created in the form [shortname]-[component] -dev@eclipse.org</td>
+ <td width="33%">- confirmation of list name and/or component list names</td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Mailing list short description</td>
+ <td width="43%">- the short description appears on the mailing list main page</td>
+ <td width="33%">- short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Mailing list long description </td>
+ <td width="43%">- the long description appears on the introductory page to
+ the individual mailing list </td>
+ <td width="33%">- long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a></td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+
+ <td width="11%" >Download directory</td>
+
+ <td width="43%">
+ <p>- the project lead will submit the names of one or two committers
+ per project who will receive an account and password on download1.eclipse.org<br>
+ - <i><a href="#downloadspace">see Builds and Downloads above</a></i></p>
+ </td>
+
+ <td width="33%">- names of committers to be granted update rights to the download
+ site </td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+ <tr>
+ <td width="11%" >Bugzilla </td>
+ <td width="43%">- Bugzilla product is created with sublisting for each component
+ and component milestone eg. <br>
+ <img src="bugzillacomponent.jpg" width="355" height="113"> <br>
+ </td>
+ <td width="33%">- initial list of components, milestones, and component owners</td>
+
+ <td width="13%">review by PMC</td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/projectvalidation.html b/dev_process/old_provisioning/projectvalidation.html
new file mode 100644
index 0000000..d4d0c6e
--- /dev/null
+++ b/dev_process/old_provisioning/projectvalidation.html
@@ -0,0 +1,29 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Project Validation Phase Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>project validation phase provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><br><font size="+1">
+ Please use the <a href="/org/processes/project_validation_provisioning_request.html">new
+ combination web-form & document</a>.</font>
+ </p>
+ <p>The <a href="projectvalidation-old.html">old version</a> of this
+ document is still available from the archives.
+ </p>
+ </td> </tr>
+</table>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/proposal.jpg b/dev_process/old_provisioning/proposal.jpg
new file mode 100644
index 0000000..b021e32
--- /dev/null
+++ b/dev_process/old_provisioning/proposal.jpg
Binary files differ
diff --git a/dev_process/old_provisioning/toplevelproposal.html b/dev_process/old_provisioning/toplevelproposal.html
new file mode 100644
index 0000000..fcf2c7c
--- /dev/null
+++ b/dev_process/old_provisioning/toplevelproposal.html
@@ -0,0 +1,218 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Top-Level Project Proposal Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="60%"><font class=indextop>top-level project proposal
+ provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="40%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <table width="100%" cellspacing="3" cellpadding="2">
+ <tr>
+ <td align="center" valign="top" colspan="2">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+ </table>
+ </td> </tr>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for Top-Level Project proposals
+ (projects that propose a new PMC) at eclipse.org. The <a href="projectproposal.html">Project
+ Proposal Provisioning</a> document describes the infrastructure for new
+ projects under an existing Top-Level Project. These documents follow the
+ Eclipse Project Lifecyle as described in the <a href="../org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> .<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse top-level project proposal review infrastructure</font></b></td>
+ </TR>
+ <tr>
+ <td> <img src="proposal.jpg"></td>
+ <td> When a declaration is made to the EMO, the initiating individual works
+ with a PMC to create a proposal which begins the proposal phase. See the
+ <a href="main.html">Project Provisioning</a> document and review archives
+ of previous successful proposals on the <a href="../proposals/main.html">Proposals</a>
+ page for more details about this process. During the proposal phase the
+ project is provisioned with two items:<br>
+ <br>
+ 1 - a website in the proposals directory on eclipse.org, and <br>
+ 2 - a <a href="#newsgroups">newsgroup</a> to open discussions. <br>
+ <br>
+ Please consult the <a href="#checklist">checklist</a> below for items required
+ to create the proposal website and the newsgroup. Each of the deliverables
+ can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>. <br>
+ <br>
+ At the end of the Proposal Phase is the <a href="#creationreview">Creation
+ Review</a>. During the proposal phase you may consider an <a href="#pr">Announcment
+ Press Release</a>, or you may decide to do the release after the Creation
+ Review and as part of the launch of the <a href="toplevelvalidation.html">Top-Level
+ Project Validation</a> phase. <br>
+ </td> </tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Proposal newsgroups </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td colspan "4"> In this phase, the newsgroup is created last for several
+ reasons. Many newsreaders actively inform their users of the existance of
+ a new newsgroup so when we first created all the infrastructure in a single
+ big bang, the project leaders didn't have enough time to populate the main
+ web page of the proposal before it was "pre-announced" by the
+ newsreader software. We now wait for the main web page to be complete before
+ the newsgroups are created. We then post an initial message, inviting people
+ to visit the newly created project page to learn more about the project.
+ <br>
+</td>
+</tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="pr"></a>Announcement press release </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The press release is optional. The release could be issued by the Foundation,
+ or it could be a joint release with the project's stakeholders, and includes
+ Q&A's, messages and preparation of the stakeholder spokespeople. The
+ discipline of creating a press release ensures that all stakeholders have
+ agreed on messages, positioning and have identified spokepersons.<br>
+ <br>
+ If you do decide to issue a press release, the Eclipse Foundation Marketing
+ Director can help you coordinate the announcement. (Email the <a href="mailto:emo@eclipse.org">EMO</a>
+ for further information.)<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="creationreview"></a>Creation review </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td colspan="4" width="100%">
+ <p>The creation review is scheduled roughly one to two months after the
+ proposal is made public to ensure sufficient time to receive and respond
+ to feedback received from the community. The creation review meeting will
+ include members of the proposed Top-Level Project PMC, representatives
+ from the existing eclipse PMCs and the Eclipse Foundation. The review
+ format is teleconference, and is open to the eclipse membership at large.
+ Notifications of creation review meetings are sent to the eclipse membership
+ mailing list by the EMO. <br>
+ <br>
+ The two key criteria in successfully passing the creation review are:
+ <ol>
+ <li>does the project have a community of contributors and committers who
+ are willing to work towards making this a success? <br>
+ </li>
+ <li>does the project have a technology scope and focus which will have
+ a reasonable likelihood of success</li>
+ </ol>
+ <p> Although the creation review is a relatively informal meeting, the proposed
+ top-level PMC lead will be expected to make a brief presentation to the
+ review committee. The presentation should include a brief summary of the
+ project proposal, in addition to comments about the community response
+ to the proposal, current project participants, initial implementation
+ focus and future directions. The presentation slides will be posted to
+ the proposal site before the review. You can view previous sucessful creation
+ review slide presentations in the <a href="../proposals/main.html">Proposal
+ Archives</a>. <br>
+ <br>
+ Upon a successful review the EMO will recommend creation of the project
+ for the Eclipse Foundation Board of Director's final approval.
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Top-Level project proposal provisioning checklist
+ </font></b></td>
+ </TR>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="21%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="23%"><b> Description</b></td>
+ <td width="43%"><b>Project team deliverable</b></td>
+ <td width="13%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="21%" >Proposal published on static web pages </td>
+ <td width="23%">pages published in eclipse.org/proposals directory, linked
+ from proposals main page</td>
+ <td width="43%">-HTML documents (where possible) <br>
+ - in this stage no access is granted to the static webpages, therefore an
+ approved draft for posting should be delivered 48 hours before launch date.
+ The project team then has a one-day cycle to review the proposal as it will
+ be published. </td>
+ <td width="13%">EMO</td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Short Name</td>
+ <td width="23%">The name for the proposal subdirectory on which the newsgroup,
+ mailing list, and CVS addresses will be based </td>
+ <td width="43%">- a 3-6 character short name or acronym for the project title
+ </td>
+ <td width="13%">EMO </td>
+ </tr>
+ <tr>
+ <td width="21%" >Project Description</td>
+ <td width="23%">a brief description of the project (1 paragraph) for the proposals
+ page </td>
+ <td width="43%">- a one paragraph description of the proposed project</td>
+ <td width="13%">EMO </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup</td>
+ <td width="23%">the initial newsgroup for soliciting feedback on the proposal</td>
+ <td width="43%">- confirmation of newsgroup name in format news://news.eclipse.org/<br>
+ eclipse.[top-level project].[shortname}<br>
+ - the newsgroup is the last item to be released on launch day<br>
+ - the preparation cycle is 3-6 hours, therefore a confirmed name 24 hours
+ before the launch is preferred. </td>
+ <td width="13%">EMO </td>
+ </tr>
+ <tr>
+ <td width="21%" >Newsgroup description </td>
+ <td width="23%">3 line newsgroup description that appears on the <a href="../newsgroups/index.html" target="_top">Newsgroups
+ main page </a></td>
+ <td width="43%">- newsgroup description/invitation to participate</td>
+ <td width="13%">EMO</td>
+ </tr>
+
+</table>
+
+
+</body>
+</html>
diff --git a/dev_process/old_provisioning/toplevelvalidation.html b/dev_process/old_provisioning/toplevelvalidation.html
new file mode 100644
index 0000000..f20f13b
--- /dev/null
+++ b/dev_process/old_provisioning/toplevelvalidation.html
@@ -0,0 +1,439 @@
+<html>
+<head>
+<link rel="stylesheet" href="../default_style.css">
+<title>Top-Level Project Provisioning</title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
+<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" height="129" >
+ <tr>
+ <td ALIGN=LEFT width="67%"><font class=indextop>top-level project validation
+ phase provisioning</font><br>
+ <font class=indexsub>infrastructure for projects </font></td>
+ <td WIDTH="33%"> </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td align="center" valign="top">
+ <p style="border-style: dashed"><b><font face="Arial,Helvetica" size="+1">These
+ pages are out-of-date. <br>
+ Revised and corrected versions of these pages are being developed. <br>
+ Please verify with all information on these pages with the <a href="mailto:emo@eclipse.org">EMO</a>.</font></b></p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p><br>
+ This document describes the infrastructure for new Top-Level Projects
+ (projects that propose a new PMC) that have completed a sucessful creation
+ review and are beginning the validation phase of their project at eclipse.org.
+ The <a href="projectvalidation.html">Project Validation Phase Provisioning</a>
+ document describes the infrastructure for new projects under an existing
+ Top-Level Project. These documents follow the Eclipse Project Lifecyle as described
+ in the <a href="../org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and are intended to complement the information
+ provided there. In general all inquiries related to project provisioning
+ can be sent to the <a href="mailto:emo@eclipse.org">EMO</a> .<br>
+ </p>
+ </td> </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ Eclipse Top-Level project validation phase infrastructure</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="0">
+<tr>
+ <td> <img src="validation.jpg" width="180" height="310"></td>
+ <td width="100%">
+ <p>After a successful Creation Review, the project enters the Validation
+ Phase and additional infrastructure is created to support the initial
+ work on the project:</p>
+ <ul>
+ <li>CVS commit rights</li>
+ <li> CVS component structure</li>
+ <li>download site </li>
+ <li>a developer mailing list and</li>
+ <li> the project website<br>
+ </li>
+ </ul>
+ Please consult the <a href="#checklist">checklist</a> below for items
+ required to implement this core infrastructure. Each of the deliverables
+ can be emailed to the <a href="mailto:emo@eclipse.org">EMO</a>.
+ <p>The project is 'created' in two steps: </p>
+ <ol>
+ <li>CVS, user accounts, mailing-list, master home page (links to your
+ page in the <a href="#web">website CVS</a>), <a href="#downloadspace">download
+ space</a> on download.eclipse.org, and bugzilla </li>
+ <li> Developer mailing lists, hosting Top-Level Project main page and any additional
+ <a href="#newsgroups">newsgroups</a> are then connected to your
+ project making it "live".</li>
+ </ol>
+
+ <p> This ensures that all the core infrastructure is ready and that the
+ data and an initial project structure are in place, before the project
+ goes 'live". <br>
+ <br>
+ Ongoing <a href="#changes">changes</a> to the project's core infrastructure
+ are expected especially during the Validation Phase, as the project matures.
+ Please consult the <a href="changes.html">Project Implementation Phase
+ Provisioning</a> document for pointers on how to implement these changes.
+ </p>
+ </td> </tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="newsgroups"></a>Project newsgroup</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p>At this stage, the proposal newsgroup can be repositioned as the project
+ newsgroup, or the team can archive the existing newsgroup (so it becomes
+ read-only) and start a new project newsgroup. <br><br>
+ </p>
+ </td>
+</tr>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ </font><a name="web"></a><font face="Arial,Helvetica" color="#FFFFFF">Project
+ website</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p>Each project has a web presense on www.eclipse.org. The content for
+ a project web pages is stored in a separate CVS repository on dev.eclipse.org.
+ The repository is automatically checked out to www.eclipse.org, and
+ thereby enables website authors to use HTML and PHP to author websites
+ directly on www.eclipse.org, does not require viewcvs, and paves the
+ way for an eventual MySQL database backend. Only those committers
+ designated by their project PMC will be granted update rights to the
+ project website CVS. As a bootstrap mechanism, the PMC will have committer
+ access to assist with web maintenance.<br>
+ <br>
+ A directory of the form <b>www.eclipse.org/[shortname]</b> will be
+ created by the webmaster for each new project. This also becomes the
+ url for the project home page. A default index.html page containing
+ the required frames is created in the website CVS repository. </p>
+ <p>Here's how it works:</p>
+ <p>1 - In Eclipse, create a new CVS Repository location:</p>
+ <blockquote>
+ <blockquote>
+ <p><b>Server</b>: dev.eclipse.org<br>
+ <b>Path</b>: /home/cvs/org.eclipse<br>
+ <b>Username/Password</b>: your committer credentials are also used
+ for website authoring<br>
+ <b>Website url</b>: www.eclipse.org/[shortname]</p>
+ </blockquote>
+ </blockquote>
+ <p>2 - Checkout the "www" project, and you will see the project directories.
+ Each of these directories has a single index.html file that sets up
+ the frames and opens up main.html.<br>
+ <br>
+ 3 - It may take up to one minute to transfer committed content to
+ www.eclipse.org but essentially committed changes are live.</p>
+
+ <p>There are some images which you may use in your web pages. These can
+ be viewed at www.eclipse.org/images. </p>
+
+ <p>The Tools and Technology Top-Level Projects have modelled the following
+ conventions for project websites. </p>
+ <table width="75%" border="1">
+ <tr>
+ <td>
+ <div align="center"><b>Filename</b></div>
+ </td>
+ <td>
+ <div align="center"><b>Purpose</b></div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/main.html</div>
+ </td>
+ <td>
+ <div align="center">the content for the main project page </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/faq.html</div>
+ </td>
+ <td>
+ <div align="center">the project faq page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/download.html</div>
+ </td>
+ <td>
+ <div align="center">the project downloads page</div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <div align="center">www.eclipse.org/xyz/plan.html</div>
+ </td>
+ <td>
+ <div align="center">the project plan page</div>
+ </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="downloadspace"></a><font face="Arial,Helvetica" color="#FFFFFF">Builds
+ and downloads</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+
+ <tr>
+ <td>
+ <p><b>Builds </b><br>
+ The project leads are responsible for builds and maintenance on eclipse.org.
+ The frequency of these is dependent on the project needs. For more information
+ see: </p>
+ <blockquote>
+ <p>Eclipse project development - <a href="http://www.eclipse.org/eclipse/development/main.html">http://www.eclipse.org/eclipse/development/main.html</a><br>
+ Platform release engineering - <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html">http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html</a></p>
+ </blockquote>
+ <b>Downloads </b><br>
+ The project lead and their appointed committers will receive an account
+ and password on download1.eclipse.org which is a high-bandwidth download
+ server. For projects under the Tools Top-Level Project, for example, the directory will
+ be /home/www/tools/xyz. For mirroring purposes, however, the link to download
+ a file is http://www.eclipse.org/downloads/download.php?file=/tools/xyz/fileName.
+ This will allow mirror site selection based on the file requested. We ask
+ that you not link directly to "download.eclipse.org" or "download1.eclipse.org"
+ <p>Because the downloads space is mirrored to several servers worldwide,
+ we ask you use this space wisely, taking extra care when placing large
+ files in this space, and performing regular file cleanups. Large directories
+ use bandwidth while mirroring and deter new mirror sites because of high
+ disk space requirements. Also, HTML and PHP files must not be placed on
+ the download server.</p>
+ <p>Uploads to this space are via SFTP (preferred) or FTP. Use any SFTP client,
+ such as CoreFTP, to connect to download1.eclipse.org. Although you are
+ connecting to download1.eclipse.org, links to files must be done to download.eclipse.org.
+ <br>
+ <br>
+ RSYNC transfers can be arranged. Please consult the <a href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</a>
+ for details on setting this up.</p>
+ </td>
+ </tr>
+ </table><p></p>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td colspan="2" align="left" valign="top" bgcolor="#0080C0"><b><a name="changes"></a><font face="Arial,Helvetica" color="#FFFFFF">Changes
+ </font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr>
+ <td>
+ <p><b> For more information see the <a href="changes.html">Project Implementation
+ Phase Provisioning</a> document. <br>
+ <br>
+ Getting changes to your infrastructure</b></p>
+ <p>If you need changes to your infrastructure, you need to send an email
+ to webmaster@eclipse.org or to the emo@eclipse.org. In general things
+ like password reset and creating new components are taken care of by the
+ webmaster. Other content related changes such as changes to web elements
+ on www.eclipse.org should be sent to <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>.
+ When sending requests, please clearly identify the Top-Level Project and
+ Project you are working on so that requests that require PMC approval
+ or clarification can be properly routed to the correct PMC by the infrastructure
+ team.</p>
+ <p><b>Changes to your committers list</b><br>
+ Changes to the committers list, including adding new committers, is done
+ through <a href="mailto:emo@eclipse.org">emo@eclipse.org</a>. We also
+ track the committer's address and contact information. We use these lists
+ to determine the developer's voting rights on eclipse.org, so please help
+ us to keep them up to date! For more information see the <a href="changes.html">Project
+ Implementation Phase Provisioning</a> document. <br>
+ <br>
+ </p>
+ </td>
+ </tr>
+</table>
+<table width="100%" cellspacing=0 cellpadding=3 align=center>
+ <tr bgcolor="#999999">
+ <td align="left" valign="top" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
+ <a name="checklist"></a>Top-Level project validation phase provisioning
+ checklist</font></b></td>
+ </TR>
+ </table>
+<table width="100%" cellspacing=0 cellpadding=3 align=top border="1">
+ <tr>
+ <td width="16%">
+ <p><b>Item</b></p>
+ </td>
+ <td width="38%"><b> Description</b></td>
+ <td width="32%"><b>Project team deliverable</b></td>
+ <td width="14%"><b>Review by</b></td>
+ </tr>
+ <tr>
+ <td width="16%" >Committers list</td>
+ <td width="38%">
+ <p>A list of the initial committers for the project.<br>
+ </p>
+ </td>
+ <td width="32%">A list of the initial committers with the following information:<br>
+ - name of the project and new top-level project<br>
+ - full name of the committer<br>
+ - email address of the committer<br>
+ - if available, the list of CVS components or modules to which the committer
+ will have update privileges</td>
+ <td width="14%">- nominated by PMC <br>
+ - approved by EMO </td>
+ </tr>
+ <tr>
+
+ <td width="16%" >Committer Guidelines, Agreement, Questionnaire and Employer
+ Consent </td>
+
+ <td width="38%">
+ <p>The EMO is responsible for ensuring that documentation is in place
+ for new committers. <br>
+ <br>
+ Once the documentation is in place, the EMO will contact the webmaster
+ to provide the appropriate accesses to the new committers. </p>
+ </td>
+ <td width="32%">
+ <p>- the project team may appoint a single contact to assist the new
+ committers in completing the required documentation</p>
+ <p> </p>
+ </td>
+ <td width="14%"> </td>
+ </tr>
+ <tr>
+ <td width="16%" >List of initial CVS components</td>
+
+ <td width="38%">Typical components are:<br>
+ org.eclipse.[shortname].[component]<br>
+ <p> </p>
+ </td>
+
+ <td width="32%">- a list of components along with a list of committers who
+ will have access to each component<br>
+ <br>
+ </td>
+
+ <td width="14%">submitted by PMC and reviewed by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="16%" >Project website moves to website CVS</td>
+
+ <td width="38%">- <i><a href="#web">See Website section above</a></i> <br>
+ - the project receives a website address on www.eclipse.org in the format
+ www.eclipse.org/[shortname]/<br>
+ -the website content is checked into the corresponding repository by
+ the project committers <br>
+ Note: Only those committers designated by their project PMC will be
+ granted update rights to the project website CVS. As a bootstrap mechanism,
+ the PMC will have committer access to assist with web maintenance.<br>
+ </td>
+
+ <td width="32%">- a list of which committers have access to the website CVS<br>
+ - the new committers can coordinate the release of their new site with the
+ release of links from the project main page, newsgroups and mailing list
+ pages, etc. </td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Project description</td>
+
+ <td width="38%">the project description is modified on the project main page
+ (www.eclipse.org/projects/index.html) to reflect change in status</td>
+ <td width="32%">- any requested edits to the project description</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Proposal archived</td>
+
+ <td width="38%">the successful proposal is archived in the proposal archive</td>
+ <td width="32%">- none</td>
+
+ <td width="14%"> </td>
+ </tr>
+ <tr>
+ <td width="16%" >Newsgroup link on newsgroups page </td>
+
+ <td width="38%">the <a href="#newsgroups">newsgroup</a> is moved from a standalone
+ position on the page a new top-level project section </td>
+ <td width="32%">- any requested edits to the newsgroup description</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Mailing list name </td>
+ <td width="38%">- typical mailing list names are in the form [shortname]-dev@eclipse.org
+ <br>
+ - when multiple components are developed independently, component lists
+ are created in the form [shortname]-[component] -dev@eclipse.org</td>
+ <td width="32%">- confirmation of list name and/or component list names</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Mailing list short description</td>
+ <td width="38%">- the short description appears on the mailing list main page</td>
+ <td width="32%">- short description based on the examples here <a href="http://www.eclipse.org/mail/index.html" target="_blank">http://www.eclipse.org/mail/index.html</a></td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Mailing list long description </td>
+ <td width="38%">- the long description appears on the introductory page to
+ the individual mailing list </td>
+ <td width="32%">- long description based on the example shown here <a href="http://dev.eclipse.org/mailman/listinfo/platform-dev" target="_blank">http://dev.eclipse.org/mailman/<br>
+ listinfo/platform-dev</a></td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+
+ <td width="16%" >Download directory</td>
+
+ <td width="38%">
+ <p>- the project lead will submit the names of one or two committers
+ per project who will receive an account and password on download1.eclipse.org<br>
+ - <i><a href="#downloadspace">see Downloads above</a></i></p>
+ </td>
+ <td width="32%">- names of committers to be granted update rights to the
+ download site </td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+ <tr>
+ <td width="16%" >Bugzilla </td>
+ <td width="38%">- Bugzilla product is created with sublisting for each component
+ and component milestone eg. <br>
+ <img src="bugzillacomponent.jpg" width="355" height="113"> <br>
+ </td>
+ <td width="32%">- initial list of components, milestones and component
+ owners</td>
+
+ <td width="14%">review by EMO</td>
+ </tr>
+</table>
+<p></p>
+<p></p>
+</body>
+</html>
diff --git a/dev_process/old_provisioning/validation.jpg b/dev_process/old_provisioning/validation.jpg
new file mode 100644
index 0000000..f9e1161
--- /dev/null
+++ b/dev_process/old_provisioning/validation.jpg
Binary files differ
diff --git a/dev_process/pre-proposal-phase.php b/dev_process/pre-proposal-phase.php
new file mode 100644
index 0000000..38c67cf
--- /dev/null
+++ b/dev_process/pre-proposal-phase.php
@@ -0,0 +1,250 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Pre-Proposal Phase";
+$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>Pre-Proposal Phase</h1>
+<p><i>version 026 - November 10, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Pre-Proposal Phase</h2>
+<p>The Pre-Proposal Phase starts when an individual or company declares their interest in,
+ and rationale for, establishing a project; and ends with a proposal being
+made available to the membership by being posted on the eclipse.org website.</p>
+<p>The first step is to decide whether the new idea is a top-level project, a
+sub-project, or a component. Some rules of thumb on this decision are:</p>
+<table border="1" width="100%">
+ <tr>
+ <td width="25%"> </td>
+ <td width="25%" align="center"><b>Component</b></td>
+ <td width="25%" align="center"><b>Sub-Project</b></td>
+ <td width="25%" align="center"><b>Top-Level Project</b></td>
+ </tr>
+ <tr>
+ <td width="25%"><b>Project Management</b></td>
+ <td width="25%" valign="top">managed as part of a larger effort</td>
+ <td width="25%" valign="top">managed separately<sup>1</sup></td>
+ <td width="25%" valign="top">managed separately</td>
+ </tr>
+ <tr>
+ <td width="25%"><b>Shipping and Releases</b></td>
+ <td width="25%" valign="top">MUST ship at the same time as the other pieces</td>
+ <td width="25%" valign="top">USUALLY ships at the same time as the other
+ pieces</td>
+ <td width="25%" valign="top">shipping deadlines are unrelated to other
+ pieces</td>
+ </tr>
+ <tr>
+ <td width="25%"><b>Code Size</b></td>
+ <td width="25%" valign="top">Small</td>
+ <td width="25%" valign="top">Medium to large</td>
+ <td width="25%" valign="top">Large and larger</td>
+ </tr>
+</table>
+<p>The next step in establishing a new project at Eclipse is to contact the Eclipse Management Organization
+(<a href="mailto:emo@eclipse.org">EMO</a>) and begin working towards a Project Proposal and a Project Declaration.
+The goal of this phase is to ensure that the proposal is clear, understandable,
+and is a good fit with the Purposes.</p>
+<p>A declaration is a short email which is distributed by the EMO to the Eclipse membership-at-large stating that someone wants to start a project at Eclipse. Before a declaration is sent, the EMO will want to talk about the technology areas you are planning on working on, which Project Management Committee (PMC) the new project would best fit in, who you think will be working on the project, etc.
+The EMO will also want to see a nearly complete draft of the proposal as our
+experience is that good proposals more than a week to write.</p>
+<p>The declaration has the following form:</p>
+<blockquote>As per the Eclipse Development Process, we are notifying the Eclipse Membership-at-Large of the intent of
+Company Q to propose the XYZ Project as part of the Technology PMC.<br>
+<br>
+A brief description of the project is below. A draft project proposal has been posted on
+ http://www.eclipse.org/proposals/.../index.html and will become public in a
+ few days.<br>
+<br>
+------------------------------------------------------------------------<br>
+<br>
+*Project Declaration for the "XYZ Project"*<br>
+<br>
+The goal of this project is to add comprehensive support blah blah blah... </blockquote>
+<p>History has shown that companies who are starting their first open-source
+project, or perhaps merely their first Eclipse open-source project, want to
+carefully stage the press announcements. Because the Eclipse membership-at-large
+is large and includes press, the EMO works carefully with the proposers to
+ensure that news is not prematurely leaked.</p>
+<p>The declaration is emailed to the membership more or less a week in advance of the
+proposal being posted. This provides a benefit of membership and allows members
+to raise concerns about projects before they become public.</p>
+<p>The goals of the proposal document itself include:</p>
+<ul>
+ <li><b>Clear and concise description.</b> <br>
+ It is important that the description be understandable by the diverse
+ Eclipse community and not just by specialists in the subject matter. It is
+ also important that the description concentrate on the technical aspects of
+ the project and avoid marketing buzzwords. Terms that are not in common use
+ amongst the Eclipse membership must be defined, and references to standards
+ should be linked to the corresponding URL.
+ <ul>
+ <li>A thought experiment for clarity and conciseness is "if I
+ randomly choose five Committers from the entire Eclipse Committer pool,
+ will those five people understand what this project is about?" The
+ five may not agree with the proposal or even believe that it is
+ feasible, but they need to understand what it is proposing.<sup>2</sup></li>
+ </ul>
+ </li>
+ <li><b>Resources committed.</b><br>
+ Eclipse is a place for active projects, not a place for dumping unwanted
+ code. Eclipse projects involve substantial on-going development activity. Thus proposals should be convincing about the resources that are being
+ brought to the project in addition to any initial code contribution.</li>
+ <li><b>Tools versus Run-time.<br>
+ </b>Currently the Eclipse Bylaws, section 1.1, state that "the Eclipse
+ technology is a vendor-neutral, open development platform supplying
+ frameworks and exemplary, extensible tools".
+ <ul>
+ <li>The distinction between tools and run-times is not as black-and-white as one
+ might like - for example, is the code generated by a tool consider a
+ run-time? What about a library that must be linked to use the code generated
+ by a tool? What about a framework that must be installed on a J2EE server in
+ order to use a particular tool with that server? etc. - and yet the Eclipse
+ organization is conscious of the issue. </li>
+ <li> Currently, the
+ policy is that "plumbing", or primitive, run-times are not
+ acceptable whereas frameworks that work on top of existing run-times (e.g.,
+ works on top of J2EE) are acceptable.</li>
+ <li>Frameworks that are in support of development tools are acceptable;
+ frameworks that are application servers, database servers, operating
+ systems, etc. are not acceptable. Projects that are more appropriate at
+ other more server-centric open source organizations (such as Apache or
+ ObjectWeb) are not.</li>
+ <li> The easiest proposals, of course, are those with no ambiguity: for
+ example, an Eclipse tool that generates configuration files for an Apache
+ run-time to render.</li>
+ </ul>
+ </li>
+ <li>
+ <p align="left"><b>Consistent With The Purposes.<br>
+ </b>Eclipse projects, and hence all proposals, must be consistent with the <a href="/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf">Purposes</a>.
+ </li>
+ <li><b>Project Name.<br>
+ </b>Naming and branding are challenging issues. In order to provide a consistent
+brand for Eclipse, projects must follow <a href="project-naming-policy.php">the project naming
+ guidelines</a>, summarized here. The best names are descriptive but
+ at the same time memorable. The policy for project names is:
+ <ul>
+ <li><b>Descriptive Name.</b> A descriptive name is one that is useful
+ when placed into a box on <a href="/org/councils/AC/arch2.jpg">the
+ Eclipse architecture diagram</a>. For example "<a href="/gmf">Graphical
+ Modeling Framework</a>", "Trust Framework" or
+ "Component Assembly Tools". We want to avoid having to
+ create a <a href="http://www.apache.org/foundation/projects.html" target="_top">
+ separate web page to explain which names correspond to which
+ technology</a>.
+ <ul>
+ <li>Descriptive names do not include "Eclipse" or
+ "Project". The name should work with or without the
+ prefix and suffix. For example, "The Eclipse Graphical
+ Modeling Framework Project" as well as "Graphical
+ Modeling Framework".</li>
+ <li>Descriptive names may optionally include "Framework"
+ or "Tools" if the project has more of an emphasis on
+ extensible frameworks, or more on exemplary tools. Eclipse
+ projects always provide both but may be tailored more toward one
+ or the other. When choosing to use these words, the team should
+ consider that "Framework" and "Tools"
+ mean different things to different people and may even be
+ becoming overused. </li>
+ <li>Top-level projects may optionally include "Platform"
+ instead of "Framework".</li>
+ </ul>
+ </li>
+ <li><b>An optional Nickname.</b> Some teams like to have a clever
+ nicknames, for example "Higgins" or "Buckminister".</li>
+ <li><b>Project Name. </b>The full name includes the optional nickname, e.g., "The
+ Eclipse Component Assembly Project (Buckminister)".</li>
+ <li><b>Acronym.</b> Most descriptive names are sufficiently long
+ that it can be convenient to abbreviate them in some way. For
+ example, the Eclipse Communication Framework shortens to ECF.</li>
+ </ul>
+ </li>
+ <li><b>Vendor neutral.<br>
+ </b>Eclipse is place for vendor neutral projects which includes being
+ operating system agnostic. If, as is usually the case, the proposal is
+ coming from a single company, the proposal should explain how the resulting
+ project will be vendor neutral. Similarly, the proposal should explain away
+ any operating system dependencies.</li>
+ <li>
+ <p align="left"><b>Place in the Eclipse architecture.</b><br>
+ How does this project fit with the other Eclipse projects? Does it
+ build on top of other projects? What are the dependencies? Does
+ it overlap with existing projects? Why are the needs this project
+ meets are not met by existing Eclipse projects?
+ </li>
+</ul>
+<p>The proposal itself is a static HTML page (with a small fragment of PHP) using the standard Eclipse Proposal
+CSS style sheet (<a href="/proposals/templates/proposal-template.zip">please use
+the template we provide</a>). We have found that there are a number of problems with HTML
+generated by Microsoft Word and thus ask that proposers use some other tool to
+create the page. The proposal should include a list of interested and committed
+persons and companies and their affiliations, but should not include corporate
+or group logos.</p>
+<p>Past proposals are available from the <a href="/proposals/">archived
+proposals page</a>. Three particularly good examples to emulate are: <a href="/proposals/eclipse-mylar/">Mylar</a>,
+<a href="/proposals/eclipse-gmf/">GMF</a>, and <a href="/proposals/eclipse-dsdp/">DSDP</a>.</p>
+<p>The Pre-Proposal Phase ends when the proposal is made publicly available <a href="/proposals/"> on
+the eclipse.org website</a>. The specific mechanics are: (these will eventually be
+entered via a webform)</p>
+<ol>
+ <li>The project short name is confirmed. The short name is the subset,
+ abbreviation, or acronym that the project will most common be known by. For
+ example the <a href="/tptp/">Test and Performance Tools Platform Project</a>'s
+ short name is TPTP.</li>
+ <li>The proposal is placed on the website.</li>
+ <li>The proposal is linked both the dedicated <i><a href="/proposals">proposals</a></i> area of the
+ website and from the hosting PMC's website, both described until the one
+ paragraph project description.</li>
+ <li>A newsgroup for discussion is created.
+ <ul>
+ <li> The newsgroup name will be <code>eclipse.[toplevel].[shortname]</code>.
+The short name can be an abbreviation of the Descriptive Name, or an Acronym, e.g.,
+ eclipse.technology.ecf, or it can be the optional Nickname, e.g.,
+ eclipse.technology.buckminister.</li>
+ <li>A three
+ line newsgroup description is used for <a href="/newsgroups/">the
+ newsgroups page</a>.</li>
+ <li>The newsgroup is created last for several reasons. Many newsreaders actively
+ inform their users of the existence of a new newsgroup so when we first
+ created all the infrastructure in a single big bang, the project leaders
+ didn't have enough time to populate the main web page of the proposal before
+ it was "pre-announced" by the newsreader software. We now wait for
+ the main web page to be complete before the newsgroups are created. We then
+ post an initial message, inviting people to visit the newly created project
+ page to learn more about the project.</li>
+ </ul>
+ </li>
+</ol>
+<p>A press release at this point is optional. Some companies and
+individuals like to have a press release when the project is proposed, while
+others prefer to wait until the project is approved/created, and then others do
+not issue one at all - it is completely up to the proposal team. Any release
+must include Q&A's, messages and preparation by the stakeholder spokespeople. The discipline of creating a press release ensures
+that all stakeholders have agreed on messages, positioning and have identified
+spokepersons.</p>
+<p>If you do decide to issue a press release, the Eclipse Foundation Marketing
+Director must help you coordinate the announcement. (<a href="mailto:emo@eclipse.org">Email
+the EMO</a> for further information.)</p>
+<p>The next phase is the <a href="proposal-phase.php">Proposal Phase</a>.</p>
+
+<h3>Legal Paperwork To Start Now</h3>
+<p>It is important for the proposers to begin moving the various <a href="/legal/newcommitter.html">Committer
+Agreements</a> through their company's legal department as it always seems to
+take longer for this paperwork than one would like. The project cannot be provisioned
+(provisioning happens after the Proposal Phase) without the Questionnaires and signed Agreements.</p>
+
+<hr>
+<p><sup>1</sup> Projects often have seats on the top-level PMC, although the
+exact policy depends on the PMC.<sup><br>
+2 </sup>This thought experiment may become EMO policy in the future.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/project-log.php b/dev_process/project-log.php
new file mode 100644
index 0000000..2db7c64
--- /dev/null
+++ b/dev_process/project-log.php
@@ -0,0 +1,103 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Project Log";
+$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>Project Log</h1>
+<p><i>version 026 - October 14, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Project Log</h2>
+
+<p align="left">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. Maintaining a current and accurate Project Log is
+ the best way to keep this information up-to-date.
+
+<p>The Project Log is a CSV file (a spreadsheet saved in the open Comma
+Separated Value file format) containing the following sections. The Project Log
+must be available via a public url on the project's website, and a static copy
+must be included in the <a href="release-review.php">Release Review</a>
+materials for each release.</p>
+
+<h4>Section 1 (Committers)</h4>
+<p>A list of all the Committers, past and present, whose contribution is still
+active in the repository. A Committer whose code has been entirely removed from
+the active branches does not need to be listed. The columns for this section
+are:</p>
+<ul>
+ <li>dev.eclipse.org unix login name</li>
+</ul>
+
+<h4>Section 2 (Developers)</h4>
+
+<p>A list of all the non-Committers whose contribution is still active in the
+repository. The columns for this section are:</p>
+<ul>
+ <li>component (CVS directory)</li>
+ <li>bug #</li>
+ <li>contributor's name (see Additional Information below)</li>
+ <li>contribution size (LOC or "small" where small is defined as
+ "less than 100 LOC")</li>
+ <li>committer who committed this contribution</li>
+ <li>description if there is no bug# or if there are multiple bug #s</li>
+</ul>
+<p>Note that it behooves the project to use the full capabilities of Bugzilla to
+assist with generating this report. If the project uses the following features,
+then simple queries will generate most of section 2:</p>
+<ol>
+ <li>All code changes (100% of them) refer to a Bugzilla entry</li>
+ <li>All commit messages include the corresponding bug numbers.</li>
+ <li>VERIFY and CLOSE all RESOLVED bugs when closing out a release.</li>
+ <li>Target milestones for "fixed in version"</li>
+</ol>
+<h4>Section 3 (Third Party Software)</h4>
+<p>A list of the non-Eclipse third party software included in the project. The
+columns for this section are:</p>
+<ul>
+ <li>name including version</li>
+ <li>directory location or jar file</li>
+ <li>license name and version (including any licenses related to embedded third
+ party software)</li>
+ <li>usage (e.g. modified/unmodified, source, object, derivative work, entire
+ package or which subset)</li>
+</ul>
+<h3>Additional Information</h3>
+<p align="left">The Foundation needs to maintain contact information for all
+contributors however the Foundation also needs to abide by its <a href="/legal/privacy.php">Privacy
+Policy</a>. The projects handles these two requirements by maintaining an internal, non-public,
+database (list) of contact information for all project Contributors. Committers
+are stored by in the Foundation database under their dev.eclipse.org unix login name, thus the only
+requirement for section 1 is that login name. Contributors are stored by
+the Projects in private, in a text file, a spreadsheet, an HTML table, a small
+database, or whatever the project chooses. Section 2 uses the contributor names
+as keys into that information to avoid having to list the
+contributor's email address or mailing address in the Project IP log. The
+Project sends the contact information to the Foundation as part of the process
+of a <a href="release-review.php">Release Review</a>.</p>
+<p align="left">All of this is a long way of saying that the project leadership
+and/or PMC must keep track of the contributors' contact information in private
+and send that private list to the EMO at the Release Review.<sup>1</sup></p>
+<h3>Applicability</h3>
+<p>The project log keeps track of code contributions but also, as per the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> Eclipse IP Policy</a>,
+documentation and other non-code contributions.</p>
+
+<p><sup>1</sup> For a while, there was a concept of "contributor Foundation
+database key"; we have moved away from that and are no longer using that
+process.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/project-naming-policy.php b/dev_process/project-naming-policy.php
new file mode 100644
index 0000000..0672593
--- /dev/null
+++ b/dev_process/project-naming-policy.php
@@ -0,0 +1,97 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Eclipse Project Naming Policy";
+$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">
+
+<h2>Project
+ Name</h2>
+
+ Naming and branding are challenging issues. In order to provide a consistent
+brand for Eclipse, projects must follow these project naming guidelines. The best names are descriptive but
+ at the same time memorable. The policy for project names is:
+ <ul>
+ <li><b>Descriptive Name.</b> A descriptive name is one that is useful
+ when placed into a box on <a href="/org/councils/AC/arch2.jpg">the
+ Eclipse architecture diagram</a>. For example "<a href="/gmf">Graphical
+ Modeling Framework</a>", "Trust Framework" or
+ "Component Assembly Tools". We want to avoid having to
+ create a <a href="http://www.apache.org/foundation/projects.html" target="_top">
+ separate web page to explain which names correspond to which
+ technology</a>.
+ <ul>
+ <li>Descriptive names do not include "Eclipse" or
+ "Project". The name should work with or without the
+ prefix and suffix. For example, "The Eclipse Graphical
+ Modeling Framework Project" as well as as "Graphical
+ Modeling Framework".</li>
+ <li>Descriptive names may optionally include "Framework"
+ or "Tools" if the project has more of an emphasis on
+ extensible frameworks, or more on exemplary tools. Eclipse
+ projects always provide both but may be tailored more toward one
+ or the other. When choosing to use these words, the team should
+ consider that "Framework" and "Tools"
+ mean different things to different people and may even be
+ becoming overused. </li>
+ <li>Top-level projects may optionally include "Platform"
+ instead of "Framework".</li>
+ </ul>
+ </li>
+ <li><b>An optional Nickname.</b> Some teams like to have a clever
+ nicknames, for example "Higgins" or "Buckminister".</li>
+ <li><b>Project Name. </b>The full name includes the optional nickname, e.g., "The
+ Eclipse Component Assembly Project (Buckminister)".</li>
+ <li><b>Acronym.</b> Most descriptive names are sufficiently long
+ that it can be convenient to abbreviate them in some way. For
+ example, the Eclipse Communication Framework shortens to ECF.</li>
+ </ul>
+<
+<h2>Using
+ the Project Name</h2>
+
+Every public use of the project name - in a web page, a presentation, a
+ press release, an article, etc. - should follow these guidelines:
+ <ul>
+ <li>The first use of the Project Name uses the entire Descriptive Name
+ and may include the optional Nickname. For
+ example, "The Eclipse Component Assembly
+ Project (Buckminister)". Subsequent references to the project may use the
+ Nickname, e.g., "Buckminister".</li>
+ <li>If the project is in the Proposal Phase, or is a Technology Project, that fact
+ must be mentioned early in the document. For example, "The proposed
+ Eclipse Phoenix project ..." or "The Buckminister project, a
+ Technology project at Eclipse, is releasing version 0.2 of their framework
+ for early alpha feedback from the community."</li>
+ </ul>
+<p>
+
+<h2>Infrastructure
+ uses of the Project Name</h2>
+
+<b>Newsgroup.<br>
+</b>The project newsgroup name will be <code>eclipse.[toplevel].[shortname]</code>.
+The short name can be an abbreviation of the Descriptive Name, or an Acronym, e.g.,
+eclipse.technology.ecf, or it can be the optional Nickname, e.g.,
+eclipse.technology.buckminister.
+<p><b>Mailing Lists.<br>
+</b>
+New projects typically have a single <code> [shortname]-dev@</code> mailing list. When multiple components are being developed by independent teams, the new project may choose to have additional mailing lists of the form
+<code>[shortname]-[component]-dev@</code>. The short name can be an abbreviation
+of the Descriptive Name, or an Acronym, or the project's optional Nickname.</p>
+<p><b>CVS Components.<br>
+</b> Typical component names are <code>org.eclipse.[shortname].[component]</code>. The
+short name is some variation of the project's Descriptive Name - the Acronym, a
+shortened version, or even the whole name. The project's optional Nickname is <b><i> not</i></b> a valid
+short name for CVS components. For example, org.eclipse.ecf.core and
+org.eclipse.componentassembly.ui are valid component names, but
+org.eclipse.buckminister.internal.connector is not.<br>
+</p>
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
diff --git a/dev_process/proposal-phase.php b/dev_process/proposal-phase.php
new file mode 100644
index 0000000..740dc42
--- /dev/null
+++ b/dev_process/proposal-phase.php
@@ -0,0 +1,168 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Proposal Phase";
+$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>Proposal Phase</h1>
+<p><i>version 017 - August 6, 2005</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>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 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 and communications. Projects in the proposal and
+ validation/incubation stages must use the appropriate watermark on their web
+ pages.
+ </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>1</sup> These graphics and watermarks do not yet exist. They will probably
+be created in 4Q2005.<sup><br>
+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>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/release-review.php b/dev_process/release-review.php
new file mode 100644
index 0000000..39d3884
--- /dev/null
+++ b/dev_process/release-review.php
@@ -0,0 +1,296 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Release Review";
+$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>Release Review</h1>
+<p><i>version 018 - August 7, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Release Review</h2>
+
+<p> The Release Review is conducted before each major release to verify that the key goals of the release have been accomplished and to verify that all intellectual property rights issues have been
+resolved. For Eclipse projects with typical six week milestones, a plausible time for a release review is one to two weeks into the final six week period, i.e., four or five weeks before the release is scheduled to go live.<br>
+<br>
+The Release Review is attended by the EMO, the project leadership, and members of the Eclipse community.
+The Release Review process is described on the <a href="review-mechanisms.php">Review
+Mechanisms page</a>. The remainder of this page discusses the Review's content.<br>
+<br>
+The Release Review is the final review of the project, process, release and most
+importantly, the IP issues, against the characteristics that help ensure
+<a href="eclipse-quality.php"> Eclipse Quality</a>. In this context, Eclipse Quality means extensible frameworks and
+exemplary tools developed in an open, inclusive, and predictable process involving the entire community. We use this definition so that members of the Eclipse community and ecosystem can rely on and use the frameworks and tools in their work and their businesses, including direct use and use as building blocks of commercial products.</p>
+
+ <p>
+ A Release Review is a fairly comprehensive process. We anticipate that
+ gathering the material for the review and preparing the slide is a
+ non-trivial effort, but we believe that the introspection offered by this
+ exercise is useful for the project and that the results are very useful
+ for the community. </p>
+ <p>The items to be covered in the Review include the following. The slide
+ deck will probably average one or two slides on each of these bullets. (Note the use of the
+ word "summarize" throughout this agenda. Judgment must be used
+ to determine how much to include in each of these bullet items. At the
+ project's request, the EMO will help determine the appropriate level of
+ information.) </p>
+<blockquote><span style="background-color: #FFFFCC">Note that during the Release Review, the project leadership will personally
+assert/guarantee the veracity of the statements. The standard is especially high
+ for the IP Issues because the project leadership are the ones who know whether the
+ <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> IP
+Policy</a> has been followed rigorously or not. An obvious consequence of this is
+that the verbal report and written documents of the Release Review should not make statements
+that the project leadership cannot back up with facts.</span> </blockquote>
+ <ul>
+ <li>
+ <b>Features.</b> Summarize the major features of this release as well
+ as any other features that have generated significant discussion
+ amongst the community during the development cycle. Compare the
+ features against the Roadmap to understand the project's conformance
+ or divergence (note: compare against the Project Plan section as the
+ forward looking sections apply to the next release). References to existing New & Noteworthy
+ documentation is a useful addition to this summary.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b> </i>The community will use this release and the
+ ecosystem will build products on top of this release, and both
+ need to know what features were included or excluded.
+ </li>
+ </ul>
+ </li>
+ <li>
+ <b>Non-Code Aspects.</b> Summarize the state of the non-code aspects
+ of the release including: user documentation, localization/externalization, examples,
+ tutorials, articles, and so on. Have the existing artifacts been
+ updated? Are there new artifacts? Have the obsolete ones been retired
+ or at least marked as pertaining only to older material?
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> The non-code aspects are essential for the
+ wide-spread adoption of the release.</li>
+ </ul>
+ </li>
+ <li>
+ <b>APIs.</b> Certify that the APIs in this release are <i><a href="eclipse-quality.php">Eclipse
+ Quality</a></i>. The project's Architecture Council representative will
+ personally certify that the requirements for quality have been met
+ and/or discuss any deficiences.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> Eclipse members build commercial tools on top of
+ the extensible frameworks and thus the quality of the APIs is
+ extremely important.</li>
+ </ul>
+ </li>
+ <li><b>Tool Usability. </b>Summarize the usability of the tools.
+ Usability in this sense is about using the tools to solve development
+ problems, not the more academic sense of UI evaluation/testing.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> Without usable
+ tools, the project will not attract the user community necessary
+ to enable the ecosystem. </li>
+ </ul>
+ </li>
+ <li>
+ <b>Architectural Issues.</b> Summarize the architectural quality of
+ the release. Discuss the <i>intrinsic nature of being extensible</i>
+ embodied by this project. Discuss issues such as unresolved overlap with other
+ projects, unpaid "merge debt" from incorporating various
+ components, and so on.
+ <ul>
+ <li><font color="#0080C0"><b>
+ <i>Reason: </i></b></font>Eclipse members build commercial tools
+ on top of the extensible frameworks and thus the quality of the
+ architecture is important.</li>
+ </ul>
+ </li>
+ <li>
+ <b>End-of-Life.</b> Summarize the features (APIs and any significant
+ user features)
+ from previous releases that are being end-of-life'd in this release.
+ End of life includes both deprecation and actual removal.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> The community builds products that rely on
+ features and so they need to know when these features are
+ changing.</li>
+ </ul>
+ </li>
+ <li>
+ <b>Bugzilla.</b> Summarize the bugzilla situation. How many bug
+ records (defects and enhancements) have been
+ opened/closed/deferred/new, etc? How many P1, P2, ..., bug records are
+ outstanding?
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> Summaries of the bugzilla records offer a glimpse
+ into the project productivity. They also offer an estimate of the
+ outstanding risk. And the summary is used to alert the community
+ to known issues.</li>
+ </ul>
+ </li>
+ <li>
+ <b>Standards.</b> Summarize the standards compliance of this release.
+ If the features are based on defined, pending, or ad-hoc standards,
+ what is the state of those standards and what is the state of the
+ support for those standards in this release.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason: </font></b></i>Eclipse is about building frameworks and tools
+ based on standards, so we need to make sure that we are conforming
+ to the appropriate standards.</li>
+ </ul>
+ </li>
+ <li>
+ <b>Schedule.</b> Discuss the initial schedule and any changes to the
+ schedule over the course of the release, i.e., what the project team
+ achieved. Discuss whether milestones were met or slipped.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> The community relies on consistent schedules from
+ Eclipse so that projects and products can plan for the correct
+ dependencies.</li>
+ </ul>
+ </li>
+ <li>
+ <b>Process.</b> Summarize the project's conformance to the <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
+ Development Process</a> and to <a href="index.php">these guidelines</a>.
+ Has this release been developed using open,
+ transparent, permeable, and inclusive processes? Has this release followed
+ its charter principles? Consider the use of bugzilla, the
+ mailing lists, the newsgroups, conference calls, committer
+ elections/removals, etc.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> It is important for Eclipse projects to build a
+ community around the project, not just deliver code for a project.
+ This review item is about the process of building the community.</li>
+ </ul>
+ </li>
+ <li><b>Communities.</b> Summarize the project's development of its three
+ communities. Consider the interactions on bugzilla, the
+ mailing lists, the newsgroups, public conference calls, blogs, PR
+ activities, code camps, conference tutorials, coordinating with other
+ Eclipse projects and other open source projects (Apache, ObjectWeb,
+ etc), ...
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> It is important for Eclipse projects to build a
+ community around the project, not just deliver code for a project.
+ This review item is about the success of building a community.</li>
+ </ul>
+ </li>
+ <li>
+ <b>IP Issues.</b> As per the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
+ IP Policy</a>, these steps must be done:
+ <ol>
+ <li>The project leadership verifies that:
+ <ul>
+ <li>... that the about files and use licenses are in place as
+ per the <a href="/legal/guidetolegaldoc.php">Guidelines to
+ Legal Documentation</a>.</li>
+ <li>... all contributions (code, documentation, images,
+ etc) has been committed by individuals who are either
+ Members of the Foundation, or have signed the appropriate
+ Committer Agreement. In either case, these are individuals who have
+ signed, and are abiding by, the Eclipse IP Policy. (see below)</li>
+ <li>... that all
+ significant contributions have been reviewed by the Foundation's
+ legal staff. (see below)</li>
+ <li>... that all non-committer code contributions, including third-party libraries, have
+ been documented in the release and reviewed by the Foundation's legal
+ staff (see below)</li>
+ <li>... that all contribution questionnaires have been completed
+ (see below)</li>
+ <li>... the "provider" field of each plug-in is set to
+ "eclipse.org"</li>
+ <li>... the "copyright" field of each plug-in is set to
+ the copyright owner.</li>
+ </ul>
+ </li>
+ <li>The PMC provides a <a href="project-log.php"> Project Log</a> that enumerates:
+ <ol type="a">
+ <li>every piece of third party software including information on
+ the license</li>
+ <li>every major contribution</li>
+ <li>the name of every contributor including
+ non-committer contributions via bug fixes with bug #'s</li>
+ <li>the About files which contain any non-standard terms
+ (e.g., a reference to a license other than the EPL, etc)</li>
+ </ol>
+ </li>
+ <li>The EMO will validate for (a) and (b) that contribution questionnaires
+ have been properly submitted and EMO approvals have been
+ completed.</li>
+ <li>The Project Log is part of the Release Review documentation. It
+ can be included in the slides or as a separate document.</li>
+ </ol>
+ </li>
+ <li><b>IP Issues (II).</b> The EMO explicitly asks during the Release
+ Review if any Member would like to assert that this release infringes
+ their IP rights. If so, the EMO and the project will follow the
+ Eclipse IP Policy in discussions with that Member.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> One of the important benefits that the Eclipse
+ Foundation provides for its members is the consistent application
+ of the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
+ IP Policy</a> which helps ensure (but does not guarantee) that the
+ framework and tools are useable in commercial products. </li>
+ </ul>
+ </li>
+ <li>
+ <b>Project Plan.</b> If there is a Project Plan (full or even a draft)
+ for the next release, the final issue to cover in the Release Review
+ is the unveiling of the new plan.
+ </li>
+ <li>
+ <b>Release Review Version. </b>The slides should include reference to
+ the version of this document the Review is based on.
+ <ul>
+ <li>
+ <i><b><font color="#0080C0">Reason:</font></b></i> The guidelines
+ are continually evolving and a reader in the future will want to
+ know what version of the guidelines were in place when the Release
+ Review was completed. </li>
+ </ul>
+ </li>
+ </ul>
+ <p>Example slide decks can be found in the <a href="/projects/previous-release-reviews.php">Release
+ Review archives</a>. </p>
+ <p>
+ After the public Release Review, the EMO (and, if appropriate, the parent
+ PMC) consider the community feedback and announce the result: </p>
+ <ul>
+ <li>
+ Pass - the review is acceptable and the release should proceed
+ </li>
+ <li>
+ Postpone - issues have arisen that must be solved before the
+ release proceeds
+ </li>
+ <li>
+ Pass w/ Notes - the release has some issues that need to be addressed,
+ but they can be addressed with release notes and/or documentation
+ </li>
+ <li>
+ Pass w/ Issues - the release has some issues, but they can be
+ addressed in a future release as agreed to in the review
+ </li>
+ <li>
+ Fail - there are significant problems with the release and/or the
+ project.
+ </li>
+ </ul>
+<p>After a successful Release Review, the project continues in the <a href="implementation-phase.php">Implementation
+Phase</a>.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/review-mechanisms.php b/dev_process/review-mechanisms.php
new file mode 100644
index 0000000..3c96cd5
--- /dev/null
+++ b/dev_process/review-mechanisms.php
@@ -0,0 +1,66 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Review Mechanisms";
+$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>Review Mechanisms</h1>
+<p><i>version 014 - July 26, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Creation, Checkpoint, and Release Reviews</h2>
+<p>Phases end with Reviews. For each Review, the project leadership makes a presentation to the review committee as well as any interested Eclipse
+members. Their are a number of guidelines/requirements for the presentation
+slides:</p>
+<ul>
+ <li>The presentation slides must be posted to the project website at least one
+ week, preferably two weeks, in advance. For proposals, the slides must be
+ provided to the EMO for posting with the proposal.
+ <ul>
+ <li>If the project posts the slides, the URL is to be emailed to the EMO
+ for reference from other eclipse.org pages.</li>
+ <li>If the project posted the slides, a copy of the current version is to
+ be emailed to the EMO after the review for archiving.</li>
+ </ul>
+ </li>
+ <li>The presentation slides must be available on the website in a format that
+ anyone in the membership can review. For example, PowerPoint is not an
+ acceptable single format - it can be one of the formats available, but not
+ the only one. For a single format, please use PDF. </li>
+ <li>The presentation slides should have page numbers to allow the attendees to
+ follow along.</li>
+ <li>The slides are not authored by the Eclipse Foundation - they are authored
+ by a project lead, or a project lead employed by a company - and thus the
+ footer of the slides should make the authorship clear.</li>
+ <li>The slides must be licensed under the EPL.</li>
+</ul>
+<p>All Reviews are announced by the EMO on <a href="/projects/">the Eclipse
+website</a>.</p>
+<p>Unless otherwise specified, Reviews are held as conference calls -
+the EMO will provide a call-in number. The project team can utilize other
+mechanisms (e.g., web conferencing) at its own expense as long as those
+mechanisms are available to all the attendees without additional costs to the
+attendees.</p>
+
+<h3>Archival Quality</h3>
+<p>The Review presentations are archived on the Eclipse website (Creation
+Reviews are <a href="/proposals/">archived with their proposal</a>,
+Checkpoint and Release Reviews <a href="/projects/previous-release-reviews.php">are
+archived</a>). Eclipse members may not be able to attend the Review conference
+calls for a variety of reasons including that the member did not become a member
+until after the Review occurred - in spite of this, the members still need to
+have access to the Review presentations. Thus the presentation slide decks need
+to be more than just slide decks: they need to be archival quality documents
+that are comprehensible and complete on their own.</p>
+<p>What this means to presentation authors is that the slide deck needs to have
+more detail than a normal face-to-face meeting presentation would usually have.
+Specific facts, numbers, dates, etc.</p>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/status-and-planning-reporting.php b/dev_process/status-and-planning-reporting.php
new file mode 100644
index 0000000..3728412
--- /dev/null
+++ b/dev_process/status-and-planning-reporting.php
@@ -0,0 +1,234 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Status and Planning Reporting";
+$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>Status and Planning Reporting</h1>
+<p><i>version 019 - August 8, 2005</i></p>
+<p><a href="index.php">[This is one page of the larger document.]</a></p>
+<h2>Status and Planning Reporting</h2>
+
+<p>The goal is to have a mostly-automated planning and reporting system for Eclipse
+projects that:</p>
+<ul>
+ <li>Replaces the static HTML quarterly status reports with an machine-processed
+ XML file</li>
+ <li>Reduces each project's overhead of keeping this information up-to-date</li>
+ <li>Automatically reminds project leaders when the information needs refreshing</li>
+ <li>Publishes information on eclipse.org web pages. <br>
+ For example,
+ the <a href="/projects/timeline/">prototype
+ master timeline</a> has been useful - we can imagine other useful reports
+ like that.</li>
+</ul>
+<h2>File Format</h2>
+<p>Each project will have an <code>eclipse-project-status.xml</code> file in its
+root web directory.</p>
+<p><code><project><br>
+ <name></code><i>project name</i><code></name><br>
+ <short-name></code><i>project short name</i><code></short-name><br>
+</code>The project name is the long name (Test and Performance Tools Platform)
+and the short name is the abbreviation (TPTP).<code><br>
+<br>
+ <url></code><i>project home url</i><code></url><br>
+</code>Obviously, the home page for the project.</p>
+<p><code> <summary></code><i>executive summary of current status</i><code></summary><br>
+</code>This is one of the more important items: the project status summary for
+the membership-at-large. A couple of honest paragraphs about what is happening
+in the project, the challenges and the plans.</p>
+<p><code> <description url="</code><i>url of project description</i><code>"/><br>
+ <description></code><i>description of project</i><code></description><br>
+</code>The project description might already exist on the project website, and
+thus it can be referenced by url or included directly here.</p>
+<p><code> <shipping><br>
+ <release url="</code><i>download url 1</i><code>"></code><i>description
+1</i><code></release><br>
+ <release url="</code><i>download url 2</i><code>"></code><i>description
+2</i><code></release><br>
+ ...<br>
+ </shipping><br>
+ <shipping url="</code><i>download page url</i><code>" aname="Latest
+Releases"/><br>
+</code>The latest releases that are currently shipping.</p>
+<p>The first format is an XML version of the "Latest Releases" section
+of download pages like <a href="http://download.eclipse.org/eclipse/downloads/index.php">this
+one</a>; the second is a direct reference to the download pages. In the second
+format, the tools will use this algorithm to automatically extract the shipping
+information:</p>
+<ol>
+ <li>read the download page url</li>
+ <li>search for the matching <code><a name="..."></code></li>
+ <li>from there, search for <code><a href></code>s and extract
+ description and download urls. The <a href>s will only match if the
+ description matches the Perl regular expression .*\d+\.\d+.* - in other
+ words, there has to be at least a digit-dot-digit version number in the
+ description. It will ignore descriptions that match \d+\.\d+M\d+ and \d+\.\d+RC\d
+ (milestone and release candidate builds).</li>
+ <li>the search will end at the first <code></table></code>, <code></ul></code>,
+ or <code></ol></code></li>
+</ol>
+<p>This second format should work with these download page formats:</p>
+<ul>
+ <li><a href="http://download.eclipse.org/birt/downloads/">BIRT</a></li>
+ <li><a href="http://download.eclipse.org/tools/emf/scripts/downloads.php">EMF</a></li>
+ <li><a href="http://download.eclipse.org/tools/gef/downloads/index.php">GEF</a></li>
+ <li><a href="http://download.eclipse.org/eclipse/downloads/index.php">Platform</a></li>
+ <li><a href="http://download.eclipse.org/tools/ve/downloads/index.php">VE</a></li>
+ <li><a href="http://www.eclipse.org/webtools/downloads.html">WebTools</a></li>
+</ul>
+<p>It will sort-of work with these download page formats:</p>
+<ul>
+ <li><a href="http://download.eclipse.org/tools/uml2/scripts/downloads.php">UML2</a>
+ - the maintenance builds are not numbered 1.1.1 in the <a href>
+ description, thus the maintenance builds will not show up in the list.</li>
+</ul>
+<p>It does not appear to work with these download page formats:</p>
+<ul>
+ <li><a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/downloads/main.html?cvsroot=Tools_Project">CDT</a>
+ - cannot determine which are releases and which are development builds</li>
+ <li><a href="http://www.eclipse.org/tptp/home/downloads/downloads.html">TPTP</a>
+ - no version numbers</li>
+</ul>
+<p><code> <releases include-in-parent="true"><br>
+ <milestone status="tentative|scheduled|completed"><br>
+ <date></code><i>date</i><code></date><br>
+ <plan format="defacto1"></code><i>optional planning or status url</i><code></plan><br>
+ <download></code><i>optional download url</i><code></download><br>
+ <name></code><i>name</i><code></name><br>
+ </milestone><br>
+ ...<br>
+ <release
+status="tentative|scheduled|completed"><br>
+ <date></code><i>date</i><code></date><br>
+ <plan format="defacto1"></code><i>optional planning or status url</i><code></plan><br>
+ <download></code><i>optional download url</i><code></download><br>
+ <name></code><i>name</i><code></name><br>
+ </release><br>
+ ...<br>
+ </releases><br>
+</code>The releases being planned and worked on. Obviously there should be a
+<shipping> entry for all <completed> releases. If this project does
+not ship separately (e.g., the JDT ships as part of the Platform), then there
+should be a <releases include-in-parent="true"> tag; otherwise
+include-in-parent should be excluded or set to "false".</p>
+<p> The date can be any of these levels of
+precision (It is not possible to be more specific than a day nor vaguer than a
+quarter):</p>
+<ul>
+ <li>DD/MM/YYYY - for a specific day, e.g., 22/03/2005</li>
+ <li>MM/YYYY - for a specific month, e.g., 10/2005</li>
+ <li>NQYYYY - for a quarter, e.g., 3Q2005</li>
+</ul>
+<p>If the optional planning document URL is in one of the supported formats and
+the plan format is declared, the tools can extract the themes and priorities and
+bug numbers for summary in the Roadmap Summary (see below).</p>
+<ul>
+ <li><code>plan format="defacto1"</code> - the defacto Eclipse
+ project planning format as specificed-by-example by the Platform team (e.g.,
+ <a href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html">the
+ Platform 3.1 plan</a>)</li>
+</ul>
+<p><code> <project-ip-log url="</code><i>url</i><code>"/><br>
+</code>URL to the <a href="project-log.php"> project's IP log</a>. This is an
+absolutely required component, although it could reference it's parent's log.</p>
+<p><code> <community><br>
+ <mailing-list></code><i>list name</i><code></mailing-list><br>
+ ...<br>
+ <newsgroup></code><i>newsgroup name</i><code></newsgroup><br>
+ ...<br>
+ <bugzilla></code><i>product</i><code></bugzilla><br>
+ <bugzilla></code><i>product:component</i><code></bugzilla><br>
+ ...<br>
+ <blog></code><i>blog url</i><code></blog><br>
+ ...<br>
+ <cvs></code><i>cvs repository path</i><code></cvs><br>
+ ...<br>
+ </community><br>
+</code>List of the project's community communication and information artifacts.
+Mailing lists such as ptp-dev@eclipse.org, newsgroups such as
+eclipse.technology.alf, bugzilla categories such as <code>AspectJ</code> or <code>AspectJ:Compiler</code>,
+blogs, and the Eclipse CVS repository paths. In the future we might add other
+artifacts like wikis, forums, del.icio.us tags, and so on. This list should be
+as complete as possible, thus if the project has multiple mailing lists (e.g.,
+birt-dev@eclipse.org and birt-pmc@eclipse.org), both should be listed (in
+separate <mailing-list> lines). CVS repository paths can be singular
+(e.g., <code>dev.eclipse.org:/home/tools/gef-home</code>) or wild-card (e.g., <code>dev.eclipse.org/home/tools/org.eclipse.gef*</code>).</p>
+<p><code></project></code></p>
+<h2>Other Information</h2>
+<p>Other information that is considered part of the project status and planning
+reports, but which is stored in other places includes:</p>
+<ul>
+ <li>The project leaders and their contact information - stored in the
+ Foundation's database.</li>
+ <li>The project committers - stored in the Foundation database.</li>
+ <li>Non-EPL licensed software included in a release - to be stored in a
+ separate project log file.</li>
+</ul>
+<h3>Web Services Interface</h3>
+<p>In the future, there will be a web services interface to the Eclipse project
+information. We envision a simple interface that returns an XML response which
+is the merger of the <code>eclipse-project-status.xml</code> file and the other
+project information listed above. Tools will be able to use the web service
+interface for consistent access to the information regardless of where it is
+stored.</p>
+<h2>Reports</h2>
+<p>Here are a number of initial reports to be generated from this information:</p>
+<ol>
+ <li>
+ <p align="left"><b>Release Timeline. </b>Like the <a href="/projects/timeline/">prototype
+ master timeline</a>. The master timeline will not include Technology
+ projects (or, in the future, Research projects) on the theory that
+ Technology projects are not "major Eclipse projects".</li>
+ <li>
+ <p align="left"><b>Milestone Timeline.</b> Same thing, but showing all the
+ milestones as well. It will be big and probably fairly cluttered.</li>
+ <li>
+ <p align="left"><b>Quick Reference. </b>A one-page per project summary of
+ all the projects. Useful for printing and flipping through on an airplane
+ trip.</li>
+ <li><b>Validity.</b> A report showing the "up-to-dateness" status of
+ each project's eclipse-project-status.xml file. Green for up-to-date. Yellow
+ for up to 30 days out of date. Red for 30-90 days out of date. Red with
+ underlines and bold for more than 90 days out of date. Black
+ "MISSING" if the file does not exist.</li>
+ <li><b>Atom Feed.</b> Change notifications.</li>
+ <li><b><a name="Roadmap Summary">Roadmap Summary</a>.</b> A report that shows
+ the Themes and Priorities from the Roadmap and summarizes the collective
+ projects' contributions to those Themes; in other words, collections of bug
+ numbers and their status, sorted by Theme.</li>
+</ol>
+<h2>Updating</h2>
+<p>The Eclipse Development Process requires this information to be current each quarter. Current
+is defined as:</p>
+<ol>
+ <li>modified within the last three weeks of the quarter</li>
+ <li>has an executive summary that is different than last quarter's executive summary</li>
+ <li>has all the required sections and proper formatting of dates, etc.</li>
+</ol>
+<p>There will be an automated reminder email. The email will include why the
+automated program is sending you this email, e.g., "hasn't been
+updated" or "date field '27-Jan-2006' is not in DD/MM/YYYY or MM/YYYY
+or NQYYYY date format", etc.</p>
+<ul>
+ <li>At T-3 weeks, an email will be sent to each project leader reminding them to update
+ the eclipse-project-status.xml file.</li>
+ <li>At T-2 weeks, if the file has not been modified, a second reminder will be
+ sent.</li>
+ <li>At T-1 week, if the file has not been modified, a third reminder will be
+ sent and it will be cc'd to the EMO.</li>
+ <li>At T-0 weeks, if the file has not been modified, two weeks worth of every
+ other day reminders will be sent.</li>
+ <li>At T+2 weeks, a final email will be sent to the project leader and to the
+ EMO saying something like "robo-emailer is giving up".</li>
+</ul>
+
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
diff --git a/dev_process/validation-phase.php b/dev_process/validation-phase.php
new file mode 100644
index 0000000..78902e5
--- /dev/null
+++ b/dev_process/validation-phase.php
@@ -0,0 +1,235 @@
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");
+
+$pageTitle = "Validation Phase";
+$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>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 "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."
+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, and inclusive 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
+ "openness". The project leadership must go out of its way to
+ encourage and nurture new contributors. 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. </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 "learning the
+ropes" 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>. 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. 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 "how should we use Bugzilla
+effectively?". 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 and communications. Projects in the proposal and
+ validation/incubation stages 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 "gets the Eclipse way".
+ <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. 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>1</sup> These graphics and watermarks do not yet exist. They
+will probably be created in 4Q2005.<sup><br>
+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>
+<?php
+ include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
+?>
\ No newline at end of file
