Update the handbook and clean up the directory (at least a little).
diff --git a/handbook/eclipse.book.xml b/handbook/eclipse.book.xml
deleted file mode 100644
index 546c628..0000000
--- a/handbook/eclipse.book.xml
+++ /dev/null
@@ -1,2254 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?asciidoc-toc?>
-<?asciidoc-numbered?>
-<book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-<info>
-<title>Eclipse Project Handbook</title>
-<date>2015-08-18</date>
-</info>
-<preface>
-<title></title>
-<simpara>Copyright © 2015 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0</simpara>
-</preface>
-<chapter xml:id="preamble">
-<title>Overview</title>
-<simpara>This document provides you with the information that you need to
-create a new Eclipse open source project or become a committer
-on an existing one.</simpara>
-<simpara>The <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link> (EDP) is the foundational
-document for Eclipse projects and committers. It describes the
-manner in which we do open source software. The Eclipse Development
-Process does not prescribe any particular development methodology;
-it is more concerned with the larger-scale aspects of open source
-project lifecycle, including such things as reviews, processes for
-running votes and elections, bringing new committers onto a project, etc.
-This document will elaborate on some key points of the Eclipse Development
-Process.</simpara>
-<section xml:id="preamble-principles">
-<title>Principles</title>
-<simpara>Four basic principles lie at the heart of the Eclipse Development Process:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Transparency;</simpara>
-</listitem>
-<listitem>
-<simpara>Openness;</simpara>
-</listitem>
-<listitem>
-<simpara>Meritocracy; and</simpara>
-</listitem>
-<listitem>
-<simpara>Vendor neutrality</simpara>
-</listitem>
-</itemizedlist>
-<simpara>We refer to the first three as the "open source rules of engagement".</simpara>
-<simpara>To operate with <emphasis role="strong">transparency</emphasis>, a project’s discussions, minutes, deliberations,
-project plans, plans for new features, and other artifacts are open, public,
-and easily accessible.</simpara>
-<simpara><emphasis role="strong">Openness</emphasis> at Eclipse means quite a lot more than "open book" (which is
-really a synonym for transparent). The project 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 include, of course, direct competitors in the marketplace.</simpara>
-<simpara>Eclipse is a <emphasis role="strong">meritocracy</emphasis>. The more that somebody contributes, the more
-responsibility they will earn. A pattern of quality contribution to a project
-may lead to an invitation to join the project as a committer. Leadership roles
-in Eclipse are also merit-based and earned by peer acclaim. Merit must be
-demonstrated in publicly-accessible forums. Committers and project leads are
-added to a project via <link linkend="elections">election</link>.</simpara>
-<note>
-<simpara>Employment status has no bearing at whether or not somebody can participate
-in an open source project at Eclipse. Employment does not guarantee
-committer status; committer status must be earned by everybody.</simpara>
-</note>
-<simpara><emphasis role="strong">Vendor neutrality</emphasis> is similar to openness in that it’s concerned with
-maintaining a level playing field. No vendor is permitted to dominate a project,
-and nobody can be excluded from participating
-in a project based on their employment status. While
-project resources will contain copyright statements that assert ownership of
-various assets by individual vendors, the project itself must remain vendor
-neutral.</simpara>
-<simpara>Quality and intellectual property cleanliness are also important principles.</simpara>
-<simpara><emphasis role="strong">Quality</emphasis> 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
-are cool/compelling to use, indicative of what is possible) and ready for
-use by adopters. 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.</simpara>
-<simpara><emphasis role="strong"><link linkend="ip">Intellectual property</link></emphasis> (IP) is any artifact that is made available from
-a Eclipse server (this includes source code management systems, the website,
-and the downloads server). Artifacts include (but are not limited to) such things
-as source code, images, XML and configuration files, documentation, and more.
-Strict rules govern the way that we manage IP and your responsibilities
-as a committer.</simpara>
-<simpara>Code produced by an Eclipse project is used by organizations to build products.
-These adopters of Eclipse technology need to have some assurance that the IP they’re
-basing their products on is <emphasis role="strong">clean</emphasis>: the organization or individuals who claim
-copyright of the code are the legitimate copyright holders, and the copyright
-holders legitimately agree to make the code available under the license(s) that
-the project works under. As a committer, you must be careful that you do not copy
-code and inadvertently claim it as your own.</simpara>
-</section>
-</chapter>
-<chapter xml:id="starting">
-<title>Starting an Open Source Project at Eclipse</title>
-<simpara>Eclipse open source projects start with a proposal that is made
-available to the community for review. At the end of the <emphasis>community
-review</emphasis> period, we engage in a <emphasis>creation review</emphasis>, and then
-provision the project resources.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/project-creation.png"/>
-</imageobject>
-<textobject><phrase>An overview of the Project Creation Process</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Use the <link xlink:href="https://projects.eclipse.org/node/add/project-proposal">web form</link> to create a new project proposal.
-Instructions are provided on the form. All new proposals are created
-in <emphasis>draft</emphasis> mode, and are accessible only by the original author and
-anybody designated as a project lead or committer in the proposal.
-Only those individuals designated as a project lead may edit the
-proposal.</simpara>
-<note>
-<simpara>Keep track of the URL of the proposal. We do not provide
-public links to the document until after the proposal is opened for
-community review.</simpara>
-</note>
-<simpara>A proposal must minimally include a description of the project, a
-declaration of scope, and a list of prospective members (project
-leads and committers) before we make it accessible to the public
-for <emphasis>community review</emphasis>.</simpara>
-<simpara>When you feel that the proposal is ready, send a note to
-the Eclipse Management Organization (EMO) at <link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link> requesting that
-the proposal be made available to the public for review. The EMO
-will review the proposal and may provide feedback before initiating
-the <emphasis>community review</emphasis> period.</simpara>
-<simpara>At the beginning of the <emphasis>community review</emphasis> period, the EMO will
-announce the proposal on several channels (the <link xlink:href="http://www.eclipse.org/projects/project_activity.php">Project
-Activity News</link> page, Twitter, the
-<link xlink:href="http://www.eclipse.org/forums/eclipse.proposals">Proposals Forum</link>, blog post, and an email note
-to the Eclipse Foundation members and committers). The EMO will
-also open an record in the Eclipse Foundation’s issue tracker—​an
-instance of Bugzilla—​to track the progress of the proposal;
-the proposal’s author and project leads will be copied on that record.</simpara>
-<simpara>A proposal will be open for community review for a minimum of two
-weeks.</simpara>
-<simpara>The Eclipse Foundation holds the <emphasis>trademark</emphasis> for all Eclipse projects.
-Trademark assignment is undertaken prior to the creation of any new
-project. If you already have a trademark on your project name, that
-trademark must be assigned to the Eclipse Foundation. Be advised that
-trademark assignment can be a time-consuming process (it can take hours,
-days, or weeks depending on the circumstances surrounding the name).
-If you currently hold the trademark, you will be asked to complete a
-<link xlink:href="http://eclipse.org/legal/Trademark_Transfer_Agreement.pdf">Trademark Transfer Agreement</link>.</simpara>
-<simpara>The proposal must list two mentors from the Architecture Council.
-Members of the Architecture Council have considerable experience with
-Eclipse Foundation practices, and the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>.
-If you are already in contact with mentors who agree to help you with
-your project, please do list them in the proposal. Otherwise, the
-EMO will engage directly with the Architecture Council to identify
-mentors as necessary. Mentors are available to the project through the
-incubation phase; they are released from their duties when the project
-<link linkend="release-graduation">graduates</link>.</simpara>
-<simpara>When the project name trademark has been secured, mentors have been
-identified, and the proposal contents are finalized, the EMO will schedule
-a <emphasis>creation review</emphasis>. Reviews—​which run for a minimum of one week—​are
-scheduled twice a month, generally concluding on the first and third
-Wednesday of each month. The creation review may overlap with the
-<emphasis>community review</emphasis> period.</simpara>
-<note>
-<simpara>Creation reviews tend to always be successful. They should be
-considered low stress as the hard work has already been done in
-advance of the start of the review.</simpara>
-</note>
-<simpara>Following the creation review, the EMO will initiate the provisioning process.
-To gain committer status, some <link linkend="paperwork">committer paperwork</link> must be completed
-as part of the provisioning process. The exact nature of that
-paperwork depends on several factors, including the employment status
-of the individual and the Eclipse Foundation membership status of their employer.</simpara>
-<note>
-<simpara>If you can be ready with the paperwork in time for the completion of the
-creation review, then we can move quickly through the provisioning process.
-When we initiate provisioning, committers will be sent an email with
-instructions; please don’t send any paperwork in until after you receive
-those instructions.</simpara>
-</note>
-<section xml:id="starting-after-provisioning">
-<title>After Provisioning</title>
-<simpara>The Webmaster will send a note announcing the completion of the provisioning
-process. Before you commit any code into your project repository, you must
-submit your project’s <link linkend="ip-initial-contribution"><emphasis>initial contribution</emphasis></link> and
-list of third-party libraries for review by the IP team.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/post-creation.png"/>
-</imageobject>
-<textobject><phrase>Post creation activities</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Do not commit any code to your project’s source code repository until after
-you receive approval for the IP Team. Once you’ve received that approval,
-you can do builds and produce milestones for your first release. You must
-wait until after the IP Team has approved your initial contribution and use
-of third-party libraries before you do any official <link linkend="release">releases</link>.</simpara>
-</section>
-<section xml:id="starting-project-phases">
-<title>Project Phases</title>
-<simpara>All new projects start in the <emphasis>incubation phase</emphasis> (a project in the
-incubation phase is said to be <emphasis>incubating</emphasis>). The classification of
-a project in the incubation phase is not a statement about the quality
-of the project’s code; rather, incubation phase is more about the
-project team’s progress in practicing the open and public processes
-necessary to establish the three communities (developers, adopters,
-and users) around the project.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Egg-incubation.png"/>
-</imageobject>
-<textobject><phrase>The Incubation Logo</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>In order to alert potential consumers of the incubating nature,
-projects in the incubation phase must include <emphasis>incubation branding</emphasis>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Display the incubation logo on their project web page (if they have one);</simpara>
-</listitem>
-<listitem>
-<simpara>Displays the incubation logo on their project’s primary download page;</simpara>
-</listitem>
-<listitem>
-<simpara>Include the word "incubation" in the filename of all downloadable
-files (when technically feasible) for builds and milestones;</simpara>
-</listitem>
-<listitem>
-<simpara>When technically feasible, include the word "incubation" in features
-(e.g. about dialogs, feature lists, and installers).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>There are no incubation branding requirements for general
-user interface elements.</simpara>
-<simpara>For projects that produce OSGi artifacts, include the word
-"incubation" in the <emphasis>Bundle-Name</emphasis>, feature names, and p2 repositories.</simpara>
-<note>
-<simpara>The word "incubation" should not be included in technical
-namespaces (especially when it may result in confusion when the project
-leaves incubation). e.g. an OSGi bundle’s <emphasis>Bundle-SymbolicName</emphasis>, or a
-Java package name.</simpara>
-</note>
-<simpara>Incubating projects that correctly conform to the incubation branding
-rules outlined above may take advantage of the <link linkend="ip-parallel-ip">Parallel
-IP Process</link>. They are encouraged to produce milestone builds, make
-releases, and grow their community.</simpara>
-<simpara>When the project code is ready (e.g. stable APIs) and the project team
-has learned to operate as an open source project according to the
-Eclipse Development Process, the project may opt to <emphasis>graduate</emphasis> into
-the <emphasis>mature phase</emphasis>.</simpara>
-<simpara>Most of the lifetime of an Eclipse project is spent in the mature phase.
-A mature project is one that is a good open source citizen with open,
-transparent, and meritocractic behavior. The project is regularly
-and predictably releasing IP clean extensible frameworks and
-exemplary tools. The project is actively nurturing the three
-communities: developers, adopters, and users.</simpara>
-</section>
-<section xml:id="starting-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>How do I find Architecture Council mentors? </simpara>
-</question>
-<answer>
-<simpara>You don’t have to find them yourself. Focus on the content of the
-proposal. We can solicit mentors from the Architecture Council after
-the proposal has been opened for community review.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I change the proposal after it is posted? </simpara>
-</question>
-<answer>
-<simpara>Yes. The proposal can be changed any time before the start of the
-start of the creation review.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>When do I submit my code for review by the IP team? </simpara>
-</question>
-<answer>
-<simpara>Submit your code (initial contribution) for review after the project
-has been provisioned. The Eclipse Webmaster will let you know via
-email when provisioning is complete.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Does the new project have to use Git? </simpara>
-</question>
-<answer>
-<simpara>Yes. Git is the only source code management system that is currently
-permitted for new projects.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I host my project code on GitHub? </simpara>
-</question>
-<answer>
-<simpara>New projects can make use of <link linkend="resources-github">GitHub</link>. Official project repositories
-must be moved under the <link xlink:href="https://github.com/eclipse">Eclipse Organization</link> at GitHub.
-Official repositories are subject to the same intellectual
-property due diligence rules and processes that all Eclipse project
-repositories must follow.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How long should I let my project incubate? </simpara>
-</question>
-<answer>
-<simpara>It depends. Community expectations are one factor. Team experience
-with open source is another. If your team is new to open source,
-it may make sense to stay in incubation a little longer than a
-seasoned team with a mature code base might. As a general rule,
-though, projects should plan to leave incubation within a year.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Does the mature project code that I’m bring to Eclipse need to incubate? </simpara>
-</question>
-<answer>
-<simpara>Yes. All new projects start in the incubation phase. Remember
-that incubation is as much about the project team learning about
-how to operate as an open source project as it is about the
-project code. Project teams that "get it" can opt to exit
-incubation quickly (e.g. with their first release) if that
-makes sense for the team and the community.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What do all these terms (e.g. EMO) mean? </simpara>
-</question>
-<answer>
-<simpara>Please see the <link linkend="glossary">glossary</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="project-resources-and-services">
-<title>Project Resources and Services</title>
-<simpara>Open source projects at the Eclipse Foundation are required to make use
-of certain Eclipse Foundation services:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>All project issues must be tracked in the <link xlink:href="https://bugs.eclipse.org/bugs">Eclipse Bugzilla</link>
-instance;</simpara>
-</listitem>
-<listitem>
-<simpara>Source code must be maintained in source code repositories assigned to the
-project (e.g. an Eclipse <link xlink:href="https://git.eclipse.org/c">Git</link> or <link xlink:href="https://git.eclipse.org/r">Gerrit</link> instance,
-or the <link xlink:href="https://github.com/eclipse">Eclipse Organization</link> on GitHub);</simpara>
-</listitem>
-<listitem>
-<simpara>All third-party libraries used by the project must be tracked and
-approved for use by the Eclipse IP Team;</simpara>
-</listitem>
-<listitem>
-<simpara>Downloads must be distributed via a forge-specific downloads server;</simpara>
-</listitem>
-<listitem>
-<simpara>Developer (committer) communication must occur in the <emphasis>dev</emphasis> list
-provided to the project by the Eclipse; and</simpara>
-</listitem>
-<listitem>
-<simpara>Projects must keep their <link linkend="pmi-metadata">Project Metadata</link> up-to-date.</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="resources-source">
-<title>Source Code Management</title>
-<simpara>Your project must maintain source code in the repositories assigned to the
-project by the Eclipse Foundation. These official repositories must be
-the exclusive source of all project code delivered via the project’s assigned
-distribution channel (e.g. the download server).</simpara>
-<simpara>In order for your project to operate in an <emphasis>open</emphasis> manner, it must be possible
-for potential contributors to have access to the code base in its most current
-form, so all ongoing development must be regularly pushed to these canonical
-repositories.</simpara>
-<section xml:id="resources-cla">
-<title>Contributor License Agreement (CLA)</title>
-<simpara>The Eclipse Foundation has implemented <link xlink:href="https://www.eclipse.org/legal/CLA.php">Contributor License Agreements</link> (CLA)
-to improve <link linkend="ip">intellectual property</link> (IP) management and workflow. All
-contributors, who are not committers on the Eclipse project, must sign the CLA.</simpara>
-<simpara>You do <emphasis role="strong">not</emphasis> require a CLA to contribute to a project on which you have committer
-status.</simpara>
-</section>
-<section xml:id="resources-commit">
-<title>Git Commit Records</title>
-<simpara>Git commit records are required to take a specific form. The credentials
-of the actual author must be used to populate the <literal>Author</literal> field. The email
-address used must match the email address that the Eclipse Foundation has
-on file for the author (case-sensitive).</simpara>
-<simpara>The commit message is divided into three sections:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>One line (max 72 characters) summary;</simpara>
-</listitem>
-<listitem>
-<simpara>Description; and</simpara>
-</listitem>
-<listitem>
-<simpara>Footer.</simpara>
-</listitem>
-</orderedlist>
-<formalpara>
-<title>Example Git Commit Record</title>
-<para>
-<screen>commit d6cf52411377a039fc2906378711091a26e932cb
-Author: Some Body <somebody@somewhere.com> <co xml:id="CO1-1"/>
-Date: Wed May 29 16:17:36 2013 +0200
-
- Bug 350686 - Hide unwanted action bar items <co xml:id="CO1-2"/>
-
- This change hides unwanted 'Link with Editor' and
- 'Customize View...' items from the local toolbar
- and the view menu.
-
- Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 <co xml:id="CO1-3"/>
- Also-by: Some Bodyelse <somebodyelse@nowhere.com> <co xml:id="CO1-4"/>
- Signed-off-by: Some Body <somebody@somewhere.com> <co xml:id="CO1-5"/></screen>
-</para>
-</formalpara>
-<calloutlist>
-<callout arearefs="CO1-1">
-<para>The email address of the author must match the email address on the Eclipse Foundation account.</para>
-</callout>
-<callout arearefs="CO1-2">
-<para>Best practice: include the bug id in the commit message summary.</para>
-</callout>
-<callout arearefs="CO1-3">
-<para>Gerrit change id (only when pushing to Gerrit for review).</para>
-</callout>
-<callout arearefs="CO1-4">
-<para>Additional authors can be added using <literal>Also-by</literal> entries.</para>
-</callout>
-<callout arearefs="CO1-5">
-<para>Non-committers must <emphasis>sign-off</emphasis> the commit using the same email address as used in the author field.</para>
-</callout>
-</calloutlist>
-<simpara>The <emphasis>summary</emphasis> line is used in many places where Git commits are listed, ensure
-that this line is sensible by itself. The <emphasis>description</emphasis> area should be used to provide
-more detail about the commit. The footer area is used for extra fields and values.</simpara>
-<simpara>If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx")
-Gerrit Code Review will automatically add a link in the
-corresponding Bugzilla record back to the Gerrit record (this, of course, only
-applies to commits pushed to Gerrit).</simpara>
-<simpara>The <literal>Change-Id</literal> is used by <link linkend="resources-gerrit">Gerrit Code Review</link> to associate new versions
-of a change back to its original review. This field need only be specified if the
-repository is managed by Gerrit.</simpara>
-<simpara>Create a separate <literal>Also-by</literal> field for each additional author of a commit. This might
-apply, for example, if a commit has been authored via pair-programming, or the commit
-is the result of collapsing multiple commits authored by multiple developers.</simpara>
-<simpara>Commits that are provided by non-committers must have a <literal>Signed-off-by</literal> field in the
-footer indicating that the author is aware of the terms by which the contribution has been
-provided to the project. The non-committer must additionally have an Eclipse Foundation
-account and must have a signed <link linkend="resources-cla">Contributor License Agreement</link> (CLA)
-on file.</simpara>
-</section>
-<section xml:id="resources-git">
-<title>Git</title>
-<simpara>Those projects that want to use Git on the Eclipse forge, are assigned a
-directory in which they may create as many Git repositories as required.
-<link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Git">Open a bug</link> to request that the Webmaster create a new Git
-repository for your project. Alternatively, committers with shell accounts
-can create repositories themselves.</simpara>
-<formalpara>
-<title>Create a new Git repository</title>
-<para>
-<screen>> initrepo /gitroot/project/org.eclipse.repo.name.git</screen>
-</para>
-</formalpara>
-<simpara>For consistency, the name of the repository must end with <literal>.git</literal>.</simpara>
-<simpara>To set the description of the repository, use <literal>sftp</literal> or <literal>scp</literal> to copy a text file to
-<literal>/gitroot/project/org.eclipse.repo.name.git/description</literal>. Git repository
-descriptions should be limited to a paragraph of one or two sentences.</simpara>
-<simpara>Only project committers can push to an Eclipse Git repository. A push
-that includes commits that do not conform to the required form will be rejected.</simpara>
-<simpara>You can <link xlink:href="https://git.eclipse.org/c">browse Eclipse repositories</link> directly on the Git server.</simpara>
-</section>
-<section xml:id="resources-gerrit">
-<title>Gerrit Code Review</title>
-<simpara><link xlink:href="https://www.gerritcodereview.com/">Gerrit</link> provides web based code review and
-repository management for the Git version control system. Many projects use
-Gerrit to reduce barriers and encourage contribution to the project.
-<link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Gerrit">Open a bug</link> to request that the Webmaster configure your
-Git repository for Gerrit.</simpara>
-<simpara>Commits may be pushed directly to the Git repository through Gerrit by
-a project committer (e.g. to the <literal>master</literal> branch).</simpara>
-<simpara>Anybody can push to a <literal>refs/for/*</literal> branch for review in a Gerrit repository. A push
-that includes commits that do not conform to the required form will be rejected.
-Commits intended for review should have a
-<link xlink:href="https://git.eclipse.org/r/Documentation/user-changeid.html"><literal>Change-Id</literal></link></simpara>
-<simpara>You can <link xlink:href="https://git.eclipse.org/r">browse Eclipse repositories</link> directly on the Gerrit
-server.</simpara>
-</section>
-<section xml:id="resources-github">
-<title>GitHub</title>
-<simpara>Projects may opt to move some or all of their canonical source code repositories to the
-<link xlink:href="https://github.com/eclipse">Eclipse organization</link> on GitHub.</simpara>
-<note>
-<simpara>Projects that host source code on GitHub are not permitted to use GitHub
-Issues or Wiki.</simpara>
-</note>
-<simpara><link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=GitHub">Open a bug</link> to request that the Webmaster create a new, or move
-an existing, Git repository for your project. The Webmaster will install some
-<emphasis>hooks</emphasis> on your GitHub repository.</simpara>
-<simpara>The <emphasis>Committers hook</emphasis> grants designated project committers write access to the
-GitHub-hosted project repositories. Project committers must use the email address they
-provide to the Eclipse Foundation as their GitHub email address.</simpara>
-<simpara>The <link linkend="resources-cla">Contributor License Agreement</link> (CLA) hook will inspect incoming
-GitHub pull requests to ensure that the contributor has a valid CLA on file, and that
-the commit has been "signed-off" as required. Project committers should only merge pull
-<emphasis>green</emphasis> requests:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Github-cla-success.png"/>
-</imageobject>
-<textobject><phrase>Github cla success</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>The GitHub API does not give us a means of absolutely denying a merge; all we can
-do is warn you that the contributors have not signed a CLA:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Github-cla-failure.png"/>
-</imageobject>
-<textobject><phrase>Github cla failure</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Do not merge unless you are absolutely certain that the contributer does have a
-valid CLA on file (e.g. the Contributor License Agreement Lookup Tool confirms
-that they have a CLA).</simpara>
-<simpara>You must manually check that the commit message includes the
-required "Signed-off-by" statement in the footer.</simpara>
-<simpara>The Webmaster creates and maintains a mirror of all GitHub-hosted
-repositories on Eclipse Foundation hardware.</simpara>
-</section>
-</section>
-<section xml:id="resources-libraries">
-<title>Third-party Libraries</title>
-<simpara>Eclipse projects must register all of their <link linkend="ip-third-party">third-party library</link> use with the
-IP Team.</simpara>
-</section>
-<section xml:id="resources-forums">
-<title>Forums and Outbound Communication</title>
-<simpara>All projects are assigned a <link xlink:href="http://www.eclipse.org/forums">user forum</link> as a point of contact between
-the user and adopter communities, and the project developers.</simpara>
-<simpara>The EMO strongly encourages the use of alternative communication channels for
-connecting with the community: your project team knows your community and how
-to best connect with them.</simpara>
-</section>
-<section xml:id="resources-website">
-<title>Project Websites</title>
-<simpara>Project websites are an excellent way to connect your project with
-your community. Many projects opt to use the <link linkend="pmi">Project Management Infrastructure</link>
-(PMI) as their project website,
-but if so-desired, a project may host a website on Eclipse Foundation-hosted
-servers.</simpara>
-<simpara>Project website sources are hosted in Git repositories maintained by the
-Eclipse Foundation. <link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Website">Open a bug</link> to request that the Webmaster
-create a website for your project.</simpara>
-<note>
-<simpara>Alternative hosting services for project-specific websites are
-not permitted. Websites <emphasis>not</emphasis> hosted by the Eclipse Foundation are
-considered third-party and so are subject to the
-<link xlink:href="https://eclipse.org/legal/logo_guidelines.php">Guidelines for Eclipse
-Logo & Trademarks</link> (the Eclipse foundation asserts ownership of the
-project name trademark).</simpara>
-</note>
-</section>
-<section xml:id="resources-builds">
-<title>Builds</title>
-<simpara>Use of Eclipse Foundation-provided and hosted build services, the so-called
-<link xlink:href="http://wiki.eclipse.org/CBI">Common Build Infrastructure</link> (CBI) is strongly recommended, but n
-ot strictly required.</simpara>
-<simpara>Whether or not your project chooses to make use of provided build resources, it must
-be possible for members of the community to build project artifacts from
-source code with reasonable effort.</simpara>
-<section xml:id="resources-signing">
-<title>Signed Artifacts</title>
-<simpara>Where technically sensible, all downloadable artifacts should
-be <link xlink:href="https://wiki.eclipse.org/JAR_Signing">signed</link> by an Eclipse Foundation-provided certificate.</simpara>
-</section>
-</section>
-<section xml:id="resources-downloads">
-<title>Downloads</title>
-<simpara>Project artifacts (e.g. downloads) can be distributed via third-party
-services (e.g. Maven Central), but the Eclipse Foundation-provided
-infrastructure must be considered the primary source of project
-downloads.</simpara>
-<simpara>Project committers can <link xlink:href="https://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads">upload project artifacts</link> to the project’s
-directory on the download server.</simpara>
-</section>
-</chapter>
-<chapter xml:id="paperwork">
-<title>Committer Paperwork</title>
-<simpara>The Eclipse Foundation needs to ensure that all committers with write
-access to the code, web site, and issue tracking system understand their role in
-safeguarding the intellectual property of Eclipse. The Eclipse Foundation also
-needs to ensure that we have accurate records of the people who are
-acting as change agents on the projects. To ensure that
-committers understand their role, and that that Eclipse Foundation has
-accurate records, committers must provide documentation asserting
-that they have read, understood, and will follow the committer guidelines, and to have
-their employer sign that they agree that the new committer
-can participate at Eclipse and can contribute under the terms of the
-project license.</simpara>
-<simpara>All committers must complete the <emphasis>Committer Questionnaire</emphasis> and provide documentation
-as described below.</simpara>
-<section xml:id="paperwork-questionnaire">
-<title>Committer Questionnaire</title>
-<simpara>The <link xlink:href="http://portal.eclipse.org">Committer Questionnaire</link> is an online form that
-must be completed by all new committers. This form offers two separate paths:
-one for committers who work for a member company that has provided a signed
-Member Committer Agreement, and one for everybody else.</simpara>
-<note>
-<simpara>The <emphasis>Committer Questionnaire</emphasis> is accessible only after you have been elected as
-a committer on a project, either as an initial committer on a new project, or
-via election on an existing project.</simpara>
-</note>
-<simpara>Only member companies that have provided a signed Member Committer Agreement
-will be listed as member companies in the Committer Questionnaire.</simpara>
-</section>
-<section xml:id="paperwork-documents">
-<title>Documents</title>
-<simpara>The exact nature of the documentation required is dependent on your
-employments status.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/paperwork.png" width="75%" scalefit="1"/>
-</imageobject>
-<textobject><phrase>Paperwork requirements flowchart.</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Documents must be printed, signed and then returned either by fax
-(using the fax number on the form) or as scanned images via email
-to <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-<section xml:id="paperwork-mca">
-<title>Member Committer Agreement</title>
-<simpara>The <link xlink:href="http://www.eclipse.org/legal/committer_process/EclipseMemberCommitterAgreementFinal.pdf">Member Committer Agreement</link> (MCA) is used by member companies to
-cover all of their employees who participate in Eclipse Foundation projects
-as committers.</simpara>
-<simpara>If your employer has provided a signed MCA, then you most likely do not
-require any additional paperwork.</simpara>
-<note>
-<simpara>MCAs make committer paperwork easy, especially if you
-work for a member company that employs multiple committers. With an MCA a
-company can provide signed documentation once, rather than once for each
-employee (as required for an Individual Committer Agreement).</simpara>
-</note>
-<simpara>If your employer has not already provided an MCA, consult with your management
-team to determine who has the necessary authority to sign it on your company’s
-behalf. Provide the MCA in advance of the completion of your committer election
-or new project creation to streamline the committer provisioning process.
-If you and your management team are not sure whether or
-not your employer has an MCA, ask <link xlink:href="mailto:emo-records@eclipse.org">EMO Records</link>.</simpara>
-<simpara>If your employer is a member company that cannot provide a signed
-MCA, then you’ll have to complete an Individual Committer Agreement and
-Eclipse Committer Employer Consent Form.</simpara>
-</section>
-<section xml:id="paperwork-ica">
-<title>Individual Committer Agreement</title>
-<simpara>The Individual Committer Agreement (ICA) greement is used by committers
-who are not covered by an Member Committer Agreement.</simpara>
-<simpara>You will need to provide an ICA if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>You work for member company that has not signed a Member Committer Agreement;</simpara>
-</listitem>
-<listitem>
-<simpara>You work for a company that is not a member of the Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>You are self employed or not employed; or</simpara>
-</listitem>
-<listitem>
-<simpara>You are a student.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If you provide an Individual Committer Agreement, and are employed
-or self-employed, then you also need an <emphasis>Eclipse Committer Employer</emphasis>
-Consent Form.</simpara>
-</section>
-<section xml:id="paperwork-ececf">
-<title>Eclipse Committer Employer Consent Form</title>
-<simpara>Committers covered by an Individual Committer Agreement must document
-the consent of their employer when participating in Eclipse Foundatio
-projects by providing an Eclipse Committer Employer Consent Form (ECECF).</simpara>
-<simpara>You will need to provide an <link xlink:href="http://www.eclipse.org/legal/committer_process/employer_consent.pdf">ECECF</link> if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>You work for member company that has not signed a Member Committer Agreement;</simpara>
-</listitem>
-<listitem>
-<simpara>You work for a company that is not a member of the Eclipse Foundation; or</simpara>
-</listitem>
-<listitem>
-<simpara>You are self-employed.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If you are self employed, an owner of your own company, or
-have full ownership or part ownership in another company and has the
-authority to sign and submit the Eclipse Committer Employer Consent Form
-on your own behalf, then they should do so.</simpara>
-<simpara>Alternatively, you may arrange for the company that is
-your principal business customer to sign and submit the
-Eclipse Committer Employer Consent Form on your behalf.</simpara>
-</section>
-</section>
-<section xml:id="paperwork-existing">
-<title>Existing Committer</title>
-<simpara>If you are already a committer on an existing Eclipse Foundation project then
-additional paperwork may or may not be needed. The EMO IP Team will ask for
-additional documentation if required.</simpara>
-<simpara>If that MCA or ECECF already explicitly covers you for the
-new project, or that MCA or ECECF is universal (for all projects),
-then no additional paperwork is required</simpara>
-<simpara>If you are covered by an MCA or ECECF that does not include
-the new project, then the candidate must provide the documents as described
-above.</simpara>
-</section>
-<section xml:id="paperwork-not-employed">
-<title>Not Employed or Student</title>
-<simpara>If you are not employed or are a student, send a note to <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>
-explaining your not employed or student status.</simpara>
-<note>
-<simpara>We require this email because most new committers are employed by a company,
-the Eclipse Legal Team assumes that is the case for everyone, thus exceptions
-need to be noted.</simpara>
-</note>
-</section>
-<section xml:id="paperwork-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>What happens if I do not fill out the paperwork?</simpara>
-</question>
-<answer>
-<simpara>Then you don’t get your login and password for write-access to the
-source code repository(s). Sorry. No exceptions.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What happens if I cannot convince my employer to fill out the paperwork?</simpara>
-</question>
-<answer>
-<simpara>The Eclipse Board of Directors has taken a firm position that if you are
-employed then you must meet one of the scenarios described above. If you cannot
-convince your employer to fill out the necessary paperwork, then you may
-not have write-access to project resources. This is the
-Board’s position <emphasis>even if</emphasis> you are working on Eclipse projects on your
-own time. We realize that this prevents some talented and desirable
-people from being able to commit to the projects but this is our
-IP risk reduction strategy.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Where can I get help to discuss these documents with my management team? </simpara>
-</question>
-<answer>
-<simpara>The EMO and the Executive Director are happy to talk to your management
-and senior executives about these (and other) legal documents to
-help them understand why these documents are the best risk reduction
-solution for everyone involved (The Eclipse Foundation, you, and your
-employer); just contact us at <link xlink:href="mailto:license@eclipse.org">license@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What formats can be used to submit paper documentation? </simpara>
-</question>
-<answer>
-<simpara>The Eclipse Foundation accepts any of the following formats for
-submitting a paper form:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Print, sign, and postal mail the form to the Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>Print, sign, and fax the form to the Eclipse Foundation; or</simpara>
-</listitem>
-<listitem>
-<simpara>Print, sign, scan, and email to the scan as an attachment to the Foundation</simpara>
-</listitem>
-</itemizedlist>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What Email address should I use to send scanned documents? </simpara>
-</question>
-<answer>
-<simpara>Email scans of the completed paperwork to EMO Records at <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What if a committer changes employers? </simpara>
-</question>
-<answer>
-<simpara>If you change employers, please contact <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="ip">
-<title>Intellectual Property</title>
-<simpara>Eclipse projects are expected to take necessary precautions to mitigate
-intellectual property (IP) risk to adopters. A company that integrates the code
-from your project, for example, does so with confidence that the code in the
-project can legally be distributed under the agreed-to terms. The
-<link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">IP Due Diligence Process</link>, managed by the Eclipse IP Team
-(commonly referred to as the <emphasis>IP Team</emphasis>), is in place to support this.</simpara>
-<simpara>All Eclipse committers must be familiar with the <link xlink:href="http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP
-Policy</link>.</simpara>
-<section xml:id="ip-initial-contribution">
-<title>Initial Contribution</title>
-<simpara>Code provenance tracking is critical (we need to know the source of all code
-that ends up in our repositories). To that end, all new projects are required to
-make an <emphasis>initial contribution</emphasis> before <emphasis role="strong">any</emphasis> code is committed to a project’s
-source code repository.</simpara>
-<simpara>The IP Team will review your initial contribution to ensure that the code can
-distributed through an Eclipse property. The IP Team will review the code to
-make sure that it hasn’t been copied inappropriately, that licenses are being
-used correctly, and so forth. As part of this process, the IP Team will
-research the source of all code; depending on the size of the contribution, this
-can be a time-consuming process.</simpara>
-<note>
-<simpara>A project cannot make a <link linkend="release">release</link> until the due diligence on
-the IP contained in that release—​including project code contributions and
-third-party libraries—​is complete.</simpara>
-</note>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit the initial contribution
-for review by the IP Team.</simpara>
-<simpara>The IP Team is not able to review the history of project code being moved to
-an Eclipse project. The IP Team will review a snapshot of the project code and
-that snapshot, the <emphasis>initial contribution</emphasis>, must be the first commit in the
-Eclipse repository. If your project uses an existing GitHub repository, the
-Webmaster team will help you obscure the the history into a hidden branch.</simpara>
-</section>
-<section xml:id="ip-project-code">
-<title>Project Code Contributions</title>
-<simpara>Some contributions of code to maintained by the project (i.e. committed to a
-project source code repository and maintained by the project team) must be
-reviewed by the IP Team. The <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">IP Due Diligence Process</link>
-provides help to determine whether or not the contribution needs to be reviewed
-by the IP Team. If you’re not sure, ask your project mentors or your PMC for
-assistance.</simpara>
-<simpara>All contributions of project code must be tracked in the project’s
-<link linkend="ip-iplog">IP Log</link>.</simpara>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit a project code
-contribution for review by the IP Team.</simpara>
-</section>
-<section xml:id="ip-third-party">
-<title>Third-Party Libraries</title>
-<simpara>All third-party libraries required by project code will have to be checked
-and approved by the IP Team.</simpara>
-<simpara>The IP Team must review a third-party library if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the Java/OSGi manifest for one of the project bundles makes a
-direct reference to a third-party library (either the library bundle
-or a package from the library);</simpara>
-</listitem>
-<listitem>
-<simpara>project code includes an import statement for a package from a
-third-party library;</simpara>
-</listitem>
-<listitem>
-<simpara>project code uses reflection or other means to reference a
-library’s APIs and implementation;</simpara>
-</listitem>
-<listitem>
-<simpara>project code uses OSGi Services to make a reference to a
-specific implementation of a service; or</simpara>
-</listitem>
-<listitem>
-<simpara>project code invokes a "command line" tool.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>This list is not intended to be exhaustive.</simpara>
-<simpara>The <link xlink:href="http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf">Guidelines for the Review of Third Party Dependencies</link> can help
-you determine how to classify your third-party libraries.</simpara>
-<note>
-<simpara>A project cannot make a <link linkend="release">release</link> until the due diligence on
-the IP contained in that release—​including project code contributions and
-third-party libraries—​is complete.</simpara>
-</note>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit a third-party
-library for review by the IP Team.</simpara>
-</section>
-<section xml:id="ip-ownership">
-<title>Ownership</title>
-<simpara>The author of a contribution (or their employer) retains ownership of the
-intellectual property contained in the contribution. As part of the contribution
-process, the contributor licenses their contribution under the project license.</simpara>
-</section>
-<section xml:id="ip-copyright-headers">
-<title>Copyright and License Headers</title>
-<simpara>All source files must include a file header that describes the copyright and
-license terms of the software.</simpara>
-<formalpara>
-<title>Example Copyright and License Header</title>
-<para>
-<screen>/*******************************************************************************
- * Copyright (c) 2015 Schmedly Inc. and others. <co xml:id="CO2-1"/>
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html <co xml:id="CO2-2"/>
- *
- * Contributors:
- * Wayne Beaton - initial API and implementation <co xml:id="CO2-3"/>
- *******************************************************************************/</screen>
-</para>
-</formalpara>
-<calloutlist>
-<callout arearefs="CO2-1">
-<para>Name the initial copyright owner; this must be a legal entity (e.g. a company or individual).
-If other organizations have contributed, include "and others".</para>
-</callout>
-<callout arearefs="CO2-2">
-<para>List project licenses.</para>
-</callout>
-<callout arearefs="CO2-3">
-<para>Optionally list the names of the contributors and the nature of their contribution.</para>
-</callout>
-</calloutlist>
-<simpara>Your project is not a legal entity and so it is inappropriate to list it as
-the copyright owner.</simpara>
-<warning>
-<simpara>The copyright owner is either an individual or their employer. Most
-employment contracts stipulate that the intellectual property creations of an
-employee are the property of the employer and so the employer should generally
-be listed as the copyright owner.</simpara>
-</warning>
-<simpara>For more information please see the <link xlink:href="https://www.eclipse.org/legal/copyrightandlicensenotice.php">Default Eclipse Foundation Copyright and License Notice</link>.</simpara>
-</section>
-<section xml:id="ip-licensing">
-<title>Licensing</title>
-<simpara>Eclipse top level projects define the standard licensing for their
-projectsd. If your project has non standard licensing requirements,
-you may need to make a presentation to the Eclipse board of directors
-to request their approval. The presentation need only briefly describe
-the project and why special licensing considerations are necessary.</simpara>
-</section>
-<section xml:id="ip-cq">
-<title>Contribution Questionnaires</title>
-<simpara>A Contribution Questionnaires (CQ) is the main interface
-between Eclipse committers and the IP Team.</simpara>
-<simpara>A CQ is started when a committer completes a <emphasis>questionnaire</emphasis> regarding
-a contribution or third-party library. In literal terms, a CQ is a
-record in a modified instance of Bugzilla, named <emphasis>IPZilla</emphasis>,
-that tracks the progress of the approval process. The CQ record is the
-primary communication channel between the submitting committer and the
-IP Team. CQ records persist indefinitely.</simpara>
-<note>
-<simpara>You can review existing CQs via <link xlink:href="https://dev.eclipse.org/ipzilla">IPZilla</link>. Note that
-IPZilla is accessible only by committers, Eclipse Foundation member company
-represenatives, and other specifically-designated individuals.</simpara>
-</note>
-<simpara>All significant contributions of code to be maintained by an Eclipse project, as
-defined by the Eclipse IP Due Diligence Process require a CQ.</simpara>
-<simpara>Projects require a CQ for every third-party library that project
-code makes direct use of (regardless of whether or not the library
-is directly distributed by the project. If your code makes indirect
-use of a third party library through another Eclipse
-project’s code, you do not require a CQ for that library.</simpara>
-<note>
-<simpara>CQs for third-party libraries are <emphasis>version-specific</emphasis>. That is,
-a separate CQ is required for different versions of the same library.</simpara>
-</note>
-<simpara>CQs are not generally required for ongoing work done by project
-committers. Consult the IP Due Diligence Process document for
-more information.</simpara>
-<section xml:id="ip-parallel-ip">
-<title>Parallel IP</title>
-<simpara>The <emphasis>Parallel IP Process</emphasis> allows Eclipse projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team. In practical terms, the Parallel
-IP Process permits—​with preliminary approval from the IP Team—​a
-project to check-in code contributions into their source code
-repository and run builds against third-party libraries
-without having to wait for the full IP Due Diligence Process to
-compete.</simpara>
-<note>
-<simpara>There is some risk associated with the Parallel IP Process.
-The IP Team will grant preliminary approval based on a cursory
-review of the contribution; but during their full review, they may
-uncover issues that require mitigation. This may require, for
-example, that some parts of a contribution be removed completely
-(history and all) from a source code repository.</simpara>
-</note>
-<simpara>Parallel IP manifests in two different ways: projects in the
-<emphasis>incubation phase</emphasis> may leverage the Parallel IP process for
-project code and third-party libraries. <emphasis>Mature phase</emphasis> projects
-may leverage parallel IP for new versions of third-party libraries
-for which previous versions have already been approved.</simpara>
-<simpara>To leverage the Parallel IP Process, projects still submit CQ.
-The difference is that once a CQ has been reviewed for
-license compatibility, the project will be authorized via IPzilla
-to check-in the code start working on it.</simpara>
-<simpara>All IP must be fully approved before it is included in a release.</simpara>
-</section>
-<section xml:id="ip-piggyback">
-<title>Piggyback CQs</title>
-<simpara>Many third party libraries have already been approved for use in Eclipse projects.
-Many of those are immediately available via the <link xlink:href="http://www.eclipse.org/orbit">Orbit Project</link>.
-While these libraries have already been cleared for use by all projects,
-their use must be tracked. Usage is tracked so that—​in the event that a issue is uncovered
-following the due diligence process—​we can mitigate the impact of that issue.</simpara>
-<simpara>In this case, a <emphasis>piggyback CQ</emphasis> can be created on top of an existing CQ. Piggyback CQs
-are generally approved very quickly as the due diligence work has already been completed.</simpara>
-</section>
-<section xml:id="ip-cq-workflow">
-<title>CQ Workflow</title>
-<simpara>The workflow for creating a CQ for a third-party library starts with a search of existing
-CQs. If an existing CQ can be found that is concerned with the same library and version,
-then a piggyback CQ is created. Piggyback CQs must be approved by the project’s Project
-Management Committee (PMC) before they are processed by the EMO IP Team.</simpara>
-<simpara>If an existing CQ cannot be found, a new one must be created. Once created, the source
-code for the third-party library must be attached to the record. The PMC must then approve
-the record. If the project is eligible to leverage the Parallel IP Process, the IP
-Team performs a cursory review of the record and—​if the CQ meets with the
-requirements—​tentatively approves the use of the library while the full review is
-undertaken in parallel.</simpara>
-<simpara>The IP team may require your assistance as it performs a deep analysis of the library.
-Once that analysis is complete and the IP team has made a decision, they will outline
-the next steps. These next steps may—​in the event that the library is rejected—​that
-the library be removed from the project VCS, or that some part be removed. Most often,
-the library is approved and the CQ is marked as such.</simpara>
-<simpara>Be advised that this process may take a while. The actual amount of time that it takes
-to process a CQ depends on numerous factors including the size of the queue, and the
-nature and size of the contribution.</simpara>
-</section>
-</section>
-<section xml:id="ip-iplog">
-<title>IP Logs</title>
-<simpara>An IP Log is a record of the intellectual property contributions to a project.
-This includes such as a list of all committers, past and present, that have
-worked on the code and (especially) those who have made contributions to
-the current code base.</simpara>
-<simpara>The IP Log is a big part of the official <link linkend="release">release cycle</link>. You are required to
-submit your project’s IP Log prior to scheduling a release, or restructuring
-review. We encourage you to keep your IP log current rather than rushing at the
-end. The IP Log includes important information about your project that lets
-adopters know where all the code comes from, who owns the copyrights, and so
-forth.</simpara>
-<simpara>Specifically, the log tracks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Licenses;</simpara>
-</listitem>
-<listitem>
-<simpara>Past and present committers;</simpara>
-</listitem>
-<listitem>
-<simpara>Third-party libraries; and</simpara>
-</listitem>
-<listitem>
-<simpara>Contributions from outside the project (i.e. non-committers)</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="ip-iplog-generator">
-<title>IP Log Generator</title>
-<simpara>The Automated IP Log Tool automatically generates an IP Log using information
-that is available to the Eclipse Foundation. The list of committers, for
-example is generated using information provided by the Dash project which itself
-pulls information out of source code repositories.</simpara>
-<simpara>The IP Log generator pulls information from multiple location to assemble the log:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/ip-log-generator.png"/>
-</imageobject>
-<textobject><phrase>ip log generator</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<itemizedlist>
-<listitem>
-<simpara>Third-party libraries used by the project come from <emphasis>IPZilla</emphasis>;</simpara>
-</listitem>
-<listitem>
-<simpara>The <emphasis>Dash</emphasis> process scans the project source code repositories to assess committer activity;</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Dash</emphasis> also scans Git repositories for contributions;</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If you follow the guidelines for handling Git contributions, contributions received via
-Git in any branch will automatically appear in the log</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Contributions received as patches in <emphasis>Bugzilla</emphasis> that are marked <literal>iplog+</literal>
-will automatically appear in the log; and</simpara>
-</listitem>
-<listitem>
-<simpara>License information is obtained from the <emphasis>Foundation</emphasis> database</simpara>
-</listitem>
-</itemizedlist>
-<simpara>To fully leverage the value of the Automated IP Log Tool, you need to:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Keep your project metadata up-to-date;</simpara>
-</listitem>
-<listitem>
-<simpara>Follow the guidelines for handling Git contributions;</simpara>
-</listitem>
-<listitem>
-<simpara>Mark IP Contributions in Bugzilla; and</simpara>
-</listitem>
-<listitem>
-<simpara>Create <link linkend="ip-cq">contribution questionnaires</link> (CQs) where appropriate</simpara>
-</listitem>
-</itemizedlist>
-<warning>
-<simpara>Contributions should be recorded in <emphasis>one of</emphasis> Git or Bugzilla, not both.
-Setting the <emphasis>Author</emphasis> credentials on Git commits is the preferred mechanism.
-The IP Log generator is not smart enough to detect duplicate entries.</simpara>
-</warning>
-<simpara>Your project’s metadata is used to determine the identities of the source code
-repositories that Dash needs to scan to find out committer information. Specifically,
-you need to specify, in the <emphasis>Source Repositories</emphasis> section, a list of paths to source code
-repository locations.</simpara>
-<simpara>The Automated IP Log tool populates the <emphasis>Contributors</emphasis> section with information gathered
-from Git and Bugzilla. This section lists contributions from non-committers (this is
-time-sensitive, so contributions made by current committers before they became
-committers will also be included). Only non-committer contributions are recorded in
-the generated log.</simpara>
-<simpara><link linkend="resources-commit">Git commits</link> contributed by non-committers are identified by
-the author credentials on the commit record; the <emphasis>Author</emphasis> field must be set to the identity
-of the actual author of the commit.</simpara>
-<simpara>Alternatively, Bugzilla attachments can be marked with the <literal>iplog+</literal> flag.
-This flag setting indicates that the person who attached the bug is the contributor.
-To comply with the website terms of use, the person who attaches
-the contribution <emphasis role="strong">must</emphasis> be the person who has permission to make it available.
-You should ensure that this is the case before including the code in your project’s
-repository and flagging the entry.</simpara>
-<simpara>You can also flag an entire Bugzilla entry with <literal>iplog+</literal>. Doing so,
-however, indicates to the Automated IP Log tool that every single comment made by a non-committer
-in the bug report represents a potential contribution. For your own sanity, it’s a good practice
-to ask contributors to provide and attach patches that can be individually marked. Marking an
-entire bug represents an ongoing maintenance issue as new comments added to the bug from
-non-committers will show up in the generated log.</simpara>
-<simpara>That contributions flagged in Bugzilla will only appear in the IP Log if the bug is marked
-<literal>FIXED</literal> or <literal>CLOSED</literal>.</simpara>
-<simpara>The Third-Party Software section of the log is populated from IPZilla. The IP Team
-will mark your contributions in such a way that they will appear in
-the log. If third party software is not appearing properly, contact the
-<link xlink:href="mailto:emo-ip-team@eclipse.org">EMO IP Team</link> to make corrections.</simpara>
-</section>
-</section>
-<section xml:id="ip-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What do you do with the IP Log? </simpara>
-</question>
-<answer>
-<simpara>IP Log reviews occur in two stages. In the first stage, the EMO performs
-a technical assessment to make sure that the artifacts produced by the
-project are properly accounted for in the IP log. You may be asked to
-assist with the resolution of any discrepancies found during this assessment.
-In the second stage, the IP Team reviews the log to ensure that
-it matches their records. The IP log review concludes with approval by the IP Team.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>When should I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>The IP Log should be submitted for review by the IP Team two weeks before the planned
-end date for a release review or (if code moves are involved) a restructuring review.
-Note that the date of your review may be different from the date of the actual release.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Are there other reasons to submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>Generally no. If the IP Team requires an IP Log review outside of the context of
-a release or restructuring review, they’ll ask for it. It is not generally necessary
-to submit an IP Log for review outside of the context of a review.
-It is, however, good practice to do your own review of the generated
-IP Log periodically to make sure that it accurately reflects the state of the project.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I fix problems with the generated IP Log? </simpara>
-</question>
-<answer>
-<simpara>The IP Log is generated based on data from Eclipse Foundation servers. If the log
-is being generated incorrectly, then the underlying data needs to be fixed. If
-you spot a problem, send a note to <link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="elections">
-<title>Elections</title>
-<simpara>Roles in a project are assigned based on merit demonstrated in a
-publicly-accessible forum, in the form of an election. Elections
-start with a nomination that contains a statement of merit. The nature
-of a statement of merit varies widely, but is generally expected to
-to concisely state the impact that the nominee has had on the
-project.</simpara>
-<note>
-<simpara>Employment status has no bearing at whether or not somebody can participate
-in an open source project at Eclipse. Employment does not, for example, guarantee
-committer status; committer status must be earned by everybody.</simpara>
-</note>
-<section xml:id="elections-committer">
-<title>Committer Elections</title>
-<simpara>A committer election starts with a statement of merit for the nominee.
-The statement of merit should, for example, include links to contributions
-made by the nominee (e.g. Git commits, Gerrit reviews, pull requests,
-or Bugzilla records).</simpara>
-<simpara>Use the <link xlink:href="http://portal.eclipse.org">developer portal</link> to elect a committer.</simpara>
-<simpara>Only project committers may vote in a committer election. To be successful,
-the election must receive a minimum of three positive <literal>+1</literal> votes.
-Any committer can veto the election by casting a <literal>-1</literal> vote. For projects
-with three or fewer committers all committers must vote. Committer elections
-run for one week, but will end prematurely if all
-project committers vote <literal>+1</literal>.</simpara>
-<simpara>Following a successful committer vote, the project’s PMC will review
-the election results and then either approve or veto the election.
-An election may be vetoed, for example, if the PMC feels that the
-merit statement is not strong enough.</simpara>
-<simpara>The <link linkend="paperwork">paperwork</link> process will automatically be initiated following
-PMC approval of an election.</simpara>
-</section>
-<section xml:id="elections-pl">
-<title>Project Lead Elections</title>
-<simpara>Similar to a committer election, a project lead election starts with a
-statement of merit. The merit statement should, rather than focus on
-specific code contributions, focus instad on the leadership qualities
-expressed by the individual.</simpara>
-<example>
-<title>Project Lead merit statement</title>
-<simpara>Sounak has been part of the Ogee development since before the initial
-contribution. He played an important role ever since, as he is one of the key
-developers. With regards to the number of commits Sounak is currently the top
-committer of Ogee:
-<link xlink:href="http://git.eclipse.org/c/ogee/org.eclipse.ogee.git/stats/?period=q&ofs=10">http://git.eclipse.org/c/ogee/org.eclipse.ogee.git/stats/?period=q&ofs=10</link>
-Apart from that Sounak took care of the project page and the build. For
-release 0.6 he also handled the review formalities for me. Finally I would
-like to mention a blog post he did at odata.org to promote Ogee in the OData
-community:
-<link xlink:href="http://www.odata.org/blog/eclipse-ogee">http://www.odata.org/blog/eclipse-ogee</link></simpara>
-</example>
-<simpara>Project leads are normally also committers. A project may have more than one
-project lead (so-called <emphasis>co-leads</emphasis>).</simpara>
-<simpara>Use the <emphasis>Nominate a Project Lead</emphasis> link in the <emphasis>Committer Tools</emphasis> block on the
-project’s <link linkend="pmi">management page</link> to start a project lead election.</simpara>
-<simpara>Only project committers can vote in a project lead election.
-To be successful, a project lead election must receive a minimum of three
-positive <literal>+1</literal> votes. Any committer can veto the election by
-casting a <literal>-1</literal> vote. For projects with three or fewer committers
-all committers must vote. Committer elections run for one week, but will
-end prematurely if all project committers vote <literal>+1</literal>.</simpara>
-<simpara>Following a successful committer vote, the project’s PMC will review
-the election results and then either approve or veto the election.
-A PMC-approved election will be referred to the EMO/ED as a recommendation
-for appointment. The final decision rests with the EMO/ED.</simpara>
-</section>
-<section xml:id="elections-pmc-member">
-<title>PMC Member Elections</title>
-<simpara>The manner in which a top-level project’s Project Management Committee
-(PMC) <emphasis>Member</emphasis> is appointed varies by PMC. Some PMCs are set up to have a
-representative from each of the projects in the top-level project. Other
-PMCs are more exclusive and run an election similar to that of a project
-lead election.</simpara>
-<simpara>In all cases, the PMC Lead makes a recommendation to the EMO/ED to appoint
-a PMC Member. The final decision rests with the EMO/ED.</simpara>
-</section>
-<section xml:id="elections-pmc-lead">
-<title>PMC Lead Appointments</title>
-<simpara>PMC <emphasis>Leads</emphasis> are are not elected. They are vetted by the EMO, approved by
-the Eclipse Board of Directors, and appointed by the EMO/ED.</simpara>
-</section>
-<section xml:id="elections-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="release">
-<title>Releases</title>
-<simpara>Releases are formal for Eclipse projects. They start with planning,
-and end with a community review. You can capture as many future releases as you’d like. It’s
-common practice to specify releases three or six months into the future.</simpara>
-<simpara>Releases are broadly categorized as:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>Major</emphasis> releases include API changes (potential for downstream breakage);</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Minor</emphasis> releases add new functionality, but are API compatible with previous versions; and</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Service</emphasis> releases include bug fixes only and include no significant new functionality.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For all major and minor releases, you must engage in a <emphasis>release review</emphasis>.
-Release reviews are not required for bug-fix/service releases.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/release-cycle.png"/>
-</imageobject>
-<textobject><phrase>The release cycle</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara xml:id="releases-plan">A project plan is <emphasis>required</emphasis> for each major and minor project release.
-The plan should lay out in broad terms what the goals are for the
-release. As plans are a valuable means
-for the community to get involved with your project, the plan should be
-created at the beginning of the release cycle. By establishing the plan
-early, you give prospective contributors help in determining how they
-can most usefully contribute, and adopters can prepare their own
-development schedule and themes. Plans can change during the release
-cycle.</simpara>
-<simpara>Use the <link linkend="pmi">Project Management Interface</link> to create a new release
-record. At the start of the release cycle, your plan should minimally
-include a release number, date, and short description. Think of the
-description as an "elevator pitch": how would you describe the release
-in a fifteen second elevator ride? All aspects of a plan can change
-during the release cycle (including the date). If you do change the plan,
-make sure that the change is communicated via your project’s <emphasis>dev</emphasis> list
-and other project channels.</simpara>
-<simpara>The <emphasis>Plan</emphasis> tab in the release record contains numerous fields for capturing
-plan information. The amount of information that you should capture
-for a release plan varies by top-level project, so consult with your
-Project Management Committee (PMC) for advice.</simpara>
-<simpara>Producing regular builds is an important part of the release cycle.
-Builds are an important means of engaging with the community: adopters can
-help you test your code and test their own so that they can be ready for
-the eventual release. Plan to produce at least one <emphasis>milestone</emphasis> build (more
-are better, depending on the length of your release cycle), and capture
-the planned date for that milestone in the release record. It is also
-common practice to generate nightly and weekly integration builds. Ensure that
-your project’s downloads page provides the information required for the
-community to obtain your builds.</simpara>
-<simpara>All of your project’s <link linkend="ip">intellectual property</link> contributions
-must be approved by the IP Team before you can release
-(this includes third-party libraries and contributions of code to be
-maintained by the project).</simpara>
-<section xml:id="release-review">
-<title>Release Review</title>
-<simpara>A <emphasis>release review</emphasis> is a formal announcement of your release to the
-community and a request for feedback. In practical terms, experience
-has shown that those individuals and organizations who are interested
-in your project follow development throughout the release cycle and so
-are have likely already provided feedback during the development
-cycle (i.e. they are unlikely to provide feedback during the review
-period). With this in mind, the review generally serves as a means for
-a project to engage in a retrospective of the progress made during the
-release, discover areas of potential improvement, demonstrate that the
-project is operating in an open and transparent manner, and ensure that
-the development process and intellectual due diligence processes have
-been followed.</simpara>
-<simpara>Release reviews run for a week and always conclude on a Wednesday.</simpara>
-<note>
-<simpara>We schedule reviews to conclude on the <emphasis>first and
-third Wednesdays of the month</emphasis>. Your release date does not have to
-coincide with the review date (you can set the release date as
-necessary). The review must, however, conclude successfully before you
-can make the release official.</simpara>
-</note>
-<simpara>A <emphasis>release review</emphasis> requires review documentation and an intellectual
-property (IP) log check. The review process must be initiated at least
-two weeks in advance of the anticipated <emphasis>review</emphasis> date.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/release-review.png"/>
-</imageobject>
-<textobject><phrase>Release review work flow</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Prepare the review documentation well in advance of the start of the
-review period. The release record which contains your project plan
-also includes a <emphasis>Review</emphasis> tab with appropriate fields for a review.
-As with the plan fields, all of the review fields are optional and
-the level of detail you need to provide varies by top-level project.
-You can assemble review information during the release cycle (there’s
-no need to wait until the end)</simpara>
-<simpara>The review materials must be approved by the PMC; send an email to
-the PMC’s mailing list asking for approval. The PMC will respond with
-feedback or a simple "+1" indicating approval.</simpara>
-<note>
-<simpara>Click the handy <emphasis>Send Email to the PMC</emphasis> link under <emphasis>Committer Tools</emphasis>
-on the release record page to connect with the PMC.</simpara>
-</note>
-<simpara>Submit the IP Log for review by the IP Team. The IP Team must approve
-the IP Log before we can schedule the review, so submitting this early
-is important. The <link linkend="ip-iplog-generator">IP Log generator</link> automatically
-collects information based on the information that the project team has
-provided to the IP Team through <link linkend="ip-cq">contribution questionnaires</link>
-in IPZilla, commits in the project’s source code repository, and
-other information in our databases. Carefully review the IP Log before
-submitting to the IP Team for their review.</simpara>
-<note>
-<simpara>Click the handy <emphasis>Generate IP Log</emphasis> link under <emphasis>Committer Tools</emphasis>
-on the release record page to open the IP Log generator.</simpara>
-</note>
-<simpara>The information used to generate an IP Log should always be up-to-date
-(don’t wait until the end of the release cycle to make it right).</simpara>
-<simpara>At any point in this process, you can request that the review be
-initiated by clicking the <emphasis>Schedule a review for this release</emphasis> link
-that appears at the top of the release record page. This will invite you
-to select a review date. You must then follow up with the EMO to approve
-the review.</simpara>
-<note>
-<simpara>The EMO will likely notice that you’ve created the release record,
-connected with your PMC, and submitted an IP Log for review by the IP
-team and will take steps to initiate the actual review. However, since
-there is a great deal of variability in this process, send an email to
-<link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link> stating your intent to release.</simpara>
-</note>
-<simpara>The EMO will conclude the review on the scheduled end date and advise the
-project team of the outcome.</simpara>
-</section>
-<section xml:id="release-graduation">
-<title>Graduation Review</title>
-<simpara>The purpose of a <emphasis>graduation review</emphasis> is to confirm that the project has
-a working and demonstrable code base of sufficiently high quality
-active and sufficiently diverse communities; has adopters, developers, and users
-operating fully in the open following the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>; and
-is a credit to Eclipse and is functioning well within the larger Eclipse community</simpara>
-<simpara>Graduation reviews are generally combined with a <link linkend="release-review"><emphasis>release review</emphasis></link>
-(typically, but not necessarily the <emphasis>1.0</emphasis> release).
-Upon successful completion of a graduation review, a project will leave the
-incubation phase and be designated as a <emphasis>mature</emphasis> project.</simpara>
-<simpara>For a graduation review, release review documentation must be augmented to
-include demonstration of:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>solid working code with stable APIs;</simpara>
-</listitem>
-<listitem>
-<simpara>an established and growing community around the project;</simpara>
-</listitem>
-<listitem>
-<simpara>diverse multi-organization committer/contributor/developer activity; and</simpara>
-</listitem>
-<listitem>
-<simpara>operation in the open using open source rules of engagement.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The graduation review documentation should demonstrate that members have
-learned the ropes and logistics of being an Eclipse project. That is,
-the project "gets the Eclipse way".</simpara>
-</section>
-<section xml:id="release-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Can a release review fail? </simpara>
-</question>
-<answer>
-<simpara>Technically, yes. A release review can fail. In our history, however, this
-occurrs very rarely. We set up release reviews to succeed.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How often should we do releases? </simpara>
-</question>
-<answer>
-<simpara>This depends very much on the nature of your project and the expectations
-of your community and stake holders. If you’re not sure, connect with your
-mentors and top-level project for guidance.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How much effort should we put into this? </simpara>
-</question>
-<answer>
-<simpara>The amount of effort varies based on the nature of the team, and
-expectations of the community and stake holders. Generally, though, a project
-team shouldn’t spend more than a couple of hours working directly on the
-formal aspects of the release review.
-If the amount of effort seems too onerous, you may be trying too hard.
-Connect with your project mentors, top-level project’s PMC, or the
-<link xlink:href="mailto:emo@eclipse.org">EMO</link> for guidance.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>Click the <emphasis>Submit</emphasis> button on the <link linkend="ip-iplog-generator">IP Log generator</link>.
-You need to be logged in as project committer to have access to this button.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I accept contributions after I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>The short answer is <emphasis>yes</emphasis>. Please do accept contributions.
-If you require a new contribution questionnaire (for either a third
-party library or code contribution) after submitting the IP Log for
-review, please ask the <link xlink:href="mailto:emo-ip-team@eclipse.org">IP Team</link> if
-they want you to resubmit the IP Log.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I obtain PMC approval? </simpara>
-</question>
-<answer>
-<simpara>Send the the PMC a note via the top-level project’s <emphasis>PMC</emphasis> mailing list
-with a link to the release record. Note that the release record page
-has a handy link labeled <emphasis>Send Email the PMC</emphasis> under <emphasis>Committer Tools</emphasis>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>I need to do a release now. Can you fast-track the review? </simpara>
-</question>
-<answer>
-<simpara>While we do try to be as accommodating as possible, the answer is no.
-We have a well-defined process with predictable dates. Please plan
-accordingly.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can a project in the incubation phase do releases? </simpara>
-</question>
-<answer>
-<simpara>Yes. In fact, we encourage projects to do at least one release while
-in incubation phase.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What restrictions are placed on version names for incubating projects? </simpara>
-</question>
-<answer>
-<simpara>Projects in the incubation phase generally use version numbers that
-are less than 1.0. This is, however, a convention not a rule. If it makes sense
-for you community and adopters to use higher numbers, then do so.
-If you’re not sure, ask your top-level project PMC for advice.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I name/number milestone builds? </simpara>
-</question>
-<answer>
-<simpara>Milestone builds should contain the name/number of the release suffixed
-with "Mn" (e.g. the second milestone for EGit 3.2 may have a file
-named "egit-3.2M2"). Projects in the incubation phase may produce
-milestone builds for their graduation release, e.g "myProject-1.0M2".</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How can I get help? </simpara>
-</question>
-<answer>
-<simpara>Contact your mentors (for projects in the incubation phase), top-level
-project PMC, or the <link xlink:href="mailto:emo@eclipse.org">EMO</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="pmi">
-<title>Project Management Infrastructure (PMI)</title>
-<simpara>The Eclipse Project Management Infrastructure (PMI) consolidates
-project management activities into a single consistent location and experience.</simpara>
-<simpara>Project Management Infrastructure themes:</simpara>
-<simpara><emphasis>Improved consistency.</emphasis> Configuration/data-driven project web presence,
-direct linkage between releases, reviews, and plans. Information—​including
-basic project metadata, project plans, and release review information—​is
-captured and retained in a consistent (and easily leveraged) data-based
-format (rather than in multiple documents in arbitrary formats).</simpara>
-<simpara><emphasis>All-in-one-place.</emphasis> Project leads and committers are able to edit
-information in place on the project information pages. Text/information in
-one place with links in another is eliminated where possible. Comments and
-discussion related to reviews, elections, etc. are connected directly
-to the item being discussed.</simpara>
-<simpara><emphasis>Get started faster.</emphasis> By default, projects are provided with a data-driven
-website that includes consistent links to project releases, reviews,
-downloads, etc. Projects can opt to override the default and provide
-their own customized web presence. Setting up a project presence is a
-matter of configuration, not PHP programming against proprietary APIs.</simpara>
-<section xml:id="pmi-metadata">
-<title>Project Metadata?</title>
-<simpara>Project committers and project leads are responsible for maintaining
-their project’s metadata. This information is an important part of being
-an Eclipse project.</simpara>
-<simpara>Project metadata is:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Relatively static structural information such as the project
-description and scope, the names of the project’s mailing lists and
-newsgroups, the bugzilla products, source code repositories, etc.</simpara>
-</listitem>
-<listitem>
-<simpara>Historical information such as previous release downloads, release
-review slides and IP logs, etc.</simpara>
-</listitem>
-<listitem>
-<simpara>Status and future looking information such as the project and
-milestone plans, the features scheduled for the current release, release
-dates, etc.</simpara>
-</listitem>
-</orderedlist>
-<simpara>PMC members, and the Eclipse Foundation staff also have the ability to
-make changes on behalf of a project.</simpara>
-</section>
-<section xml:id="pmi-viewing">
-<title>Viewing</title>
-<simpara>The complete listing of all current
-<link xlink:href="http://projects.eclipse.org/list-of-projects">Eclipse projects</link> provides
-one starting point for viewing projects. From here, you can link
-directly to a project information page. Navigation options are provided
-to help you move from one project to another.</simpara>
-</section>
-<section xml:id="pmi-commands-and-tools">
-<title>Commands and Tools</title>
-<simpara>Committers have access to several committer-specific
-commands and tools. The selection of commands available are context sensitive; only those
-commands that make sense for the logged in user are shown.</simpara>
-</section>
-<section xml:id="pmi-editing">
-<title>Editing Project Metadata</title>
-<simpara>Committers have the ability to edit the information managed and displayed
-on the project page.
-There are several sections on the page. When you switch the page into
-"Edit" mode, you will be provided with lots of help regarding the
-contents of each of the fields (note that the help text is currently
-rendered below the fields).</simpara>
-<simpara>Some of the fields are described below.</simpara>
-<section xml:id="pmi-description-and-scope">
-<title>Description and Scope</title>
-<simpara>The <emphasis>description</emphasis> should start with a concise paragraph of three to five
-sentences (e.g. suitable for display with a collection of other projects).
-A single paragraph is generally appropriate for the
-description.</simpara>
-<simpara>If more than a single simple paragraph is required to fully
-describe the project, it is possible to set a summary. The summary
-can be specified by toggling the "show summary" link to explicitly
-set a summary apart from the more detailed description, or the top
-part of the description can be designated as the summary by inserting
-a <emphasis>Teaser Break</emphasis> into the content.</simpara>
-<note>
-<simpara>providing a summary gives you control over what will get rendered.
-In views where we are displaying more than one project, the system
-will artifically cut short descriptions that are too long, potentially
-resulting in a description that looks <emphasis>weird</emphasis>.</simpara>
-</note>
-<simpara>The <emphasis>scope</emphasis> is intended for a more select audience; generally speaking the
-scope should be taken directly from the project’s proposal. Project
-members have the ability to change the text of the project scope, but
-should be careful to avoid changing the meaning. If the meaning of the
-scope needs to change, the Project Management Committee (PMC) must be
-contacted regarding a potential restructuring review.</simpara>
-</section>
-<section xml:id="pmi-downloads">
-<title>Downloads</title>
-<simpara>You can provide download information for your project in the "Downloads"
-section.</simpara>
-<simpara>The first entry is the main "Downloads URL". This manifests as a "Big
-Button" Download on the project page. What you put here is left to the
-project team to decide. It can be a link to a webpage, a direct link to
-a file download, or whatever else makes sense the project and community.</simpara>
-<simpara>Optional text can be included along with the "Big
-Button" Download, as well as links to zero or more Eclipse Marketplace,
-update/p2 sites, or other downloads. Each of the links can have an
-optional title (the link itself will be displayed if no title is
-provided). Note that no validation is done on the links to ensure that
-they are meaningful.</simpara>
-<simpara><emphasis>The Eclipse Foundation strongly encourages all projects to create an
-maintain and <link xlink:href="http://marketplace.eclipse.org">Eclipse Marketplace</link>
-presence.</emphasis></simpara>
-</section>
-<section xml:id="source-repositories">
-<title>Source Repositories</title>
-<simpara>The project can specify zero or more <emphasis role="strong">source repositories</emphasis>. These are
-displayed in the "Contribute to this Project" section.</simpara>
-<simpara>The values specified are used to query against a database of known
-existing source repositories (this database is updated nightly by a
-discovery process). Those repositories that are found in the database
-will be displayed with enhanced information (including links to
-repository mirrors, Gerrit, etc.). All values that you provide will be
-displayed, whether they point to real repositories or not. If the
-database does not contain your repository, the PMI will assume that the
-value is correct and try its best to display the information.</simpara>
-<simpara>Repositories should be specified using the file system path, e.g.
-<emphasis>/gitroot/egit/egit.git</emphasis>. The name that is displayed for the repository
-is extracted from the last segment of the URL.</simpara>
-<simpara>If a description file exists in the Git repository, the contents are
-automatically displayed under the repository name.</simpara>
-<note>
-<simpara>The script that we us to identify repositories attempts to identify a
-corresponding Gerrit interface for the repository. If it exists, the
-Gerrit URL is used in place of the Git one. If the repository uses
-Gerrit, then only the Gerrit URL is displayed. Otherwise, the "git://"
-and "ssh://" URLs are displayed.</simpara>
-</note>
-<simpara>You can use wildcards to match multiple repositories, e.g.
-<emphasis>/gitroot/virgo/*</emphasis>. Note that wildcards only work for repositories that
-exist on Eclipse infrastructure (they do not work for GitHub-based
-repositories, for example).</simpara>
-<simpara>Repositories are displayed in the order they are specified. The order
-can be changed in the edit screen by dragging entries into the desired
-order. All wildcard matches are sorted alphabetically by name at the end
-of the list.</simpara>
-<simpara>A <emphasis role="strong">Contribution Message</emphasis> should be provided; it is displayed at
-the top of the section and is one of the primary means by which the
-community will find the project code. Arbitrary text is permitted, but we recommend
-that you limit this content to a single paragraph with a few sentences
-that include a link to more information.</simpara>
-</section>
-<section xml:id="pmi-company-logos">
-<title>Company Logos</title>
-<simpara>Company logos sometimes appear on project pages under the following
-conditions"</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The company must be a <link xlink:href="http://eclipse.org/membership/">member</link> of the
-Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>The company needs to have their logo uploaded to the Portal;</simpara>
-</listitem>
-<listitem>
-<simpara>At least one committer has to be listed as an employee of the company
-in question;</simpara>
-</listitem>
-<listitem>
-<simpara>The committer must be on this project; and</simpara>
-</listitem>
-<listitem>
-<simpara>The committer must be active (must have made at least one commit in
-the last three months)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If all of those conditions are met and the logo is still not showing up,
-then it’s possible that the project meta-data doesn’t have the correct
-source code repository information specified.</simpara>
-</section>
-<section xml:id="pmi-build-technology">
-<title>Build Technology</title>
-<simpara>A project can specify a section of text, links, and a selection of the
-build technologies employed. Specifying this information makes it easier
-for members from the community to understand your build. Links can
-include direct links into the Hudson builds, pages of build
-instructions, or whatever else the project team feels will help the community build
-the project.</simpara>
-</section>
-<section xml:id="pmi-technology-types">
-<title>Technology Types</title>
-<simpara>A project can specify the types of technology produced by the project.
-This is specified in rather broad terms like "OSGi" or "Runtime". The
-various technology types manifest as checkboxes on the edit screen. This
-information is used to form connections between projects to assist in
-navigation and discovery.</simpara>
-<simpara>Clicking on one of the technology types, will take the user
-to a page that lists the projects that produce that particular type of
-technology, along with the summary of their description and project logo
-(if specified).</simpara>
-</section>
-</section>
-<section xml:id="pmi-releases">
-<title>Releases and Reviews</title>
-<simpara>Projects, Releases, and Reviews are presented as separate records. Each
-project record, obviously, represents information about a project. A
-project may have multiple releases; information about the release is
-represented in a release record. The release record also contains some
-review information. This information is included here, because all
-releases do not necessarily have a review (a project can opt to provide
-some <emphasis>review</emphasis> type information as part of a release record. A project
-can have multiple review records; as release reviews are the most common
-form of review, most review records will be joined to a release record.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/ProjectsReleasesReviews.png"/>
-</imageobject>
-<textobject><phrase>Releases and Reviews</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>A review record, however, does not require a release association. Some
-reviews are associated with proposals. Other have no other association
-(e.g. termination reviews).</simpara>
-<simpara>Each <link linkend="release">release</link> has its own record in the database. Records are connected
-directly to a single specific project; a subset of release records
-associated with a project are displayed on the project page. An existing
-release can be edited in much the same was as a project. Any logged in
-project member (committer or project lead) can click the "Edit" button.</simpara>
-<note>
-<simpara>_Create a single record for each release. <emphasis role="strong">Do not create release records
-for milestones.</emphasis> Enter milestone information in the <emphasis>Plan</emphasis> information
-for your release.</simpara>
-</note>
-<simpara>A project lead or committer can create a new release by clicking "Create a new release" under
-"Committer Commands" on the project page. This opens a dialog requesting
-that a date and name be specified. Both of these values can be changed later.</simpara>
-<section xml:id="pmi-release-description">
-<title>Description</title>
-<simpara>Describe the release in the <emphasis>Description</emphasis> section. The description
-should generally be a concise paragraph describing the focus of the
-release (e.g. adding certain functionality, fixing bugs, etc.) in a form
-that is appropriate in an aggregation (e.g. a page that displays the
-release information for all projects participating in an instance of the
-Simultaneous release). The description should provide enough information
-to encourage the reader to click the "find out more" link.</simpara>
-</section>
-<section xml:id="pmi-release-issues">
-<title>Issues</title>
-<simpara>The release record will automatically generate a list of targeted bugs.</simpara>
-<simpara>To populate this list:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Ensure that the Bugzilla Product is set the to correct value in the
-project metadata;</simpara>
-</listitem>
-<listitem>
-<simpara>Set the "target milestones" in Bugzilla need to match the name of your
-release.</simpara>
-</listitem>
-</itemizedlist>
-<note>
-<simpara>The matching algorithm tries to be as forgiving as possible, a release
- named "3.5", "3.5.0", or "3.5 (Luna)" will—​for example—​match target
- milestones named "3.5" ,"3.5M1", "3.5 M2", "3.5.0M3", etc., but will
- not match "3.5.1".</simpara>
-</note>
-<simpara>The bugs for all projects participating in the release will be included.
-Bugs are grouped by Bugzilla product and component.</simpara>
-</section>
-<section xml:id="pmi-release-plan">
-<title>Plan</title>
-<simpara><link linkend="releases-plan">Project plan</link> information belongs in the <emphasis>Plan</emphasis> section. This
-information <emphasis role="strong">should</emphasis> generally be provided early in the development
-cycle to allow the various communities the ability to understand and
-participate in the release. It is expected that the plan will evolve
-over time. Note that all projects are required to provide a plan for
-each major and minor release (plans are not required service releases).</simpara>
-</section>
-<section xml:id="pmi-release-milestones">
-<title>Milestones</title>
-<simpara>Enter the name, date, and optional description for each milestone
-expected with the release.</simpara>
-<simpara>Projects should generally include more than one milestone build with each
-release. To include additional milestones, click the "Add another item"
-button. Note that milestones can be dragged into the desired order. To
-remove a milestone, leave the "Name" field blank.</simpara>
-</section>
-<section xml:id="pmi-review">
-<title>Review</title>
-<simpara>The release has a <link linkend="release-review"><emphasis>Review</emphasis></link> section that can be used to provide
-information for the associated review. If you provide information here,
-the release record itself can be used as review documentation; no
-further documentation is required.</simpara>
-<simpara>Each section on the review page includes a little help to describe the
-sort of information that you should provide.</simpara>
-<simpara>All major and minor releases require a review. Service releases (i.e.
-bug fix releases that do not change public APIs or add new
-functionality) do not require a review.</simpara>
-<simpara>If a release requires a review, you can schedule one by clicking the
-"Schedule a review" button. The drop-down list above the button contains
-several options for review dates. Pick the one that works best for you.</simpara>
-<simpara>Note that this form will not appear if a review has already been
-scheduled, or the release date does not provide enough time to run a
-review (or is in the past). If a review has been scheduled, a link to
-the review will appear.</simpara>
-<simpara>You can edit the review document, but there’s really not all that much
-to edit. A free-form text field is available and can be used if there is
-some need to provide review-specific information that might not
-otherwise be an appropriate part of the release record. <emphasis>This field is
-intended for other types of review (e.g. restructuring or termination
-reviews); we decided to leave it available for release reviews for cases
-in which it might be useful rather than suppress it.</emphasis></simpara>
-<simpara>When the review is displayed, it automatically includes the <emphasis>review</emphasis>
-information from the release record; it shows the review-specific
-information at the top of the page, and includes the <emphasis>review</emphasis>
-information from the release as the rest of the page contents.</simpara>
-<simpara>This can make things a bit confusing when you want to make changes to
-the metadata for a review record. Just remember that the <emphasis>review</emphasis>
-information for a release is stored in the release record.</simpara>
-</section>
-</section>
-<section xml:id="pmi-joining-a-simultaneous-release">
-<title>Joining a Simultaneous Release</title>
-<simpara>Projects cannot add themselves directly to a simultaneous release (e.g.
-<link xlink:href="https://projects.eclipse.org/releases/luna">Luna</link>), but rather must be
-added by the EMO (there is a
-<link xlink:href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=402190">bug open</link> to extend
-this ability to planning council members).</simpara>
-<simpara>To join a simultaneous release:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Create a release record:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Provide at least a description of the release initially;</simpara>
-</listitem>
-<listitem>
-<simpara>The date of the release should generally match that of the
-simultaneous release;</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Send a note to the planning council (Eclipse projects normally do
-this via the
-<link xlink:href="https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev">cross-project-issues-dev
-mailing list</link>) with the name of your project, the name/number of the
-release, and the offset.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The offset indicates how many days after the start of the aggregation
-process for a milestone your project’s bits will be available. If your
-project’s bits depend on a <literal>+1</literal> project’s bits then your project is
-probably a <literal>+2</literal> project, for example.</simpara>
-</section>
-</chapter>
-<chapter xml:id="glossary">
-<title>Glossary</title>
-<glossentry>
-<glossterm>Architecture Council </glossterm>
-<glossdef>
-<simpara>The Eclipse Architecture Council (AC) serves the community by identifying and
-tackling any issues that hinder Eclipse’s continued technological success and
-innovation, widespread adoption, and future growth. This involves technical
-architecture as well as open source processes and social aspects. Comprising
-the finest technical leaders from all community stake holders, it is the council’s
-goal to keep the projects successful and healthy, the processes simple and smooth,
-and the communities vibrant and cohesive.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Architecture Council Mentor </glossterm>
-<glossdef>
-<simpara>The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers.
-All new projects are required to have a minimum of two mentors taken from the ranks
-of the AC. Your project mentors will help you find answers to any questions you may
-have about the Eclipse Development Process and life-in-general within the Eclipse
-community. If your mentor doesn’t have an answer to your question, they can draw
-on the wisdom of the full AC and the EMO.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Board of Directors </glossterm>
-<glossdef>
-<simpara>The business and technical affairs of the Eclipse
-Foundation are managed by or under the direction of the Board of Directors
-(or more simply, "The Board").</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Committer </glossterm>
-<glossdef>
-<simpara>A committer is a software developer who has the necessary rights to write code
-into the project’s source code repository. Committers are responsible for ensuring
-that all code that gets written into the project’s source code repository is of
-sufficient quality. Further, they must ensure that all code written to an
-Eclipse source code repository is clean from an intellectual property point
-of view. This is discussed with more detail below.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Community </glossterm>
-<glossdef>
-<simpara>Community is a nebulous sort of term. Community is the group of individuals and
-organizations that gather around your project. In the case of some projects, the community
-is enormous. Other projects have smaller communities. Developing a
-community is a very important part of being an Eclipse project as it is from the
-community that you get feedback, contributions, fresh ideas, and ultimately new
-committers to help you implement your shared vision.
-The <emphasis>Eclipse Community</emphasis> is formed from the union of the communities that grow
-around individual projects.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Contribution Questionnaire </glossterm>
-<glossdef>
-<simpara>Prior to committing a significant contribution of content from a non-committer
-to an Eclipse project, the committer must fill out a <link linkend="ip-cq">contribution questionnaire</link> (CQ) and
-submit it to the IP Team for approval. In addition to the
-EMO, the relevant PMC must also provide a technical review and approval of the contribution.
-In general, ongoing development by project committers does not require EMO or PMC approval.
-When in doubt, consult the <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">Eclipse IP Due Diligence Process</link>.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Contributor </glossterm>
-<glossdef>
-<simpara>A contributor is anybody who makes contributions to the project. Contributions
-generally take the form of code patches, but may take other forms like comments
-on issues, additions to the documentation, answers to questions in forums, and
-more.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Dash Process </glossterm>
-<glossdef>
-<simpara>The Dash Process, or simply <emphasis>Dash</emphasis>, is a collection of scripts and processes that
-harvest project data for dissemination in charts, <link linkend="ip-iplog">IP Logs</link>, and more.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Dev-list </glossterm>
-<glossdef>
-<simpara>Every project has a <emphasis>development list</emphasis> or <emphasis>dev-list</emphasis>. All project
-committers must subscribe to the list. The dev-list should be the primary means
-of communication between project committers and is the means throuh which the
-Eclipse Foundation’s automated systems communicate with the project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Ecosystem </glossterm>
-<glossdef>
-<simpara>A commercial ecosystem is a system in which companies, organizations, and individuals
-all work together for mutual benefit. There already exists a vast ecosystem of companies
-that base significant parts of their business on Eclipse technology. This takes the
-form of including Eclipse code in products, providing support, and other services.
-You become part of an eco-system by filling the needs of commercial interests, being
-open and transparent, and being responsive to feedback.
-Ultimately, being part of a commercial ecosystem is a great way to ensure the
-longevity of your project: companies that build their business around your project
-are very motivated to contribute to your project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Eclipse </glossterm>
-<glossdef>
-<simpara>Now this is a tough one. For most people in the broader community, "Eclipse" refers to a
-Java IDE based on the JDT project and assembled by the Eclipse Packaging Project. However,
-the term "Eclipse" is also used to refer to the Eclipse Foundation, the eclipse.org website,
-the community, the eco-system, and—​of course—​The Eclipse Project (which is just one of
-the top-level projects hosted by the Eclipse Foundation). Confusing? Yes.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO </glossterm>
-<glossdef>
-<simpara>The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Architecture and Planning
-Councils. The EMO is responsible for providing services to the projects, facilitating
-project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse
-Development Process. The best method of contact with the EMO is by email (<link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link>).
-If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO Executive Director </glossterm>
-<glossdef>
-<simpara>The EMO Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. He is
-ultimately responsible for all the goings-on at the Eclipse Foundation.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO IP Team </glossterm>
-<glossdef>
-<simpara>The EMO Intellectual Property Team (commonly referred to
-as the <emphasis>IP Team</emphasis>) is responsible for implementing the intellectual
-property policy of the Eclipse Foundation.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO Records </glossterm>
-<glossdef>
-<simpara>The EMO Records Team (commonly referred to as <emphasis>EMO Records</emphasis>) is
-responsible for managing committer paperwork and other records
-on behalf of the Eclipse Foundation. Contact the EMO Records team via email
-(<link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>).</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Incubation Phase </glossterm>
-<glossdef>
-<simpara>The purpose of the incubation phase is to establish a fully-functioning open-source project.
-In this context, incubation is about developing the process, the community, and the technology.
-Incubation is a phase rather than a place: new projects may be incubated under any existing project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>IP Due Diligence Process </glossterm>
-<glossdef>
-<simpara>The <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">Intellectual Property Due Diligence Process</link> defines the process by which
-intellectual property is added to a project. All Eclipse committers must be familiar
-with this process.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>IP Log </glossterm>
-<glossdef>
-<simpara>An <link linkend="ip-iplog">IP Log</link> is a record of the intellectual property (IP) contributions to a project.
-This includes such as a list of all committers, past and present, that have worked on the
-code and (especially) those who have made contributions to the current code base.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Member Company </glossterm>
-<glossdef>
-<simpara>The Eclipse Foundation and Eclipse community is supported by our member organizations.
-Through this support, the Eclipse Foundation provides the open source community
-with IT, Intellectual Property, Mentors and Marketing services.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Parallel IP </glossterm>
-<glossdef>
-<simpara>The <link linkend="ip-parallel-ip">Parallel IP Process</link> allows an Eclipse projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Planning Council </glossterm>
-<glossdef>
-<simpara>The Planning Council is responsible for cross-project planning, architectural issues,
-user interface conflicts, and all other coordination and integration issues. The Planning
-Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Project</glossterm>
-<glossdef>
-<simpara>Projects are where the real work happens. Each project has code, committers,
-and resources including a web site, source code repositories, space on the build
-and download server, etc. Projects may act as a parent for one or more child
-projects. Each child project has its own identity, committers, and resource.
-Projects may, but do not necessarily, have a dedicated web site. Projects are sometimes referred
-to as <emphasis>subprojects</emphasis> or as <emphasis>components</emphasis>. The Eclipse Development Process, however,
-treats the terms project, subproject, and component as equivalent.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Project Lead </glossterm>
-<glossdef>
-<simpara>The project lead is more of a position of responsibility than one of power. The
-project lead is immediately responsible for the overall well-being of the project.
-They own and manage the project’s development process, coordinate development,
-facilitate discussion among project committers, ensure that the Eclipse IP
-policy is being observed by the project and more. If you have questions about
-your project, the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>, or anything else, ask
-your project lead.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>PMC </glossterm>
-<glossdef>
-<simpara>Each top-level project is governed by a Project Management Committee (PMC). The
-PMC has one or more leads along with several members. The PMC has numerous
-responsibilities, including the ultimate approval of committer elections, and
-approval of intellectual property contributions. Effectively, the PMC provides
-oversight for each of the projects that are part of the top-level project.
-If you have a question that your project lead cannot
-answer, ask the PMC.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>PMI </glossterm>
-<glossdef>
-<simpara>The Project Management Interface (PMI) is the system that tracks the state
-and progress of Eclipse projects. Project committers can modify the the
-information represented in the PMI, including the project description, and
-information about project releases. Automated systems use this information
-to, for example, generate dashboard and chart information for the project,
-intellectual property logs, etc.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Top-Level Project </glossterm>
-<glossdef>
-<simpara>A top-level project (sometimes referred to as a <emphasis>TLP</emphasis>) is effectively a
-container for projects that do the real work.
-A top-level project does not generally contain code; rather, a top-level project contains
-other projects. Each top-level project defines a charter that, among other
-things defines a scope for the types of projects that it contains. Top-level
-projects are managed by a Project Management Committee.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Webmaster </glossterm>
-<glossdef>
-<simpara>The Webmaster team is responsible for maintaining the IT infrastructure
-of the Eclipse Foundation and the Eclipse forge. You can contact the
-Webmaster team directly via email (<link xlink:href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</link>).</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Working Group </glossterm>
-<glossdef>
-<simpara>Eclipse <link xlink:href="https://www.eclipse.org/org/workinggroups">Working Groups</link> provide
-a vendor-neutral governance structure that allow organizations to freely
-collaborate on new technology development.</simpara>
-</glossdef>
-</glossentry>
-</chapter>
-<chapter xml:id="contact">
-<title>Getting Help</title>
-<simpara>If you have any questions, or are unsure of your responsibilities as a
-project lead or committer, please contact your project mentors or
-<link xlink:href="mailto:emo@eclipse.org">EMO</link>.</simpara>
-</chapter>
-</book>
\ No newline at end of file
diff --git a/handbook/eclipse.html b/handbook/eclipse.html
index 9f7d36f..7848c6f 100644
--- a/handbook/eclipse.html
+++ b/handbook/eclipse.html
@@ -85,6 +85,17 @@
<li><a href="#pmi-joining-a-simultaneous-release">Joining a Simultaneous Release</a></li>
</ul>
</li>
+<li><a href="#trademarks">Branding</a>
+<ul class="sectlevel2">
+<li><a href="#trademarks-background">Naming, Branding, and Trademarks</a></li>
+<li><a href="#trademarks-project">Project Names</a></li>
+<li><a href="#trademarks-website">Project Websites</a></li>
+<li><a href="#trademarks-metadata">Project Metadata</a></li>
+<li><a href="#trademarks-code">Code Namespaces</a></li>
+<li><a href="#trademarks-checklist">Branding Checklist</a></li>
+<li><a href="#trademarks-notes">Important Notes</a></li>
+</ul>
+</li>
<li><a href="#glossary">Glossary</a></li>
<li><a href="#contact">Getting Help</a></li>
</ul>
@@ -2718,6 +2729,650 @@
</div>
</div>
<div class="sect1">
+<h2 id="trademarks">Branding</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This section defines how Eclipse Projects
+must use and display all Eclipse Foundation trademarks as well as how
+they showcase their project’s website within the community and
+ecosystem. The requirements described here are a complement to the
+<a href="https://eclipse.org/legal/logo_guidelines.php">Guidelines
+for Eclipse Logos & Trademarks</a>, targeting Eclipse open source project
+leads and committers specifically.</p>
+</div>
+<div class="paragraph">
+<p>These requirements are meant to promote and improve the image of all
+projects that are part of the Eclipse community, as well as to show that
+all Eclipse Projects are part of our community of developers, adopters
+and users that we believe is an important factor in our mutual success.
+While every project manages their own development within the broader
+<a href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse
+Development Process</a>, a consistent public branding and web presence that
+ties all of our projects together benefits all of us.</p>
+</div>
+<div class="paragraph">
+<p>All projects must conform to these branding requirements before engaging
+in any Release or Graduation Review.</p>
+</div>
+<div class="sect2">
+<h3 id="trademarks-background">Naming, Branding, and Trademarks</h3>
+<div class="paragraph">
+<p>Naming and branding are important issues for project teams to consider:
+both for the project’s future success as well as to help support and
+share the good values from the Eclipse brand itself. Not only can a
+memorable name help new users and contributors find a project, having a
+distinctive name makes the trademark much stronger, and ensures that
+third parties will respect it.</p>
+</div>
+<div class="paragraph">
+<p>To ensure that future trademarks conflicts don’t arise, it is necessary
+to show other parties that Eclipse Foundation trademarks were chosen in
+good faith and with appropriate research. The Eclipse Foundation has
+no business infringing on
+pre-existing trademarks for the software products or services from other
+organizations, whether they are Member organizations or not.</p>
+</div>
+<div class="paragraph">
+<p>All Eclipse projects and corresponding software products are trademarks
+of the Eclipse Foundation. As a legal entity, the Eclipse Foundation
+owns all Eclipse project and corresponding product trademarks on behalf
+of the the Eclipse community. This prevents companies from misusing or
+misrepresenting their products as being the projects. The EMO will
+initiate a trademark review as part of the project creation or renaming
+process. Existing project name trademarks must be transferred to the
+Eclipse Foundation (please see the
+<a href="https://www.eclipse.org/legal/Trademark_Transfer_Agreement.pdf">Trademark
+Transfer Agreement</a>).</p>
+</div>
+<div class="paragraph">
+<p>Who needs these requirements?</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Project teams that want to name or rename a software product;</p>
+</li>
+<li>
+<p>Project teams that want to rename their project; and</p>
+</li>
+<li>
+<p>Anyone submitting a new project proposal</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>All project and product names must be vetted and approved by the EMO.</p>
+</div>
+<div class="sect3">
+<h4 id="_registered_trademarks">Registered Trademarks</h4>
+<div class="paragraph">
+<p>Project teams may request legal trademark registration for their project
+or product name. Since trademark registration requires a non-trivial
+investment in time and money, project teams must work with their PMC and
+the EMO to determine whether not trademark registration is necessary,
+determine in which countries the trademark must be registered, and how
+that registration will impact the project (e.g. adding registration
+marks on the website and in products).</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-background-orgs">Other Organization’s Trademarks</h4>
+<div class="paragraph">
+<p>Project teams must ensure that products names that include other
+organizations’ trademarks in names must be conform to those
+organizations’ trademark usage guidelines. For example, "Eclipse Foo
+Perl" is not appropriate, since it improperly uses the trademark "Perl"
+(which is a trademark of The Perl Foundation); a better project name
+would be "Eclipse Foo for Perl".</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-background-name">Choosing a Name</h4>
+<div class="paragraph">
+<p>Naming and branding are challenging issues that generally require some
+real investment in time and energy. The best project names are
+distinctive and memorable.</p>
+</div>
+<div class="paragraph">
+<p>Project teams should start the process of securing the trademark for a
+name as early as is practical. This is required to ensure the EMO has
+sufficient time to review and approve the name.</p>
+</div>
+<div class="paragraph">
+<p>A project team should start this process:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>When they first begin preparing a project proposal;</p>
+</li>
+<li>
+<p>As soon as their project wants to name a new software product; or</p>
+</li>
+<li>
+<p>Before initiating a Restructuring Review to change a project name</p>
+</li>
+</ul>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABHNCSVQICAgIfAhkiAAABplJREFUWIXFl3uMVkcVwH9n5t7v+3aXBcpzgaUFojxLWSAiyLLsgmKqpUiL1KKSErTG1ERjYivWmhoMtcbUxhiNtdUgljSE5eGCSZvyWimmLS2lsmF5P1sWLOWxu9/j3jtz/ONbqoVlQah6kvPHnZkz85szZ86cCzchbl3NIzdjD2Bu1DBfXz1Mlan5+uph/xcAk5IZZmA1xsqM/zmAKoItmymTfoIJS+tUkY8MIKqfOjm3qmZoV0ZR/bSxpv/EUJP90K8qHa391JiuxufW1g6J10yf0llfcHlDSHjShP7XbkPdQaP6jMze2nyFUcBd0vp+iu1PgvOpwNrZwJ7LxxVW144MAr9Y1Y+IQ/+tzgA6dZ1rqFsmIxbe7rOnEz3+4lFVtyI1p3HXpX5dVVtBSetFmf1GVhsmlmLKu8vnt7Zc6o/qp02Q0HxFBs8aYsoGBW7vH/aGc7Z1emM6Bcivrvl4MHTGk3bCjwI9sRbf9AKu/d0lqfKyoz4bfV1DuR+VEahPI3oRIwdI3HKLfwHhVufsE+bWiTDqi/i9LyfJsZe+n7ln+/7rBgBw66f/TKoeGqnv7MjFp3YuCQKtUluy3AyblJaKMaFk+oCE4NvR3Gn01NuRHt2dxcs3k0Jhp0mnlgYDRpdpS9M+e3fj9662zlUBtKFunAtuWZpkz3wnTAULtPuAH9rx96UximabIT4FSSuIh1R/pHQ0eMG/uSbPhfPLYuKVAcEvbGAfk9lbdv/HAACF1VPHWDGjpE/lCvOJBzKa3QOF44ikUBy4PPgckANiSH8MKRmNvlGf863nv+Ridyg975WmrtboMg+kysuOSso+Y6rmZbT9bcgfAluKpnpC0AOxpWBCwIIC0T60bRcydnoJIr9Pnc13eu7XDeByufvltqoyjIdsE4gpalAGYTlqUxRvckc7QPYw+HZkwMDurqJ8wbUAPpQH9PHHTTx2U5UN5G6T6G8TYx5k4O0pbX8TcOBjxMdo3AZGQH2HpRRVARRtPYLpOyh0LacWa/20l7xlkUEamNO4R6Q46kMAurF6uFc7M5bXa4NBMy0X/pHi4vEL+IvDJXMLev5d0AQ0Rn0WiRVEUB8BMeAB7YgogcI56DkMvI7H2VY1frLr3rvKb5zlojW5zV51U+be7YcBjFs7/WEXmZ9Lr0l3hp9rKGHMghS+gMxuyApaAgqaBUlAC+CzqGtFk1bwWfBREQ4PqkX1CdgQlIzM39oGYMYNyQR1vywLKibPDox52q2d/rCuqu0mALquZnAMdSZIf8b0GVtC29mUvH9sgUvrCVv7QE+98CIQgVrQEMR2hI8vLi4dmjgoeEgCpN943N82tdvIVLjQr9SyngUpZCN8tCn2ZnPJ3K1HPzgC+ULjCeCPqqxgQzzCx+5OwXbDyk5tO/lp6AHaAtKxQwyoFL/xIK4YD4kWNeiOXryAWnOQMrpJzCuu7b2Nqbk7mi6PgS7zQLKu9j4ZNHC5GTI6redehdCAlX8FHVpUrxB7iBUKHul7B/7oYdWzp74RzPnr77pao8traHtQT8s75zWJIDUQCq6osQPnii6PPUS+A8BDpgKNPXr2TNZmSlZ2Nf81AaJz0Uif6EK/59W8lFdCalDxjAse8h3nXXCQ91DQYkruXonu3e1xuohC+5AbBojW14y3EiwLjDksufwP3Os7Ikn1QnpVQdAbYgMFjyYhBL2R3ndApi/+7685ovyPbdrtds4+oQ1147oCuKIguSRizJdN5UTikzuX+nz0WOD8Eb9rx3Pap38P03uAlV6VYEPEObTtAv7YIfVnz+TFu/lJ4poDm1pKucXn/FeBqz5GnQLoxurhrmLGMEZ9ltBnS93Jpqecc0tSQXawa+Fef/b0IjxjUC0HIjWyzyTmuSCOVlCSvg0xT5lSq4ybAvvbhmoDIzurrK4K4BP7NVteaZOmvzhzqumgV/+nf3vVVmj9tJdxtlXmb2vTVbXdKKObzN1yqSJqLqypeUTbk4XS3DrC9JkQJmfeehD4bqeevrwh11B9a5iYX6mRvS7WZzPzGg9cPiZeU/OoCJ/8YBJlh72n8adXeHJD9TDv7WJ1OjaO+XbJ/MYj1/RAxgf9EP+QzNl2ojNiAE+y3pRXVNmqoWn/1oF8cvG9DZ3u7q7th4FHtWHKIC+2ErgC4IZEFUk2znretzf/Odk46/mP9L/gekQE9XFuC7ufxce5LZen1/86AIB3utmffg3vdPONznHT4tZMv2q1e71ywx4AMIn85mYB/gmUfSU64pXP4AAAAABJRU5ErkJggg==" alt="Note">
+</td>
+<td class="content">
+Renaming projects (i.e. after a project has been created
+and provisioned) requires significant work on the part of the
+infrastructure team, and can be disruptive and confusing for consumers.
+Project teams should start the process as early as possible once they
+have a candidate name.
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="trademarks-project">Project Names</h3>
+<div class="paragraph">
+<p>A project, as defined by the Eclipse Development Process, is the main
+operational unit; all open source software development at Eclipse
+occurs within the context of a project. The
+Eclipse Foundation holds the trademark for all Eclipse Projects.</p>
+</div>
+<div class="paragraph">
+<p>All project names must be approved by the Eclipse Management
+Organization (EMO) either before a project is created or before an
+existing project is renamed.</p>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-formal">Formal Name</h4>
+<div class="paragraph">
+<p>The primary branding for any project name is fully-qualified formal name
+which includes the “Eclipse” prefix (e.g. “Eclipse Woolsey Intellectual
+Property Tools” or “Eclipse Woolsey Framework”). This ensures that
+the project is associated with the Eclipse Foundation in the community,
+ecosystem, and the minds of users and adopters. However, Eclipse
+Projects are oftentimes known by many names: it is common for a project
+to have both a formal and a nickname or commonly-used acronym.</p>
+</div>
+<div class="paragraph">
+<p>The formal name may include a brand name and/or a descriptive name.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-brand">Brand Names</h4>
+<div class="paragraph">
+<p>Project teams should strongly consider choosing a brand name. “Woolsey”,
+“Apogy”, and “Whiskers” are examples of brand names that are distinctive
+and memorable; they make the project easier to talk and write about than
+a wordier descriptive name. These names are not descriptive and so don’t
+stand well on their own; combining a brand name with a descriptive name
+(e.g. “Eclipse Woolsey Intellectual Property Tools”) can help in this
+regard.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-descriptive">Descriptive Names</h4>
+<div class="paragraph">
+<p>Projects are encouraged to use a descriptive name. Descriptive names
+provide context that can help a casual viewer appreciate the purpose of
+the project in way that is difficult or impossible to convey with a
+brand name "Graphical Modeling Framework", "Trust Framework" or "Component
+Assembly Tools" are examples of descriptive names..</p>
+</div>
+<div class="paragraph">
+<p>The best names do not include the word "Project", and are—in formal
+contexts—prepended by "Eclipse". The project name should still work with
+or without the prefix. For example, "Graphical Modeling Framework" and
+"Eclipse Graphical Modeling Framework" are equally understandable.</p>
+</div>
+<div class="paragraph">
+<p>Descriptive names may optionally include the words "Framework",
+“Platform”, or "Tools" if the project has a specific emphasis on
+extensible frameworks, a platform, or obvious development tooling
+technology. 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", “Platform”, and "Tools" mean different
+things to different people and may be becoming overused.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-nick">Nicknames</h4>
+<div class="paragraph">
+<p>A project may have a nickname or common name that is a shorter form of
+the formal name (and will likely be the same as the brand name). The
+“Eclipse Woolsey Intellectual Property Tools” project may be referred to
+as “Eclipse Woosley” or simply “Woolsey”. An acronym may be used as a
+nickname (e.g. “ECF” and “GMF”).</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-acronym">Acronyms For Long Names</h4>
+<div class="paragraph">
+<p>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”.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABHNCSVQICAgIfAhkiAAABplJREFUWIXFl3uMVkcVwH9n5t7v+3aXBcpzgaUFojxLWSAiyLLsgmKqpUiL1KKSErTG1ERjYivWmhoMtcbUxhiNtdUgljSE5eGCSZvyWimmLS2lsmF5P1sWLOWxu9/j3jtz/ONbqoVlQah6kvPHnZkz85szZ86cCzchbl3NIzdjD2Bu1DBfXz1Mlan5+uph/xcAk5IZZmA1xsqM/zmAKoItmymTfoIJS+tUkY8MIKqfOjm3qmZoV0ZR/bSxpv/EUJP90K8qHa391JiuxufW1g6J10yf0llfcHlDSHjShP7XbkPdQaP6jMze2nyFUcBd0vp+iu1PgvOpwNrZwJ7LxxVW144MAr9Y1Y+IQ/+tzgA6dZ1rqFsmIxbe7rOnEz3+4lFVtyI1p3HXpX5dVVtBSetFmf1GVhsmlmLKu8vnt7Zc6o/qp02Q0HxFBs8aYsoGBW7vH/aGc7Z1emM6Bcivrvl4MHTGk3bCjwI9sRbf9AKu/d0lqfKyoz4bfV1DuR+VEahPI3oRIwdI3HKLfwHhVufsE+bWiTDqi/i9LyfJsZe+n7ln+/7rBgBw66f/TKoeGqnv7MjFp3YuCQKtUluy3AyblJaKMaFk+oCE4NvR3Gn01NuRHt2dxcs3k0Jhp0mnlgYDRpdpS9M+e3fj9662zlUBtKFunAtuWZpkz3wnTAULtPuAH9rx96UximabIT4FSSuIh1R/pHQ0eMG/uSbPhfPLYuKVAcEvbGAfk9lbdv/HAACF1VPHWDGjpE/lCvOJBzKa3QOF44ikUBy4PPgckANiSH8MKRmNvlGf863nv+Ridyg975WmrtboMg+kysuOSso+Y6rmZbT9bcgfAluKpnpC0AOxpWBCwIIC0T60bRcydnoJIr9Pnc13eu7XDeByufvltqoyjIdsE4gpalAGYTlqUxRvckc7QPYw+HZkwMDurqJ8wbUAPpQH9PHHTTx2U5UN5G6T6G8TYx5k4O0pbX8TcOBjxMdo3AZGQH2HpRRVARRtPYLpOyh0LacWa/20l7xlkUEamNO4R6Q46kMAurF6uFc7M5bXa4NBMy0X/pHi4vEL+IvDJXMLev5d0AQ0Rn0WiRVEUB8BMeAB7YgogcI56DkMvI7H2VY1frLr3rvKb5zlojW5zV51U+be7YcBjFs7/WEXmZ9Lr0l3hp9rKGHMghS+gMxuyApaAgqaBUlAC+CzqGtFk1bwWfBREQ4PqkX1CdgQlIzM39oGYMYNyQR1vywLKibPDox52q2d/rCuqu0mALquZnAMdSZIf8b0GVtC29mUvH9sgUvrCVv7QE+98CIQgVrQEMR2hI8vLi4dmjgoeEgCpN943N82tdvIVLjQr9SyngUpZCN8tCn2ZnPJ3K1HPzgC+ULjCeCPqqxgQzzCx+5OwXbDyk5tO/lp6AHaAtKxQwyoFL/xIK4YD4kWNeiOXryAWnOQMrpJzCuu7b2Nqbk7mi6PgS7zQLKu9j4ZNHC5GTI6redehdCAlX8FHVpUrxB7iBUKHul7B/7oYdWzp74RzPnr77pao8traHtQT8s75zWJIDUQCq6osQPnii6PPUS+A8BDpgKNPXr2TNZmSlZ2Nf81AaJz0Uif6EK/59W8lFdCalDxjAse8h3nXXCQ91DQYkruXonu3e1xuohC+5AbBojW14y3EiwLjDksufwP3Os7Ikn1QnpVQdAbYgMFjyYhBL2R3ndApi/+7685ovyPbdrtds4+oQ1147oCuKIguSRizJdN5UTikzuX+nz0WOD8Eb9rx3Pap38P03uAlV6VYEPEObTtAv7YIfVnz+TFu/lJ4poDm1pKucXn/FeBqz5GnQLoxurhrmLGMEZ9ltBnS93Jpqecc0tSQXawa+Fef/b0IjxjUC0HIjWyzyTmuSCOVlCSvg0xT5lSq4ybAvvbhmoDIzurrK4K4BP7NVteaZOmvzhzqumgV/+nf3vVVmj9tJdxtlXmb2vTVbXdKKObzN1yqSJqLqypeUTbk4XS3DrC9JkQJmfeehD4bqeevrwh11B9a5iYX6mRvS7WZzPzGg9cPiZeU/OoCJ/8YBJlh72n8adXeHJD9TDv7WJ1OjaO+XbJ/MYj1/RAxgf9EP+QzNl2ojNiAE+y3pRXVNmqoWn/1oF8cvG9DZ3u7q7th4FHtWHKIC+2ErgC4IZEFUk2znretzf/Odk46/mP9L/gekQE9XFuC7ufxce5LZen1/86AIB3utmffg3vdPONznHT4tZMv2q1e71ywx4AMIn85mYB/gmUfSU64pXP4AAAAABJRU5ErkJggg==" alt="Note">
+</td>
+<td class="content">
+Acronyms often become brand names.
+</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-existing">Existing Software Product Names</h4>
+<div class="paragraph">
+<p>To avoid confusion between Eclipse Projects and commercial products,
+Eclipse projects may not be named after commercial products and vice
+versa. To ensure that users understand the source of software
+products—i.e. from an Eclipse Foundation project, or from a third party
+vendor—the brand for an Eclipse project must not include or be directly
+reminiscent of a commercial product.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-short">Short Names and Ids</h4>
+<div class="paragraph">
+<p>Projects require a short name; this name is used to as an ID for the
+project in various parts of Eclipse Foundation infrastructure and should
+be as reflective of the formal name as possible. It may, for example,
+be a lowercase rendering of the brand name, or an acronym of a
+descriptive name.</p>
+</div>
+<div class="paragraph">
+<p>The short name may contain lowercase alphanumeric characters, dashes,
+and underlines. The short name may not contain periods (.). Short names
+are used in URLs like <a href="http://www.eclipse.org/<shortname>" class="bare">http://www.eclipse.org/<shortname></a>;, project
+download directories, and in other parts of the supported
+infrastructure.</p>
+</div>
+<div class="paragraph">
+<p>The short name is joined with the short name of the parent project(s) to
+form a qualified identifier for the project that is used as a key on
+many of the webpages and services generated and/or maintained for the
+project by the Eclipse Foundation. e.g. the "Eclipse Woolsey" project
+has a short name of "woolsey"; its qualified name is
+"technology.dash.woolsey", indicating that it is a subproject of the
+Eclipse Dash Project which is itself a subproject of the Eclipse
+Technology Top Level Project.</p>
+</div>
+<div class="paragraph">
+<p>Project names should always be referred to in a consistent casing, and
+used as an adjective (never as a noun or verb) like any trademark should
+be used (e.g. "Download Eclipse Woolsey software here", using the
+Woolsey name as an adjective for software).</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-product">Product Names</h4>
+<div class="paragraph">
+<p>A product is a specific, downloadable software product that users or
+consumers might want to use in some way. Most projects release a product
+with the same name (e.g. the Eclipse Woolsey project releases a software
+product called “Eclipse Woolsey”) or some variation of the project name
+(e.g. “Eclipse Woolsey SDK”).</p>
+</div>
+<div class="paragraph">
+<p>Most open source projects produce products that share the project name.
+There are, however, numerous examples of projects that produce
+additional products. The Eclipse CDO project, for example, has a product
+named “Dawn”; and the Eclipse Graphical Editing Framework project has a
+product named “Zest”.</p>
+</div>
+<div class="paragraph">
+<p>Product names should also be prefixed with “Eclipse” when used in any
+formal context (e.g. <em>Eclipse Dawn</em> or <em>Eclipse Zest</em>).</p>
+</div>
+<div class="paragraph">
+<p>Project teams should work with their PMC to determine whether or not to
+pursue assertion of ownership of the trademark for product names.
+Project teams should work with the Eclipse Management Organization (EMO)
+to assert ownership of product trademarks.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-description">Project Descriptions</h4>
+<div class="paragraph">
+<p>All Eclipse Projects require a description. The project description must
+include a brief sentence or short paragraph (no bullets) that explains
+the primary function of the software deliverables provided. For example:</p>
+</div>
+<div class="paragraph">
+<p>The Eclipse C/C++ Development Tooling™ (CDT) project provides a fully
+functional C and C++ Integrated Development Environment based on the
+Eclipse Platform.</p>
+</div>
+<div class="paragraph">
+<p>The complete description can certainly include much more information,
+but starting with a short paragraph is a great service for new readers
+to the project’s website, and is important for the Eclipse Foundation to
+maintain an overall list of project trademarks for software products.
+While this trademark description style may sometimes seem clumsy in
+technical documentation, it is a critical way that the Eclipse
+Foundation enforces trademarks.</p>
+</div>
+<div class="paragraph">
+<p>Project teams may seek guidance from the PMC and EMO to ensure that the
+text is a proper trademark goods description; i.e. one that describes
+the specific functionality of the software available for download and
+use.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-project-logo">Logos And Graphics</h4>
+<div class="paragraph">
+<p>Logos are important to recognize as trademarks as well. For a project’s
+official logo (if it has one, and especially if it uses the Eclipse
+globe in any way), the designer must ensure that it includes a small
+trademark (™) or registered trademark (®) symbol (as appropriate) in
+the graphic or immediately adjacent to it.</p>
+</div>
+<div class="paragraph">
+<p>Projects may may request to use the Eclipse Logo within their project
+logo, or otherwise create a derivative of the Eclipse Logo. However,
+they must contact the EMO to request the Board’s permission to do so.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="trademarks-website">Project Websites</h3>
+<div class="paragraph">
+<p>The official project website is the primary means of learning about the
+project and getting involved: people who are interested in contributing
+to the project come here to learn about technical details, and to
+observe the project’s development process.</p>
+</div>
+<div class="paragraph">
+<p>Eclipse Projects must host all project content on an eclipse.org domain,
+especially the official/primary website for project-related information,
+communications, access to source code, and downloads. This ensures both
+that the Eclipse Webmaster team can maintain the services, and informs
+consumers that the content comes from an Eclipse Project, and not a
+third party. This further ensures that the project remains independent
+of any specific vendor or single individual.</p>
+</div>
+<div class="paragraph">
+<p>All primary links to the project (including, for example, the project’s
+contribution guide) must point directly to the official website, and not
+to external sites or domains.</p>
+</div>
+<div class="sect3">
+<h4 id="trademarks-website-name">Name References</h4>
+<div class="paragraph">
+<p>The first reference to a project or product on
+every web page—especially in page titles or headers—must use the formal
+name and must include the relevant trademark (™) or registered trademark
+(®) symbol (e.g. “Eclipse Woolsey Intellectual Property Tools™”). If the
+webpage features an otherwise prominent reference to the project or
+product (e.g. in a callout), that reference should also use the formal
+name. Other references may use the nickname or acronym (e.g. “Eclipse
+Woolsey” or “Woolsey”) as appropriate.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-website-footer">Footers</h4>
+<div class="paragraph">
+<p>All project web pages must include a footer that prominently displays an
+approved Eclipse Logo, important links back to key pages, and a
+copyright notice.</p>
+</div>
+<div class="paragraph">
+<p>Approved Eclipse logos are available on the
+<a href="https://www.eclipse.org/artwork">Eclipse Logos and Artwork</a> page.</p>
+</div>
+<div class="paragraph">
+<p>The following minimal set of links must be included on the footer of all
+pages in the official project website:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Main Eclipse Foundation website (<a href="http://www.eclipse.org" class="bare">http://www.eclipse.org</a>);</p>
+</li>
+<li>
+<p>Privacy policy (<a href="http://www.eclipse.org/legal/privacy.php" class="bare">http://www.eclipse.org/legal/privacy.php</a>);</p>
+</li>
+<li>
+<p>Website terms of use (<a href="http://www.eclipse.org/legal/termsofuse.php" class="bare">http://www.eclipse.org/legal/termsofuse.php</a>);</p>
+</li>
+<li>
+<p>Copyright agent (<a href="http://www.eclipse.org/legal/copyright.php" class="bare">http://www.eclipse.org/legal/copyright.php</a>); and</p>
+</li>
+<li>
+<p>Legal (<a href="http://www.eclipse.org/legal" class="bare">http://www.eclipse.org/legal</a>).</p>
+</li>
+</ul>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABHNCSVQICAgIfAhkiAAABplJREFUWIXFl3uMVkcVwH9n5t7v+3aXBcpzgaUFojxLWSAiyLLsgmKqpUiL1KKSErTG1ERjYivWmhoMtcbUxhiNtdUgljSE5eGCSZvyWimmLS2lsmF5P1sWLOWxu9/j3jtz/ONbqoVlQah6kvPHnZkz85szZ86cCzchbl3NIzdjD2Bu1DBfXz1Mlan5+uph/xcAk5IZZmA1xsqM/zmAKoItmymTfoIJS+tUkY8MIKqfOjm3qmZoV0ZR/bSxpv/EUJP90K8qHa391JiuxufW1g6J10yf0llfcHlDSHjShP7XbkPdQaP6jMze2nyFUcBd0vp+iu1PgvOpwNrZwJ7LxxVW144MAr9Y1Y+IQ/+tzgA6dZ1rqFsmIxbe7rOnEz3+4lFVtyI1p3HXpX5dVVtBSetFmf1GVhsmlmLKu8vnt7Zc6o/qp02Q0HxFBs8aYsoGBW7vH/aGc7Z1emM6Bcivrvl4MHTGk3bCjwI9sRbf9AKu/d0lqfKyoz4bfV1DuR+VEahPI3oRIwdI3HKLfwHhVufsE+bWiTDqi/i9LyfJsZe+n7ln+/7rBgBw66f/TKoeGqnv7MjFp3YuCQKtUluy3AyblJaKMaFk+oCE4NvR3Gn01NuRHt2dxcs3k0Jhp0mnlgYDRpdpS9M+e3fj9662zlUBtKFunAtuWZpkz3wnTAULtPuAH9rx96UximabIT4FSSuIh1R/pHQ0eMG/uSbPhfPLYuKVAcEvbGAfk9lbdv/HAACF1VPHWDGjpE/lCvOJBzKa3QOF44ikUBy4PPgckANiSH8MKRmNvlGf863nv+Ridyg975WmrtboMg+kysuOSso+Y6rmZbT9bcgfAluKpnpC0AOxpWBCwIIC0T60bRcydnoJIr9Pnc13eu7XDeByufvltqoyjIdsE4gpalAGYTlqUxRvckc7QPYw+HZkwMDurqJ8wbUAPpQH9PHHTTx2U5UN5G6T6G8TYx5k4O0pbX8TcOBjxMdo3AZGQH2HpRRVARRtPYLpOyh0LacWa/20l7xlkUEamNO4R6Q46kMAurF6uFc7M5bXa4NBMy0X/pHi4vEL+IvDJXMLev5d0AQ0Rn0WiRVEUB8BMeAB7YgogcI56DkMvI7H2VY1frLr3rvKb5zlojW5zV51U+be7YcBjFs7/WEXmZ9Lr0l3hp9rKGHMghS+gMxuyApaAgqaBUlAC+CzqGtFk1bwWfBREQ4PqkX1CdgQlIzM39oGYMYNyQR1vywLKibPDox52q2d/rCuqu0mALquZnAMdSZIf8b0GVtC29mUvH9sgUvrCVv7QE+98CIQgVrQEMR2hI8vLi4dmjgoeEgCpN943N82tdvIVLjQr9SyngUpZCN8tCn2ZnPJ3K1HPzgC+ULjCeCPqqxgQzzCx+5OwXbDyk5tO/lp6AHaAtKxQwyoFL/xIK4YD4kWNeiOXryAWnOQMrpJzCuu7b2Nqbk7mi6PgS7zQLKu9j4ZNHC5GTI6redehdCAlX8FHVpUrxB7iBUKHul7B/7oYdWzp74RzPnr77pao8traHtQT8s75zWJIDUQCq6osQPnii6PPUS+A8BDpgKNPXr2TNZmSlZ2Nf81AaJz0Uif6EK/59W8lFdCalDxjAse8h3nXXCQ91DQYkruXonu3e1xuohC+5AbBojW14y3EiwLjDksufwP3Os7Ikn1QnpVQdAbYgMFjyYhBL2R3ndApi/+7685ovyPbdrtds4+oQ1147oCuKIguSRizJdN5UTikzuX+nz0WOD8Eb9rx3Pap38P03uAlV6VYEPEObTtAv7YIfVnz+TFu/lJ4poDm1pKucXn/FeBqz5GnQLoxurhrmLGMEZ9ltBnS93Jpqecc0tSQXawa+Fef/b0IjxjUC0HIjWyzyTmuSCOVlCSvg0xT5lSq4ybAvvbhmoDIzurrK4K4BP7NVteaZOmvzhzqumgV/+nf3vVVmj9tJdxtlXmb2vTVbXdKKObzN1yqSJqLqypeUTbk4XS3DrC9JkQJmfeehD4bqeevrwh11B9a5iYX6mRvS7WZzPzGg9cPiZeU/OoCJ/8YBJlh72n8adXeHJD9TDv7WJ1OjaO+XbJ/MYj1/RAxgf9EP+QzNl2ojNiAE+y3pRXVNmqoWn/1oF8cvG9DZ3u7q7th4FHtWHKIC+2ErgC4IZEFUk2znretzf/Odk46/mP9L/gekQE9XFuC7ufxce5LZen1/86AIB3utmffg3vdPONznHT4tZMv2q1e71ywx4AMIn85mYB/gmUfSU64pXP4AAAAABJRU5ErkJggg==" alt="Note">
+</td>
+<td class="content">
+An appropriate footer is included automatically by the default website
+infrastructure and the PMI.
+</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-website-external">External Websites</h4>
+<div class="paragraph">
+<p>Websites on external (non-eclipse.org) domains that
+use a project name trademark (e.g. www.mosquitto.com) but are not hosted
+by the Eclipse Foundation, may be employed as user community portals.
+External websites may be appropriate for some forms of documentation,
+community-generated content, and pointers to community forums. The user
+portal may help the user find information about what the project
+software does and how to get it.</p>
+</div>
+<div class="paragraph">
+<p>Only existing, well-known domains that are already heavily linked and
+known by the community are permitted as external domains. For other
+historical domains that are not an important part of the project’s
+brand, permanent (301) redirects should point to the official project
+website hosted on Eclipse Foundation infrastructure.</p>
+</div>
+<div class="paragraph">
+<p>The user portal is not a replacement for a developer portal which takes
+form in the official project website as described by this document.</p>
+</div>
+<div class="paragraph">
+<p>Projects with widely-used historical domain names may continue using the
+non-eclipse.org domain with these considerations:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Ownership of the domain name must be transferred to the Eclipse
+Foundation;</p>
+</li>
+<li>
+<p>The domain must be regarded and treated as a user community portal;</p>
+</li>
+<li>
+<p>The first and most prominent reference to an Eclipse Project or
+corresponding product name on every web page must use the formal name
+and must include the relevant trademark or registered trademark symbol
+(subsequent references may use the nickname or acronym as appropriate);</p>
+</li>
+<li>
+<p>All references to Eclipse Project names must be prefixed with
+“Eclipse”;</p>
+</li>
+<li>
+<p>The website must include trademark attributions for all Eclipse
+Foundation trademarks used on the site (see below); and</p>
+</li>
+<li>
+<p>Contributors must be directed to the eclipse.org site for information
+regarding contribution or related development activities.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>User-focused portals must include a prominent text paragraph or sidebar
+that points to the official project website, so that users interested in
+contributing or otherwise participating in the open source project know
+where to go.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="trademarks-website-attribution">Trademark Attributions</h4>
+<div class="paragraph">
+<p>The external website must include a prominent trademark attribution of
+all applicable Eclipse Foundation marks.</p>
+</div>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="paragraph">
+<p>Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey,
+Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are
+either registered trademarks or trademarks of The Eclipse Foundation in
+the United States and/or other countries.</p>
+</div>
+<div class="paragraph">
+<p>This can appear anywhere on the website.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="trademarks-metadata">Project Metadata</h3>
+<div class="paragraph">
+<p>All Projects must keep their metadata updated regularly in the central
+<a href="http://www.eclipse.org/projects/handbook#pmi">Eclipse
+Project Management Infrastructure (PMI)</a> tool. Projects using alternate
+site content generation and management tools must ensure that all
+relevant metadata is kept up-to-date in the PMI tool to ensure that
+other infrastructure tools and processes can make connections to and
+disseminate information for the project.</p>
+</div>
+<div class="paragraph">
+<p>The project description, scope, and other free-form text fields in the
+PMI must conform to the project naming guidelines.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABHNCSVQICAgIfAhkiAAABplJREFUWIXFl3uMVkcVwH9n5t7v+3aXBcpzgaUFojxLWSAiyLLsgmKqpUiL1KKSErTG1ERjYivWmhoMtcbUxhiNtdUgljSE5eGCSZvyWimmLS2lsmF5P1sWLOWxu9/j3jtz/ONbqoVlQah6kvPHnZkz85szZ86cCzchbl3NIzdjD2Bu1DBfXz1Mlan5+uph/xcAk5IZZmA1xsqM/zmAKoItmymTfoIJS+tUkY8MIKqfOjm3qmZoV0ZR/bSxpv/EUJP90K8qHa391JiuxufW1g6J10yf0llfcHlDSHjShP7XbkPdQaP6jMze2nyFUcBd0vp+iu1PgvOpwNrZwJ7LxxVW144MAr9Y1Y+IQ/+tzgA6dZ1rqFsmIxbe7rOnEz3+4lFVtyI1p3HXpX5dVVtBSetFmf1GVhsmlmLKu8vnt7Zc6o/qp02Q0HxFBs8aYsoGBW7vH/aGc7Z1emM6Bcivrvl4MHTGk3bCjwI9sRbf9AKu/d0lqfKyoz4bfV1DuR+VEahPI3oRIwdI3HKLfwHhVufsE+bWiTDqi/i9LyfJsZe+n7ln+/7rBgBw66f/TKoeGqnv7MjFp3YuCQKtUluy3AyblJaKMaFk+oCE4NvR3Gn01NuRHt2dxcs3k0Jhp0mnlgYDRpdpS9M+e3fj9662zlUBtKFunAtuWZpkz3wnTAULtPuAH9rx96UximabIT4FSSuIh1R/pHQ0eMG/uSbPhfPLYuKVAcEvbGAfk9lbdv/HAACF1VPHWDGjpE/lCvOJBzKa3QOF44ikUBy4PPgckANiSH8MKRmNvlGf863nv+Ridyg975WmrtboMg+kysuOSso+Y6rmZbT9bcgfAluKpnpC0AOxpWBCwIIC0T60bRcydnoJIr9Pnc13eu7XDeByufvltqoyjIdsE4gpalAGYTlqUxRvckc7QPYw+HZkwMDurqJ8wbUAPpQH9PHHTTx2U5UN5G6T6G8TYx5k4O0pbX8TcOBjxMdo3AZGQH2HpRRVARRtPYLpOyh0LacWa/20l7xlkUEamNO4R6Q46kMAurF6uFc7M5bXa4NBMy0X/pHi4vEL+IvDJXMLev5d0AQ0Rn0WiRVEUB8BMeAB7YgogcI56DkMvI7H2VY1frLr3rvKb5zlojW5zV51U+be7YcBjFs7/WEXmZ9Lr0l3hp9rKGHMghS+gMxuyApaAgqaBUlAC+CzqGtFk1bwWfBREQ4PqkX1CdgQlIzM39oGYMYNyQR1vywLKibPDox52q2d/rCuqu0mALquZnAMdSZIf8b0GVtC29mUvH9sgUvrCVv7QE+98CIQgVrQEMR2hI8vLi4dmjgoeEgCpN943N82tdvIVLjQr9SyngUpZCN8tCn2ZnPJ3K1HPzgC+ULjCeCPqqxgQzzCx+5OwXbDyk5tO/lp6AHaAtKxQwyoFL/xIK4YD4kWNeiOXryAWnOQMrpJzCuu7b2Nqbk7mi6PgS7zQLKu9j4ZNHC5GTI6redehdCAlX8FHVpUrxB7iBUKHul7B/7oYdWzp74RzPnr77pao8traHtQT8s75zWJIDUQCq6osQPnii6PPUS+A8BDpgKNPXr2TNZmSlZ2Nf81AaJz0Uif6EK/59W8lFdCalDxjAse8h3nXXCQ91DQYkruXonu3e1xuohC+5AbBojW14y3EiwLjDksufwP3Os7Ikn1QnpVQdAbYgMFjyYhBL2R3ndApi/+7685ovyPbdrtds4+oQ1147oCuKIguSRizJdN5UTikzuX+nz0WOD8Eb9rx3Pap38P03uAlV6VYEPEObTtAv7YIfVnz+TFu/lJ4poDm1pKucXn/FeBqz5GnQLoxurhrmLGMEZ9ltBnS93Jpqecc0tSQXawa+Fef/b0IjxjUC0HIjWyzyTmuSCOVlCSvg0xT5lSq4ybAvvbhmoDIzurrK4K4BP7NVteaZOmvzhzqumgV/+nf3vVVmj9tJdxtlXmb2vTVbXdKKObzN1yqSJqLqypeUTbk4XS3DrC9JkQJmfeehD4bqeevrwh11B9a5iYX6mRvS7WZzPzGg9cPiZeU/OoCJ/8YBJlh72n8adXeHJD9TDv7WJ1OjaO+XbJ/MYj1/RAxgf9EP+QzNl2ojNiAE+y3pRXVNmqoWn/1oF8cvG9DZ3u7q7th4FHtWHKIC+2ErgC4IZEFUk2znretzf/Odk46/mP9L/gekQE9XFuC7ufxce5LZen1/86AIB3utmffg3vdPONznHT4tZMv2q1e71ywx4AMIn85mYB/gmUfSU64pXP4AAAAABJRU5ErkJggg==" alt="Note">
+</td>
+<td class="content">
+The PMI supports teasers or summaries for many fields; ensure that
+these teasers also conform to the guidelines.
+</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="trademarks-code">Code Namespaces</h3>
+<div class="paragraph">
+<p>Where applicable and supported by the programming languages and style
+used by the project, code namespaces must include the project’s short
+name.</p>
+</div>
+<div class="paragraph">
+<p>In Java, for example, package names must start with org.eclipse and use
+their short name in the third-segment (i.e. follow the pattern
+<code>org.eclipse.<shortname>.<component></code>), e.g. <code>org.eclipse.ecf.core</code>,
+<code>org.eclipse.woolsey.ui</code>, and <code>org.eclipse.buckminster.connector</code>. Component
+names are left to the discretion of the project team.</p>
+</div>
+<div class="paragraph">
+<p>The project team must petition the Planning Council via their PMC to
+request exceptions.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="trademarks-checklist">Branding Checklist</h3>
+<div class="paragraph">
+<p>All projects must conform to these branding guidelines before engaging
+in any Release or Graduation Review.</p>
+</div>
+<div class="paragraph">
+<p>Project branding checklist:</p>
+</div>
+<div class="ulist square">
+<ul class="square">
+<li>
+<p>The primary development website is hosted on Eclipse
+Foundation-provided infrastructure;</p>
+</li>
+<li>
+<p>The primary development website is accessible through
+www.eclipse.org/<short-name>;</p>
+</li>
+<li>
+<p>The first occurrence of project name on all webpages uses the formal
+name and is prefixed with “Eclipse”;</p>
+</li>
+<li>
+<p>The project website includes a concise description of the project (and
+includes all necessary marks);</p>
+</li>
+<li>
+<p>The required navigation links (e.g. www.eclipse.org) are included in
+the website footer;</p>
+</li>
+<li>
+<p>Attributions for all Eclipse Foundation marks are included, and
+trademark and registered trademark symbols are used appropriately;</p>
+</li>
+<li>
+<p>Attributions for all other marks are included, and trademark and
+registered trademark symbols are used appropriately;</p>
+</li>
+<li>
+<p>Logos and graphics include the trademark symbol;</p>
+</li>
+<li>
+<p>The product logo is used consistently; and</p>
+</li>
+<li>
+<p>PMI metadata complete and up to date</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="trademarks-notes">Important Notes</h3>
+<div class="paragraph">
+<p>Nothing in this Eclipse Foundation document shall be interpreted
+to allow any third party to claim any association with the Eclipse
+Foundation or any of its projects or to imply any approval or support by
+the Eclipse Foundation for any third party products, services, or
+events, unless specifically covered by an Eclipse Membership agreement.</p>
+</div>
+<div class="paragraph">
+<p>Questions? Project participants who have questions about Eclipse
+Foundation trademarks either used here or at third party sites should
+contact the <a href="mailto:license@eclipse.org">license@eclipse.org</a>[EMO Legal]. Other organizations looking for information
+on how to use or refer to any Eclipse Foundation project trademarks or
+logos should see the
+<a href="https://eclipse.org/legal/logo_guidelines.php">Guidelines for Eclipse Logos & Trademarks</a>.</p>
+</div>
+<div class="paragraph">
+<p>Thanks and credit to the Apache Software Foundation’s
+<a href="http://www.apache.org/foundation/marks/pmcs">Project
+Branding Requirements</a> (licensed under the Apache License, v2.0)
+for parts of this trademark section.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
<h2 id="glossary">Glossary</h2>
<div class="sectionbody">
<div class="dlist glossary">
@@ -2954,7 +3609,7 @@
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2015-08-18 15:09:59 -04:00
+Last updated 2016-04-25 15:37:12 -04:00
</div>
</div>
</body>
diff --git a/handbook/eclipse.pdf b/handbook/eclipse.pdf
deleted file mode 100644
index cbb036b..0000000
--- a/handbook/eclipse.pdf
+++ /dev/null
Binary files differ
diff --git a/handbook/locationtech.book.xml b/handbook/locationtech.book.xml
deleted file mode 100644
index c9bd63a..0000000
--- a/handbook/locationtech.book.xml
+++ /dev/null
@@ -1,2128 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?asciidoc-toc?>
-<?asciidoc-numbered?>
-<book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-<info>
-<title>LocationTech Project Handbook</title>
-<date>2015-08-18</date>
-</info>
-<chapter xml:id="notices">
-<title>Notices</title>
-<simpara>Copyright © 2015 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0</simpara>
-</chapter>
-<chapter xml:id="preamble">
-<title>Overview</title>
-<simpara>This document provides you with the information that you need to
-create a new LocationTech open source project or become a committer
-on an existing one.</simpara>
-<simpara>While this document is focused on LocationTech, it makes several
-"Eclipse" references, including the <emphasis>Eclipse Foundation</emphasis>,
-<emphasis>Eclipse Development Process</emphasis>, and <emphasis>Eclipse Management Organization</emphasis>.
-The Eclipse Foundation is the legal entity that manages the operations
-of the LocationTech working group, software development forge, and community.
-Many of the provided services and contacts are so-named on
-that basis.</simpara>
-<simpara>The <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link> (EDP) is the foundational
-document for LocationTech projects and committers. It describes the
-manner in which we do open source software. The Eclipse Development
-Process does not prescribe any particular development methodology;
-it is more concerned with the larger-scale aspects of open source
-project lifecycle, including such things as reviews, processes for
-running votes and elections, bringing new committers onto a project, etc.
-This document will elaborate on some key points of the Eclipse Development
-Process.</simpara>
-<section xml:id="preamble-principles">
-<title>Principles</title>
-<simpara>Four basic principles lie at the heart of the Eclipse Development Process:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Transparency;</simpara>
-</listitem>
-<listitem>
-<simpara>Openness;</simpara>
-</listitem>
-<listitem>
-<simpara>Meritocracy; and</simpara>
-</listitem>
-<listitem>
-<simpara>Vendor neutrality</simpara>
-</listitem>
-</itemizedlist>
-<simpara>We refer to the first three as the "open source rules of engagement".</simpara>
-<simpara>To operate with <emphasis role="strong">transparency</emphasis>, a project’s discussions, minutes, deliberations,
-project plans, plans for new features, and other artifacts are open, public,
-and easily accessible.</simpara>
-<simpara><emphasis role="strong">Openness</emphasis> at LocationTech means quite a lot more than "open book" (which is
-really a synonym for transparent). The project is open to all;
-LocationTech provides the same opportunity to all. Everyone participates
-with the same rules; there are no rules to exclude any potential contributors
-which include, of course, direct competitors in the marketplace.</simpara>
-<simpara>LocationTech is a <emphasis role="strong">meritocracy</emphasis>. The more that somebody contributes, the more
-responsibility they will earn. A pattern of quality contribution to a project
-may lead to an invitation to join the project as a committer. Leadership roles
-in LocationTech are also merit-based and earned by peer acclaim. Merit must be
-demonstrated in publicly-accessible forums. Committers and project leads are
-added to a project via <link linkend="elections">election</link>.</simpara>
-<note>
-<simpara>Employment status has no bearing at whether or not somebody can participate
-in an open source project at LocationTech. Employment does not guarantee
-committer status; committer status must be earned by everybody.</simpara>
-</note>
-<simpara><emphasis role="strong">Vendor neutrality</emphasis> is similar to openness in that it’s concerned with
-maintaining a level playing field. No vendor is permitted to dominate a project,
-and nobody can be excluded from participating
-in a project based on their employment status. While
-project resources will contain copyright statements that assert ownership of
-various assets by individual vendors, the project itself must remain vendor
-neutral.</simpara>
-<simpara>Quality and intellectual property cleanliness are also important principles.</simpara>
-<simpara><emphasis role="strong">Quality</emphasis> means extensible frameworks and exemplary tools developed in an open,
-inclusive, and predictable process involving the entire community. From the
-consumption perspective, LocationTech quality means good for users (exemplary tools
-are cool/compelling to use, indicative of what is possible) and ready for
-use by adopters. From the creation perspective, LocationTech quality means working
-with a transparent and open process, open and welcoming to participation from
-technical leaders, regardless of affiliation.</simpara>
-<simpara><emphasis role="strong"><link linkend="ip">Intellectual property</link></emphasis> (IP) is any artifact that is made available from
-a LocationTech server (this includes source code management systems, the website,
-and the downloads server). Artifacts include (but are not limited to) such things
-as source code, images, XML and configuration files, documentation, and more.
-Strict rules govern the way that we manage IP and your responsibilities
-as a committer.</simpara>
-<simpara>Code produced by an LocationTech project is used by organizations to build products.
-These adopters of LocationTech technology need to have some assurance that the IP they’re
-basing their products on is <emphasis role="strong">clean</emphasis>: the organization or individuals who claim
-copyright of the code are the legitimate copyright holders, and the copyright
-holders legitimately agree to make the code available under the license(s) that
-the project works under. As a committer, you must be careful that you do not copy
-code and inadvertently claim it as your own.</simpara>
-</section>
-</chapter>
-<chapter xml:id="starting">
-<title>Starting an Open Source Project at LocationTech</title>
-<simpara>LocationTech open source projects start with a proposal that is made
-available to the community for review. At the end of the <emphasis>community
-review</emphasis> period, we engage in a <emphasis>creation review</emphasis>, and then
-provision the project resources.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/project-creation.png"/>
-</imageobject>
-<textobject><phrase>An overview of the Project Creation Process</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Use the <link xlink:href="https://www.locationtech.org/node/add/project-proposal">web form</link> to create a new project proposal.
-Instructions are provided on the form. All new proposals are created
-in <emphasis>draft</emphasis> mode, and are accessible only by the original author and
-anybody designated as a project lead or committer in the proposal.
-Only those individuals designated as a project lead may edit the
-proposal.</simpara>
-<note>
-<simpara>Keep track of the URL of the proposal. We do not provide
-public links to the document until after the proposal is opened for
-community review.</simpara>
-</note>
-<simpara>A proposal must minimally include a description of the project, a
-declaration of scope, and a list of prospective members (project
-leads and committers) before we make it accessible to the public
-for <emphasis>community review</emphasis>.</simpara>
-<simpara>When you feel that the proposal is ready, send a note to
-the Eclipse Management Organization (EMO) at <link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link> requesting that
-the proposal be made available to the public for review. The EMO
-will review the proposal and may provide feedback before initiating
-the <emphasis>community review</emphasis> period.</simpara>
-<simpara>At the beginning of the <emphasis>community review</emphasis> period, the EMO will
-announce the proposal on several channels (the <link xlink:href="http://www.eclipse.org/projects/project_activity.php">Project
-Activity News</link> page, Twitter, the
-<link xlink:href="http://www.eclipse.org/forums/eclipse.proposals">Proposals Forum</link>, blog post, and an email note
-to the Eclipse Foundation members and committers). The EMO will
-also open an record in the Eclipse Foundation’s issue tracker—​an
-instance of Bugzilla—​to track the progress of the proposal;
-the proposal’s author and project leads will be copied on that record.</simpara>
-<simpara>A proposal will be open for community review for a minimum of two
-weeks.</simpara>
-<simpara>The Eclipse Foundation holds the <emphasis>trademark</emphasis> for all LocationTech projects.
-Trademark assignment is undertaken prior to the creation of any new
-project. If you already have a trademark on your project name, that
-trademark must be assigned to the Eclipse Foundation. Be advised that
-trademark assignment can be a time-consuming process (it can take hours,
-days, or weeks depending on the circumstances surrounding the name).
-If you currently hold the trademark, you will be asked to complete a
-<link xlink:href="http://eclipse.org/legal/Trademark_Transfer_Agreement.pdf">Trademark Transfer Agreement</link>.</simpara>
-<simpara>The proposal must list two mentors from the Architecture Council.
-Members of the Architecture Council have considerable experience with
-Eclipse Foundation practices, and the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>.
-If you are already in contact with mentors who agree to help you with
-your project, please do list them in the proposal. Otherwise, the
-EMO will engage directly with the Architecture Council to identify
-mentors as necessary. Mentors are available to the project through the
-incubation phase; they are released from their duties when the project
-<link linkend="release-graduation">graduates</link>.</simpara>
-<simpara>When the project name trademark has been secured, mentors have been
-identified, and the proposal contents are finalized, the EMO will schedule
-a <emphasis>creation review</emphasis>. Reviews—​which run for a minimum of one week—​are
-scheduled twice a month, generally concluding on the first and third
-Wednesday of each month. The creation review may overlap with the
-<emphasis>community review</emphasis> period.</simpara>
-<note>
-<simpara>Creation reviews tend to always be successful. They should be
-considered low stress as the hard work has already been done in
-advance of the start of the review.</simpara>
-</note>
-<simpara>Following the creation review, the EMO will initiate the provisioning process.
-To gain committer status, some <link linkend="paperwork">committer paperwork</link> must be completed
-as part of the provisioning process. The exact nature of that
-paperwork depends on several factors, including the employment status
-of the individual and the Eclipse Foundation membership status of their employer.</simpara>
-<note>
-<simpara>If you can be ready with the paperwork in time for the completion of the
-creation review, then we can move quickly through the provisioning process.
-When we initiate provisioning, committers will be sent an email with
-instructions; please don’t send any paperwork in until after you receive
-those instructions.</simpara>
-</note>
-<section xml:id="starting-after-provisioning">
-<title>After Provisioning</title>
-<simpara>The Webmaster will send a note announcing the completion of the provisioning
-process. Before you commit any code into your project repository, you must
-submit your project’s <link linkend="ip-initial-contribution"><emphasis>initial contribution</emphasis></link> and
-list of third-party libraries for review by the IP team.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/post-creation.png"/>
-</imageobject>
-<textobject><phrase>Post creation activities</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Do not commit any code to your project’s source code repository until after
-you receive approval for the IP Team. Once you’ve received that approval,
-you can do builds and produce milestones for your first release. You must
-wait until after the IP Team has approved your initial contribution and use
-of third-party libraries before you do any official <link linkend="release">releases</link>.</simpara>
-</section>
-<section xml:id="starting-project-phases">
-<title>Project Phases</title>
-<simpara>All new projects start in the <emphasis>incubation phase</emphasis> (a project in the
-incubation phase is said to be <emphasis>incubating</emphasis>). The classification of
-a project in the incubation phase is not a statement about the quality
-of the project’s code; rather, incubation phase is more about the
-project team’s progress in practicing the open and public processes
-necessary to establish the three communities (developers, adopters,
-and users) around the project.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Egg-incubation.png"/>
-</imageobject>
-<textobject><phrase>The Incubation Logo</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>In order to alert potential consumers of the incubating nature,
-projects in the incubation phase must include <emphasis>incubation branding</emphasis>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Display the incubation logo on their project web page (if they have one);</simpara>
-</listitem>
-<listitem>
-<simpara>Displays the incubation logo on their project’s primary download page;</simpara>
-</listitem>
-<listitem>
-<simpara>Include the word "incubation" in the filename of all downloadable
-files (when technically feasible) for builds and milestones;</simpara>
-</listitem>
-<listitem>
-<simpara>When technically feasible, include the word "incubation" in features
-(e.g. about dialogs, feature lists, and installers).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>There are no incubation branding requirements for general
-user interface elements.</simpara>
-<simpara>For projects that produce OSGi artifacts, include the word
-"incubation" in the <emphasis>Bundle-Name</emphasis>, feature names, and p2 repositories.</simpara>
-<note>
-<simpara>The word "incubation" should not be included in technical
-namespaces (especially when it may result in confusion when the project
-leaves incubation). e.g. an OSGi bundle’s <emphasis>Bundle-SymbolicName</emphasis>, or a
-Java package name.</simpara>
-</note>
-<simpara>Incubating projects that correctly conform to the incubation branding
-rules outlined above may take advantage of the <link linkend="ip-parallel-ip">Parallel
-IP Process</link>. They are encouraged to produce milestone builds, make
-releases, and grow their community.</simpara>
-<simpara>When the project code is ready (e.g. stable APIs) and the project team
-has learned to operate as an open source project according to the
-Eclipse Development Process, the project may opt to <emphasis>graduate</emphasis> into
-the <emphasis>mature phase</emphasis>.</simpara>
-<simpara>Most of the lifetime of a LocationTech project is spent in the mature phase.
-A mature project is one that is a good open source citizen with open,
-transparent, and meritocractic behavior. The project is regularly
-and predictably releasing IP clean extensible frameworks and
-exemplary tools. The project is actively nurturing the three
-communities: developers, adopters, and users.</simpara>
-</section>
-<section xml:id="starting-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>How do I find Architecture Council mentors? </simpara>
-</question>
-<answer>
-<simpara>You don’t have to find them yourself. Focus on the content of the
-proposal. We can solicit mentors from the Architecture Council after
-the proposal has been opened for community review.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I change the proposal after it is posted? </simpara>
-</question>
-<answer>
-<simpara>Yes. The proposal can be changed any time before the start of the
-start of the creation review.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>When do I submit my code for review by the IP team? </simpara>
-</question>
-<answer>
-<simpara>Submit your code (initial contribution) for review after the project
-has been provisioned. The Eclipse Webmaster will let you know via
-email when provisioning is complete.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Does the new project have to use Git? </simpara>
-</question>
-<answer>
-<simpara>Yes. Git is the only source code management system that is currently
-permitted for new projects.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I host my project code on GitHub? </simpara>
-</question>
-<answer>
-<simpara>New projects can make use of <link linkend="resources-github">GitHub</link>. Official project repositories
-must be moved under the <link xlink:href="https://github.com/locationtech">LocationTech Organization</link> at GitHub.
-Official repositories are subject to the same intellectual
-property due diligence rules and processes that all Eclipse project
-repositories must follow.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How long should I let my project incubate? </simpara>
-</question>
-<answer>
-<simpara>It depends. Community expectations are one factor. Team experience
-with open source is another. If your team is new to open source,
-it may make sense to stay in incubation a little longer than a
-seasoned team with a mature code base might. As a general rule,
-though, projects should plan to leave incubation within a year.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Does the mature project code that I’m bring to LocationTech need to incubate? </simpara>
-</question>
-<answer>
-<simpara>Yes. All new projects start in the incubation phase. Remember
-that incubation is as much about the project team learning about
-how to operate as an open source project as it is about the
-project code. Project teams that "get it" can opt to exit
-incubation quickly (e.g. with their first release) if that
-makes sense for the team and the community.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What do all these terms (e.g. EMO) mean? </simpara>
-</question>
-<answer>
-<simpara>Please see the <link linkend="glossary">glossary</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="project-resources-and-services">
-<title>Project Resources and Services</title>
-<simpara>Open source projects at the Eclipse Foundation are required to make use
-of certain Eclipse Foundation services:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>All project issues must be tracked in the <link xlink:href="https://www.locationtech.org/bugs">LocationTech Bugzilla</link>
-instance;</simpara>
-</listitem>
-<listitem>
-<simpara>Source code must be maintained in source code repositories assigned to the
-project (e.g. a LocationTech <link xlink:href="https://git.locationtech.org/c">Git</link> or <link xlink:href="https://git.locationtech.org/r">Gerrit</link> instance,
-or the <link xlink:href="https://github.com/locationtech">LocationTech Organization</link> on GitHub);</simpara>
-</listitem>
-<listitem>
-<simpara>All third-party libraries used by the project must be tracked and
-approved for use by the Eclipse IP Team;</simpara>
-</listitem>
-<listitem>
-<simpara>Downloads must be distributed via a forge-specific downloads server;</simpara>
-</listitem>
-<listitem>
-<simpara>Developer (committer) communication must occur in the <emphasis>dev</emphasis> list
-provided to the project by the Eclipse; and</simpara>
-</listitem>
-<listitem>
-<simpara>Projects must keep their <link linkend="pmi-metadata">Project Metadata</link> up-to-date.</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="resources-source">
-<title>Source Code Management</title>
-<simpara>Your project must maintain source code in the repositories assigned to the
-project by the Eclipse Foundation. These official repositories must be
-the exclusive source of all project code delivered via the project’s assigned
-distribution channel (e.g. the download server).</simpara>
-<simpara>In order for your project to operate in an <emphasis>open</emphasis> manner, it must be possible
-for potential contributors to have access to the code base in its most current
-form, so all ongoing development must be regularly pushed to these canonical
-repositories.</simpara>
-<section xml:id="resources-cla">
-<title>Contributor License Agreement (CLA)</title>
-<simpara>The Eclipse Foundation has implemented <link xlink:href="https://www.eclipse.org/legal/CLA.php">Contributor License Agreements</link> (CLA)
-to improve <link linkend="ip">intellectual property</link> (IP) management and workflow. All
-contributors, who are not committers on the LocationTech project, must sign the CLA.</simpara>
-<simpara>You do <emphasis role="strong">not</emphasis> require a CLA to contribute to a project on which you have committer
-status.</simpara>
-</section>
-<section xml:id="resources-commit">
-<title>Git Commit Records</title>
-<simpara>Git commit records are required to take a specific form. The credentials
-of the actual author must be used to populate the <literal>Author</literal> field. The email
-address used must match the email address that the Eclipse Foundation has
-on file for the author (case-sensitive).</simpara>
-<simpara>The commit message is divided into three sections:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>One line (max 72 characters) summary;</simpara>
-</listitem>
-<listitem>
-<simpara>Description; and</simpara>
-</listitem>
-<listitem>
-<simpara>Footer.</simpara>
-</listitem>
-</orderedlist>
-<formalpara>
-<title>Example Git Commit Record</title>
-<para>
-<screen>commit d6cf52411377a039fc2906378711091a26e932cb
-Author: Some Body <somebody@somewhere.com> <co xml:id="CO1-1"/>
-Date: Wed May 29 16:17:36 2013 +0200
-
- Bug 350686 - Hide unwanted action bar items <co xml:id="CO1-2"/>
-
- This change hides unwanted 'Link with Editor' and
- 'Customize View...' items from the local toolbar
- and the view menu.
-
- Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 <co xml:id="CO1-3"/>
- Also-by: Some Bodyelse <somebodyelse@nowhere.com> <co xml:id="CO1-4"/>
- Signed-off-by: Some Body <somebody@somewhere.com> <co xml:id="CO1-5"/></screen>
-</para>
-</formalpara>
-<calloutlist>
-<callout arearefs="CO1-1">
-<para>The email address of the author must match the email address on the Eclipse Foundation account.</para>
-</callout>
-<callout arearefs="CO1-2">
-<para>Best practice: include the bug id in the commit message summary.</para>
-</callout>
-<callout arearefs="CO1-3">
-<para>Gerrit change id (only when pushing to Gerrit for review).</para>
-</callout>
-<callout arearefs="CO1-4">
-<para>Additional authors can be added using <literal>Also-by</literal> entries.</para>
-</callout>
-<callout arearefs="CO1-5">
-<para>Non-committers must <emphasis>sign-off</emphasis> the commit using the same email address as used in the author field.</para>
-</callout>
-</calloutlist>
-<simpara>The <emphasis>summary</emphasis> line is used in many places where Git commits are listed, ensure
-that this line is sensible by itself. The <emphasis>description</emphasis> area should be used to provide
-more detail about the commit. The footer area is used for extra fields and values.</simpara>
-<simpara>If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx")
-Gerrit Code Review will automatically add a link in the
-corresponding Bugzilla record back to the Gerrit record (this, of course, only
-applies to commits pushed to Gerrit).</simpara>
-<simpara>The <literal>Change-Id</literal> is used by <link linkend="resources-gerrit">Gerrit Code Review</link> to associate new versions
-of a change back to its original review. This field need only be specified if the
-repository is managed by Gerrit.</simpara>
-<simpara>Create a separate <literal>Also-by</literal> field for each additional author of a commit. This might
-apply, for example, if a commit has been authored via pair-programming, or the commit
-is the result of collapsing multiple commits authored by multiple developers.</simpara>
-<simpara>Commits that are provided by non-committers must have a <literal>Signed-off-by</literal> field in the
-footer indicating that the author is aware of the terms by which the contribution has been
-provided to the project. The non-committer must additionally have an Eclipse Foundation
-account and must have a signed <link linkend="resources-cla">Contributor License Agreement</link> (CLA)
-on file.</simpara>
-</section>
-<section xml:id="resources-git">
-<title>Git</title>
-<simpara>Those projects that want to use Git on the LocationTech forge, are assigned a
-directory in which they may create as many Git repositories as required.
-<link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Git">Open a bug</link> to request that the Webmaster create a new Git
-repository for your project. Alternatively, committers with shell accounts
-can create repositories themselves.</simpara>
-<formalpara>
-<title>Create a new Git repository</title>
-<para>
-<screen>> initrepo /gitroot/project/org.locationtech.repo.name.git</screen>
-</para>
-</formalpara>
-<simpara>For consistency, the name of the repository must end with <literal>.git</literal>.</simpara>
-<simpara>To set the description of the repository, use <literal>sftp</literal> or <literal>scp</literal> to copy a text file to
-<literal>/gitroot/project/org.locationtech.repo.name.git/description</literal>. Git repository
-descriptions should be limited to a paragraph of one or two sentences.</simpara>
-<simpara>Only project committers can push to a LocationTech Git repository. A push
-that includes commits that do not conform to the required form will be rejected.</simpara>
-<simpara>You can <link xlink:href="https://git.locationtech.org/c">browse LocationTech repositories</link> directly on the Git server.</simpara>
-</section>
-<section xml:id="resources-gerrit">
-<title>Gerrit Code Review</title>
-<simpara><link xlink:href="https://www.gerritcodereview.com/">Gerrit</link> provides web based code review and
-repository management for the Git version control system. Many projects use
-Gerrit to reduce barriers and encourage contribution to the project.
-<link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Gerrit">Open a bug</link> to request that the Webmaster configure your
-Git repository for Gerrit.</simpara>
-<simpara>Commits may be pushed directly to the Git repository through Gerrit by
-a project committer (e.g. to the <literal>master</literal> branch).</simpara>
-<simpara>Anybody can push to a <literal>refs/for/*</literal> branch for review in a Gerrit repository. A push
-that includes commits that do not conform to the required form will be rejected.
-Commits intended for review should have a
-<link xlink:href="https://git.eclipse.org/r/Documentation/user-changeid.html"><literal>Change-Id</literal></link></simpara>
-<simpara>You can <link xlink:href="https://git.locationtech.org/r">browse LocationTech repositories</link> directly on the Gerrit
-server.</simpara>
-</section>
-<section xml:id="resources-github">
-<title>GitHub</title>
-<simpara>Projects may opt to move some or all of their canonical source code repositories to the
-<link xlink:href="https://github.com/locationtech">LocationTech organization</link> on GitHub.</simpara>
-<note>
-<simpara>Projects that host source code on GitHub are not permitted to use GitHub
-Issues or Wiki.</simpara>
-</note>
-<simpara><link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=GitHub">Open a bug</link> to request that the Webmaster create a new, or move
-an existing, Git repository for your project. The Webmaster will install some
-<emphasis>hooks</emphasis> on your GitHub repository.</simpara>
-<simpara>The <emphasis>Committers hook</emphasis> grants designated project committers write access to the
-GitHub-hosted project repositories. Project committers must use the email address they
-provide to the Eclipse Foundation as their GitHub email address.</simpara>
-<simpara>The <link linkend="resources-cla">Contributor License Agreement</link> (CLA) hook will inspect incoming
-GitHub pull requests to ensure that the contributor has a valid CLA on file, and that
-the commit has been "signed-off" as required. Project committers should only merge pull
-<emphasis>green</emphasis> requests:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Github-cla-success.png"/>
-</imageobject>
-<textobject><phrase>Github cla success</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>The GitHub API does not give us a means of absolutely denying a merge; all we can
-do is warn you that the contributors have not signed a CLA:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Github-cla-failure.png"/>
-</imageobject>
-<textobject><phrase>Github cla failure</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Do not merge unless you are absolutely certain that the contributer does have a
-valid CLA on file (e.g. the Contributor License Agreement Lookup Tool confirms
-that they have a CLA).</simpara>
-<simpara>You must manually check that the commit message includes the
-required "Signed-off-by" statement in the footer.</simpara>
-<simpara>The Webmaster creates and maintains a mirror of all GitHub-hosted
-repositories on Eclipse Foundation hardware.</simpara>
-</section>
-</section>
-<section xml:id="resources-libraries">
-<title>Third-party Libraries</title>
-<simpara>LocationTech projects must register all of their <link linkend="ip-third-party">third-party library</link> use with the
-IP Team.</simpara>
-</section>
-<section xml:id="resources-forums">
-<title>Forums and Outbound Communication</title>
-<simpara>All projects are assigned a <link xlink:href="http://www.locationtech.org/forums">user forum</link> as a point of contact between
-the user and adopter communities, and the project developers.</simpara>
-<simpara>The EMO strongly encourages the use of alternative communication channels for
-connecting with the community: your project team knows your community and how
-to best connect with them.</simpara>
-</section>
-<section xml:id="resources-website">
-<title>Project Websites</title>
-<simpara>Project websites are an excellent way to connect your project with
-your community. Many projects opt to use the <link linkend="pmi">Project Management Infrastructure</link>
-(PMI) as their project website,
-but if so-desired, a project may host a website on Eclipse Foundation-hosted
-servers.</simpara>
-<simpara>Project website sources are hosted in Git repositories maintained by the
-Eclipse Foundation. <link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Website">Open a bug</link> to request that the Webmaster
-create a website for your project.</simpara>
-<note>
-<simpara>Alternative hosting services for project-specific websites are
-not permitted. Websites <emphasis>not</emphasis> hosted by the Eclipse Foundation are
-considered third-party and so are subject to the
-<link xlink:href="https://eclipse.org/legal/logo_guidelines.php">Guidelines for Eclipse
-Logo & Trademarks</link> (the Eclipse foundation asserts ownership of the
-project name trademark).</simpara>
-</note>
-</section>
-<section xml:id="resources-builds">
-<title>Builds</title>
-<simpara>Use of Eclipse Foundation-provided and hosted build services, the so-called
-<link xlink:href="http://wiki.eclipse.org/CBI">Common Build Infrastructure</link> (CBI) is strongly recommended, but n
-ot strictly required.</simpara>
-<simpara>Whether or not your project chooses to make use of provided build resources, it must
-be possible for members of the community to build project artifacts from
-source code with reasonable effort.</simpara>
-<section xml:id="resources-signing">
-<title>Signed Artifacts</title>
-<simpara>Where technically sensible, all downloadable artifacts should
-be <link xlink:href="https://wiki.eclipse.org/JAR_Signing">signed</link> by an Eclipse Foundation-provided certificate.</simpara>
-</section>
-</section>
-<section xml:id="resources-downloads">
-<title>Downloads</title>
-<simpara>Project artifacts (e.g. downloads) can be distributed via third-party
-services (e.g. Maven Central), but the Eclipse Foundation-provided
-infrastructure must be considered the primary source of project
-downloads.</simpara>
-<simpara>Project committers can <link xlink:href="https://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads">upload project artifacts</link> to the project’s
-directory on the download server.</simpara>
-</section>
-</chapter>
-<chapter xml:id="paperwork">
-<title>Committer Paperwork</title>
-<simpara>The Eclipse Foundation needs to ensure that all committers with write
-access to the code, web site, and issue tracking system understand their role in
-safeguarding the intellectual property of LocationTech. The Eclipse Foundation also
-needs to ensure that we have accurate records of the people who are
-acting as change agents on the projects. To ensure that
-committers understand their role, and that that Eclipse Foundation has
-accurate records, committers must provide documentation asserting
-that they have read, understood, and will follow the committer guidelines, and to have
-their employer sign that they agree that the new committer
-can participate at LocationTech and can contribute under the terms of the
-project license.</simpara>
-<simpara>All committers must complete the <emphasis>Committer Questionnaire</emphasis> and provide documentation
-as described below.</simpara>
-<section xml:id="paperwork-questionnaire">
-<title>Committer Questionnaire</title>
-<simpara>The <link xlink:href="http://portal.eclipse.org">Committer Questionnaire</link> is an online form that
-must be completed by all new committers. This form offers two separate paths:
-one for committers who work for a member company that has provided a signed
-Member Committer Agreement, and one for everybody else.</simpara>
-<note>
-<simpara>The <emphasis>Committer Questionnaire</emphasis> is accessible only after you have been elected as
-a committer on a project, either as an initial committer on a new project, or
-via election on an existing project.</simpara>
-</note>
-<simpara>Only member companies that have provided a signed Member Committer Agreement
-will be listed as member companies in the Committer Questionnaire.</simpara>
-</section>
-<section xml:id="paperwork-documents">
-<title>Documents</title>
-<simpara>The exact nature of the documentation required is dependent on your
-employments status.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/paperwork.png" width="75%" scalefit="1"/>
-</imageobject>
-<textobject><phrase>Paperwork requirements flowchart.</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Documents must be printed, signed and then returned either by fax
-(using the fax number on the form) or as scanned images via email
-to <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-<section xml:id="paperwork-mca">
-<title>Member Committer Agreement</title>
-<simpara>The <link xlink:href="http://www.eclipse.org/legal/committer_process/EclipseMemberCommitterAgreementFinal.pdf">Member Committer Agreement</link> (MCA) is used by member companies to
-cover all of their employees who participate in Eclipse Foundation projects
-as committers.</simpara>
-<simpara>If your employer has provided a signed MCA, then you most likely do not
-require any additional paperwork.</simpara>
-<note>
-<simpara>MCAs make committer paperwork easy, especially if you
-work for a member company that employs multiple committers. With an MCA a
-company can provide signed documentation once, rather than once for each
-employee (as required for an Individual Committer Agreement).</simpara>
-</note>
-<simpara>If your employer has not already provided an MCA, consult with your management
-team to determine who has the necessary authority to sign it on your company’s
-behalf. Provide the MCA in advance of the completion of your committer election
-or new project creation to streamline the committer provisioning process.
-If you and your management team are not sure whether or
-not your employer has an MCA, ask <link xlink:href="mailto:emo-records@eclipse.org">EMO Records</link>.</simpara>
-<simpara>If your employer is a member company that cannot provide a signed
-MCA, then you’ll have to complete an Individual Committer Agreement and
-Eclipse Committer Employer Consent Form.</simpara>
-</section>
-<section xml:id="paperwork-ica">
-<title>Individual Committer Agreement</title>
-<simpara>The Individual Committer Agreement (ICA) greement is used by committers
-who are not covered by an Member Committer Agreement.</simpara>
-<simpara>You will need to provide an ICA if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>You work for member company that has not signed a Member Committer Agreement;</simpara>
-</listitem>
-<listitem>
-<simpara>You work for a company that is not a member of the Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>You are self employed or not employed; or</simpara>
-</listitem>
-<listitem>
-<simpara>You are a student.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If you provide an Individual Committer Agreement, and are employed
-or self-employed, then you also need an <emphasis>Eclipse Committer Employer</emphasis>
-Consent Form.</simpara>
-</section>
-<section xml:id="paperwork-ececf">
-<title>Eclipse Committer Employer Consent Form</title>
-<simpara>Committers covered by an Individual Committer Agreement must document
-the consent of their employer when participating in Eclipse Foundatio
-projects by providing an Eclipse Committer Employer Consent Form (ECECF).</simpara>
-<simpara>You will need to provide an <link xlink:href="http://www.eclipse.org/legal/committer_process/employer_consent.pdf">ECECF</link> if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>You work for member company that has not signed a Member Committer Agreement;</simpara>
-</listitem>
-<listitem>
-<simpara>You work for a company that is not a member of the Eclipse Foundation; or</simpara>
-</listitem>
-<listitem>
-<simpara>You are self-employed.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If you are self employed, an owner of your own company, or
-have full ownership or part ownership in another company and has the
-authority to sign and submit the Eclipse Committer Employer Consent Form
-on your own behalf, then they should do so.</simpara>
-<simpara>Alternatively, you may arrange for the company that is
-your principal business customer to sign and submit the
-Eclipse Committer Employer Consent Form on your behalf.</simpara>
-</section>
-</section>
-<section xml:id="paperwork-existing">
-<title>Existing Committer</title>
-<simpara>If you are already a committer on an existing Eclipse Foundation project then
-additional paperwork may or may not be needed. The EMO IP Team will ask for
-additional documentation if required.</simpara>
-<simpara>If that MCA or ECECF already explicitly covers you for the
-new project, or that MCA or ECECF is universal (for all projects),
-then no additional paperwork is required</simpara>
-<simpara>If you are covered by an MCA or ECECF that does not include
-the new project, then the candidate must provide the documents as described
-above.</simpara>
-</section>
-<section xml:id="paperwork-not-employed">
-<title>Not Employed or Student</title>
-<simpara>If you are not employed or are a student, send a note to <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>
-explaining your not employed or student status.</simpara>
-<note>
-<simpara>We require this email because most new committers are employed by a company,
-the Eclipse Legal Team assumes that is the case for everyone, thus exceptions
-need to be noted.</simpara>
-</note>
-</section>
-<section xml:id="paperwork-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>What happens if I do not fill out the paperwork?</simpara>
-</question>
-<answer>
-<simpara>Then you don’t get your login and password for write-access to the
-source code repository(s). Sorry. No exceptions.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What happens if I cannot convince my employer to fill out the paperwork?</simpara>
-</question>
-<answer>
-<simpara>The Eclipse Board of Directors has taken a firm position that if you are
-employed then you must meet one of the scenarios described above. If you cannot
-convince your employer to fill out the necessary paperwork, then you may
-not have write-access to project resources. This is the
-Board’s position <emphasis>even if</emphasis> you are working on LocationTech projects on your
-own time. We realize that this prevents some talented and desirable
-people from being able to commit to the projects but this is our
-IP risk reduction strategy.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Where can I get help to discuss these documents with my management team? </simpara>
-</question>
-<answer>
-<simpara>The EMO and the Executive Director are happy to talk to your management
-and senior executives about these (and other) legal documents to
-help them understand why these documents are the best risk reduction
-solution for everyone involved (The Eclipse Foundation, you, and your
-employer); just contact us at <link xlink:href="mailto:license@eclipse.org">license@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What formats can be used to submit paper documentation? </simpara>
-</question>
-<answer>
-<simpara>The Eclipse Foundation accepts any of the following formats for
-submitting a paper form:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Print, sign, and postal mail the form to the Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>Print, sign, and fax the form to the Eclipse Foundation; or</simpara>
-</listitem>
-<listitem>
-<simpara>Print, sign, scan, and email to the scan as an attachment to the Foundation</simpara>
-</listitem>
-</itemizedlist>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What Email address should I use to send scanned documents? </simpara>
-</question>
-<answer>
-<simpara>Email scans of the completed paperwork to EMO Records at <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What if a committer changes employers? </simpara>
-</question>
-<answer>
-<simpara>If you change employers, please contact <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="ip">
-<title>Intellectual Property</title>
-<simpara>LocationTech projects are expected to take necessary precautions to mitigate
-intellectual property (IP) risk to adopters. A company that integrates the code
-from your project, for example, does so with confidence that the code in the
-project can legally be distributed under the agreed-to terms. The
-<link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">IP Due Diligence Process</link>, managed by the Eclipse IP Team
-(commonly referred to as the <emphasis>IP Team</emphasis>), is in place to support this.</simpara>
-<simpara>All LocationTech committers must be familiar with the <link xlink:href="http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP
-Policy</link>.</simpara>
-<section xml:id="ip-initial-contribution">
-<title>Initial Contribution</title>
-<simpara>Code provenance tracking is critical (we need to know the source of all code
-that ends up in our repositories). To that end, all new projects are required to
-make an <emphasis>initial contribution</emphasis> before <emphasis role="strong">any</emphasis> code is committed to a project’s
-source code repository.</simpara>
-<simpara>The IP Team will review your initial contribution to ensure that the code can
-distributed through a LocationTech property. The IP Team will review the code to
-make sure that it hasn’t been copied inappropriately, that licenses are being
-used correctly, and so forth. As part of this process, the IP Team will
-research the source of all code; depending on the size of the contribution, this
-can be a time-consuming process.</simpara>
-<note>
-<simpara>A project cannot make a <link linkend="release">release</link> until the due diligence on
-the IP contained in that release—​including project code contributions and
-third-party libraries—​is complete.</simpara>
-</note>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit the initial contribution
-for review by the IP Team.</simpara>
-<simpara>The IP Team is not able to review the history of project code being moved to
-a LocationTech project. The IP Team will review a snapshot of the project code and
-that snapshot, the <emphasis>initial contribution</emphasis>, must be the first commit in the
-LocationTech repository. If your project uses an existing GitHub repository, the
-Webmaster team will help you obscure the the history into a hidden branch.</simpara>
-</section>
-<section xml:id="ip-project-code">
-<title>Project Code Contributions</title>
-<simpara>Some contributions of code to maintained by the project (i.e. committed to a
-project source code repository and maintained by the project team) must be
-reviewed by the IP Team. The <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">IP Due Diligence Process</link>
-provides help to determine whether or not the contribution needs to be reviewed
-by the IP Team. If you’re not sure, ask your project mentors or your PMC for
-assistance.</simpara>
-<simpara>All contributions of project code must be tracked in the project’s
-<link linkend="ip-iplog">IP Log</link>.</simpara>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit a project code
-contribution for review by the IP Team.</simpara>
-</section>
-<section xml:id="ip-third-party">
-<title>Third-Party Libraries</title>
-<simpara>All third-party libraries required by project code will have to be checked
-and approved by the IP Team.</simpara>
-<simpara>The IP Team must review a third-party library if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the Java/OSGi manifest for one of the project bundles makes a
-direct reference to a third-party library (either the library bundle
-or a package from the library);</simpara>
-</listitem>
-<listitem>
-<simpara>project code includes an import statement for a package from a
-third-party library;</simpara>
-</listitem>
-<listitem>
-<simpara>project code uses reflection or other means to reference a
-library’s APIs and implementation;</simpara>
-</listitem>
-<listitem>
-<simpara>project code uses OSGi Services to make a reference to a
-specific implementation of a service; or</simpara>
-</listitem>
-<listitem>
-<simpara>project code invokes a "command line" tool.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>This list is not intended to be exhaustive.</simpara>
-<simpara>The <link xlink:href="http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf">Guidelines for the Review of Third Party Dependencies</link> can help
-you determine how to classify your third-party libraries.</simpara>
-<note>
-<simpara>A project cannot make a <link linkend="release">release</link> until the due diligence on
-the IP contained in that release—​including project code contributions and
-third-party libraries—​is complete.</simpara>
-</note>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit a third-party
-library for review by the IP Team.</simpara>
-</section>
-<section xml:id="ip-ownership">
-<title>Ownership</title>
-<simpara>The author of a contribution (or their employer) retains ownership of the
-intellectual property contained in the contribution. As part of the contribution
-process, the contributor licenses their contribution under the project license.</simpara>
-</section>
-<section xml:id="ip-copyright-headers">
-<title>Copyright and License Headers</title>
-<simpara>All source files must include a file header that describes the copyright and
-license terms of the software.</simpara>
-<formalpara>
-<title>Example Copyright and License Header</title>
-<para>
-<screen>/*******************************************************************************
- * Copyright (c) 2015 Schmedly Inc. and others. <co xml:id="CO2-1"/>
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html <co xml:id="CO2-2"/>
- *
- * Contributors:
- * Wayne Beaton - initial API and implementation <co xml:id="CO2-3"/>
- *******************************************************************************/</screen>
-</para>
-</formalpara>
-<calloutlist>
-<callout arearefs="CO2-1">
-<para>Name the initial copyright owner; this must be a legal entity (e.g. a company or individual).
-If other organizations have contributed, include "and others".</para>
-</callout>
-<callout arearefs="CO2-2">
-<para>List project licenses.</para>
-</callout>
-<callout arearefs="CO2-3">
-<para>Optionally list the names of the contributors and the nature of their contribution.</para>
-</callout>
-</calloutlist>
-<simpara>Your project is not a legal entity and so it is inappropriate to list it as
-the copyright owner.</simpara>
-<warning>
-<simpara>The copyright owner is either an individual or their employer. Most
-employment contracts stipulate that the intellectual property creations of an
-employee are the property of the employer and so the employer should generally
-be listed as the copyright owner.</simpara>
-</warning>
-<simpara>For more information please see the <link xlink:href="https://www.eclipse.org/legal/copyrightandlicensenotice.php">Default Eclipse Foundation Copyright and License Notice</link>.</simpara>
-</section>
-<section xml:id="ip-licensing">
-<title>Licensing</title>
-<simpara>LocationTech top level projects define the standard licensing for their
-projectsd. If your project has non standard licensing requirements,
-you may need to make a presentation to the Eclipse board of directors
-to request their approval. The presentation need only briefly describe
-the project and why special licensing considerations are necessary.</simpara>
-</section>
-<section xml:id="ip-cq">
-<title>Contribution Questionnaires</title>
-<simpara>A Contribution Questionnaires (CQ) is the main interface
-between LocationTech committers and the IP Team.</simpara>
-<simpara>A CQ is started when a committer completes a <emphasis>questionnaire</emphasis> regarding
-a contribution or third-party library. In literal terms, a CQ is a
-record in a modified instance of Bugzilla, named <emphasis>IPZilla</emphasis>,
-that tracks the progress of the approval process. The CQ record is the
-primary communication channel between the submitting committer and the
-IP Team. CQ records persist indefinitely.</simpara>
-<note>
-<simpara>You can review existing CQs via <link xlink:href="https://dev.eclipse.org/ipzilla">IPZilla</link>. Note that
-IPZilla is accessible only by committers, Eclipse Foundation member company
-represenatives, and other specifically-designated individuals.</simpara>
-</note>
-<simpara>All significant contributions of code to be maintained by a LocationTech project, as
-defined by the Eclipse IP Due Diligence Process require a CQ.</simpara>
-<simpara>Projects require a CQ for every third-party library that project
-code makes direct use of (regardless of whether or not the library
-is directly distributed by the project. If your code makes indirect
-use of a third party library through another LocationTech
-project’s code, you do not require a CQ for that library.</simpara>
-<note>
-<simpara>CQs for third-party libraries are <emphasis>version-specific</emphasis>. That is,
-a separate CQ is required for different versions of the same library.</simpara>
-</note>
-<simpara>CQs are not generally required for ongoing work done by project
-committers. Consult the IP Due Diligence Process document for
-more information.</simpara>
-<section xml:id="ip-parallel-ip">
-<title>Parallel IP</title>
-<simpara>The <emphasis>Parallel IP Process</emphasis> allows LocationTech projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team. In practical terms, the Parallel
-IP Process permits—​with preliminary approval from the IP Team—​a
-project to check-in code contributions into their source code
-repository and run builds against third-party libraries
-without having to wait for the full IP Due Diligence Process to
-compete.</simpara>
-<note>
-<simpara>There is some risk associated with the Parallel IP Process.
-The IP Team will grant preliminary approval based on a cursory
-review of the contribution; but during their full review, they may
-uncover issues that require mitigation. This may require, for
-example, that some parts of a contribution be removed completely
-(history and all) from a source code repository.</simpara>
-</note>
-<simpara>Parallel IP manifests in two different ways: projects in the
-<emphasis>incubation phase</emphasis> may leverage the Parallel IP process for
-project code and third-party libraries. <emphasis>Mature phase</emphasis> projects
-may leverage parallel IP for new versions of third-party libraries
-for which previous versions have already been approved.</simpara>
-<simpara>To leverage the Parallel IP Process, projects still submit CQ.
-The difference is that once a CQ has been reviewed for
-license compatibility, the project will be authorized via IPzilla
-to check-in the code start working on it.</simpara>
-<simpara>All IP must be fully approved before it is included in a release.</simpara>
-</section>
-<section xml:id="ip-piggyback">
-<title>Piggyback CQs</title>
-<simpara>Many third party libraries have already been approved for use in LocationTech projects.
-Many of those are immediately available via the <link xlink:href="http://www.eclipse.org/orbit">Orbit Project</link>.
-While these libraries have already been cleared for use by all projects,
-their use must be tracked. Usage is tracked so that—​in the event that a issue is uncovered
-following the due diligence process—​we can mitigate the impact of that issue.</simpara>
-<simpara>In this case, a <emphasis>piggyback CQ</emphasis> can be created on top of an existing CQ. Piggyback CQs
-are generally approved very quickly as the due diligence work has already been completed.</simpara>
-</section>
-<section xml:id="ip-cq-workflow">
-<title>CQ Workflow</title>
-<simpara>The workflow for creating a CQ for a third-party library starts with a search of existing
-CQs. If an existing CQ can be found that is concerned with the same library and version,
-then a piggyback CQ is created. Piggyback CQs must be approved by the project’s Project
-Management Committee (PMC) before they are processed by the EMO IP Team.</simpara>
-<simpara>If an existing CQ cannot be found, a new one must be created. Once created, the source
-code for the third-party library must be attached to the record. The PMC must then approve
-the record. If the project is eligible to leverage the Parallel IP Process, the IP
-Team performs a cursory review of the record and—​if the CQ meets with the
-requirements—​tentatively approves the use of the library while the full review is
-undertaken in parallel.</simpara>
-<simpara>The IP team may require your assistance as it performs a deep analysis of the library.
-Once that analysis is complete and the IP team has made a decision, they will outline
-the next steps. These next steps may—​in the event that the library is rejected—​that
-the library be removed from the project VCS, or that some part be removed. Most often,
-the library is approved and the CQ is marked as such.</simpara>
-<simpara>Be advised that this process may take a while. The actual amount of time that it takes
-to process a CQ depends on numerous factors including the size of the queue, and the
-nature and size of the contribution.</simpara>
-</section>
-</section>
-<section xml:id="ip-iplog">
-<title>IP Logs</title>
-<simpara>An IP Log is a record of the intellectual property contributions to a project.
-This includes such as a list of all committers, past and present, that have
-worked on the code and (especially) those who have made contributions to
-the current code base.</simpara>
-<simpara>The IP Log is a big part of the official <link linkend="release">release cycle</link>. You are required to
-submit your project’s IP Log prior to scheduling a release, or restructuring
-review. We encourage you to keep your IP log current rather than rushing at the
-end. The IP Log includes important information about your project that lets
-adopters know where all the code comes from, who owns the copyrights, and so
-forth.</simpara>
-<simpara>Specifically, the log tracks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Licenses;</simpara>
-</listitem>
-<listitem>
-<simpara>Past and present committers;</simpara>
-</listitem>
-<listitem>
-<simpara>Third-party libraries; and</simpara>
-</listitem>
-<listitem>
-<simpara>Contributions from outside the project (i.e. non-committers)</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="ip-iplog-generator">
-<title>IP Log Generator</title>
-<simpara>The Automated IP Log Tool automatically generates an IP Log using information
-that is available to the Eclipse Foundation. The list of committers, for
-example is generated using information provided by the Dash project which itself
-pulls information out of source code repositories.</simpara>
-<simpara>The IP Log generator pulls information from multiple location to assemble the log:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/ip-log-generator.png"/>
-</imageobject>
-<textobject><phrase>ip log generator</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<itemizedlist>
-<listitem>
-<simpara>Third-party libraries used by the project come from <emphasis>IPZilla</emphasis>;</simpara>
-</listitem>
-<listitem>
-<simpara>The <emphasis>Dash</emphasis> process scans the project source code repositories to assess committer activity;</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Dash</emphasis> also scans Git repositories for contributions;</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If you follow the guidelines for handling Git contributions, contributions received via
-Git in any branch will automatically appear in the log</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Contributions received as patches in <emphasis>Bugzilla</emphasis> that are marked <literal>iplog+</literal>
-will automatically appear in the log; and</simpara>
-</listitem>
-<listitem>
-<simpara>License information is obtained from the <emphasis>Foundation</emphasis> database</simpara>
-</listitem>
-</itemizedlist>
-<simpara>To fully leverage the value of the Automated IP Log Tool, you need to:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Keep your project metadata up-to-date;</simpara>
-</listitem>
-<listitem>
-<simpara>Follow the guidelines for handling Git contributions;</simpara>
-</listitem>
-<listitem>
-<simpara>Mark IP Contributions in Bugzilla; and</simpara>
-</listitem>
-<listitem>
-<simpara>Create <link linkend="ip-cq">contribution questionnaires</link> (CQs) where appropriate</simpara>
-</listitem>
-</itemizedlist>
-<warning>
-<simpara>Contributions should be recorded in <emphasis>one of</emphasis> Git or Bugzilla, not both.
-Setting the <emphasis>Author</emphasis> credentials on Git commits is the preferred mechanism.
-The IP Log generator is not smart enough to detect duplicate entries.</simpara>
-</warning>
-<simpara>Your project’s metadata is used to determine the identities of the source code
-repositories that Dash needs to scan to find out committer information. Specifically,
-you need to specify, in the <emphasis>Source Repositories</emphasis> section, a list of paths to source code
-repository locations.</simpara>
-<simpara>The Automated IP Log tool populates the <emphasis>Contributors</emphasis> section with information gathered
-from Git and Bugzilla. This section lists contributions from non-committers (this is
-time-sensitive, so contributions made by current committers before they became
-committers will also be included). Only non-committer contributions are recorded in
-the generated log.</simpara>
-<simpara><link linkend="resources-commit">Git commits</link> contributed by non-committers are identified by
-the author credentials on the commit record; the <emphasis>Author</emphasis> field must be set to the identity
-of the actual author of the commit.</simpara>
-<simpara>Alternatively, Bugzilla attachments can be marked with the <literal>iplog+</literal> flag.
-This flag setting indicates that the person who attached the bug is the contributor.
-To comply with the website terms of use, the person who attaches
-the contribution <emphasis role="strong">must</emphasis> be the person who has permission to make it available.
-You should ensure that this is the case before including the code in your project’s
-repository and flagging the entry.</simpara>
-<simpara>You can also flag an entire Bugzilla entry with <literal>iplog+</literal>. Doing so,
-however, indicates to the Automated IP Log tool that every single comment made by a non-committer
-in the bug report represents a potential contribution. For your own sanity, it’s a good practice
-to ask contributors to provide and attach patches that can be individually marked. Marking an
-entire bug represents an ongoing maintenance issue as new comments added to the bug from
-non-committers will show up in the generated log.</simpara>
-<simpara>That contributions flagged in Bugzilla will only appear in the IP Log if the bug is marked
-<literal>FIXED</literal> or <literal>CLOSED</literal>.</simpara>
-<simpara>The Third-Party Software section of the log is populated from IPZilla. The IP Team
-will mark your contributions in such a way that they will appear in
-the log. If third party software is not appearing properly, contact the
-<link xlink:href="mailto:emo-ip-team@eclipse.org">EMO IP Team</link> to make corrections.</simpara>
-</section>
-</section>
-<section xml:id="ip-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What do you do with the IP Log? </simpara>
-</question>
-<answer>
-<simpara>IP Log reviews occur in two stages. In the first stage, the EMO performs
-a technical assessment to make sure that the artifacts produced by the
-project are properly accounted for in the IP log. You may be asked to
-assist with the resolution of any discrepancies found during this assessment.
-In the second stage, the IP Team reviews the log to ensure that
-it matches their records. The IP log review concludes with approval by the IP Team.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>When should I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>The IP Log should be submitted for review by the IP Team two weeks before the planned
-end date for a release review or (if code moves are involved) a restructuring review.
-Note that the date of your review may be different from the date of the actual release.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Are there other reasons to submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>Generally no. If the IP Team requires an IP Log review outside of the context of
-a release or restructuring review, they’ll ask for it. It is not generally necessary
-to submit an IP Log for review outside of the context of a review.
-It is, however, good practice to do your own review of the generated
-IP Log periodically to make sure that it accurately reflects the state of the project.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I fix problems with the generated IP Log? </simpara>
-</question>
-<answer>
-<simpara>The IP Log is generated based on data from Eclipse Foundation servers. If the log
-is being generated incorrectly, then the underlying data needs to be fixed. If
-you spot a problem, send a note to <link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="release">
-<title>Releases</title>
-<simpara>Releases are formal for LocationTech projects. They start with planning,
-and end with a community review. You can capture as many future releases as you’d like. It’s
-common practice to specify releases three or six months into the future.</simpara>
-<simpara>Releases are broadly categorized as:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>Major</emphasis> releases include API changes (potential for downstream breakage);</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Minor</emphasis> releases add new functionality, but are API compatible with previous versions; and</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Service</emphasis> releases include bug fixes only and include no significant new functionality.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For all major and minor releases, you must engage in a <emphasis>release review</emphasis>.
-Release reviews are not required for bug-fix/service releases.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/release-cycle.png"/>
-</imageobject>
-<textobject><phrase>The release cycle</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara xml:id="releases-plan">A project plan is <emphasis>required</emphasis> for each major and minor project release.
-The plan should lay out in broad terms what the goals are for the
-release. As plans are a valuable means
-for the community to get involved with your project, the plan should be
-created at the beginning of the release cycle. By establishing the plan
-early, you give prospective contributors help in determining how they
-can most usefully contribute, and adopters can prepare their own
-development schedule and themes. Plans can change during the release
-cycle.</simpara>
-<simpara>Use the <link linkend="pmi">Project Management Interface</link> to create a new release
-record. At the start of the release cycle, your plan should minimally
-include a release number, date, and short description. Think of the
-description as an "elevator pitch": how would you describe the release
-in a fifteen second elevator ride? All aspects of a plan can change
-during the release cycle (including the date). If you do change the plan,
-make sure that the change is communicated via your project’s <emphasis>dev</emphasis> list
-and other project channels.</simpara>
-<simpara>The <emphasis>Plan</emphasis> tab in the release record contains numerous fields for capturing
-plan information. The amount of information that you should capture
-for a release plan varies by top-level project, so consult with your
-Project Management Committee (PMC) for advice.</simpara>
-<simpara>Producing regular builds is an important part of the release cycle.
-Builds are an important means of engaging with the community: adopters can
-help you test your code and test their own so that they can be ready for
-the eventual release. Plan to produce at least one <emphasis>milestone</emphasis> build (more
-are better, depending on the length of your release cycle), and capture
-the planned date for that milestone in the release record. It is also
-common practice to generate nightly and weekly integration builds. Ensure that
-your project’s downloads page provides the information required for the
-community to obtain your builds.</simpara>
-<simpara>All of your project’s <link linkend="ip">intellectual property</link> contributions
-must be approved by the IP Team before you can release
-(this includes third-party libraries and contributions of code to be
-maintained by the project).</simpara>
-<section xml:id="release-review">
-<title>Release Review</title>
-<simpara>A <emphasis>release review</emphasis> is a formal announcement of your release to the
-community and a request for feedback. In practical terms, experience
-has shown that those individuals and organizations who are interested
-in your project follow development throughout the release cycle and so
-are have likely already provided feedback during the development
-cycle (i.e. they are unlikely to provide feedback during the review
-period). With this in mind, the review generally serves as a means for
-a project to engage in a retrospective of the progress made during the
-release, discover areas of potential improvement, demonstrate that the
-project is operating in an open and transparent manner, and ensure that
-the development process and intellectual due diligence processes have
-been followed.</simpara>
-<simpara>Release reviews run for a week and always conclude on a Wednesday.</simpara>
-<note>
-<simpara>We schedule reviews to conclude on the <emphasis>first and
-third Wednesdays of the month</emphasis>. Your release date does not have to
-coincide with the review date (you can set the release date as
-necessary). The review must, however, conclude successfully before you
-can make the release official.</simpara>
-</note>
-<simpara>A <emphasis>release review</emphasis> requires review documentation and an intellectual
-property (IP) log check. The review process must be initiated at least
-two weeks in advance of the anticipated <emphasis>review</emphasis> date.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/release-review.png"/>
-</imageobject>
-<textobject><phrase>Release review work flow</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Prepare the review documentation well in advance of the start of the
-review period. The release record which contains your project plan
-also includes a <emphasis>Review</emphasis> tab with appropriate fields for a review.
-As with the plan fields, all of the review fields are optional and
-the level of detail you need to provide varies by top-level project.
-You can assemble review information during the release cycle (there’s
-no need to wait until the end)</simpara>
-<simpara>The review materials must be approved by the PMC; send an email to
-the PMC’s mailing list asking for approval. The PMC will respond with
-feedback or a simple "+1" indicating approval.</simpara>
-<note>
-<simpara>Click the handy <emphasis>Send Email to the PMC</emphasis> link under <emphasis>Committer Tools</emphasis>
-on the release record page to connect with the PMC.</simpara>
-</note>
-<simpara>Submit the IP Log for review by the IP Team. The IP Team must approve
-the IP Log before we can schedule the review, so submitting this early
-is important. The <link linkend="ip-iplog-generator">IP Log generator</link> automatically
-collects information based on the information that the project team has
-provided to the IP Team through <link linkend="ip-cq">contribution questionnaires</link>
-in IPZilla, commits in the project’s source code repository, and
-other information in our databases. Carefully review the IP Log before
-submitting to the IP Team for their review.</simpara>
-<note>
-<simpara>Click the handy <emphasis>Generate IP Log</emphasis> link under <emphasis>Committer Tools</emphasis>
-on the release record page to open the IP Log generator.</simpara>
-</note>
-<simpara>The information used to generate an IP Log should always be up-to-date
-(don’t wait until the end of the release cycle to make it right).</simpara>
-<simpara>At any point in this process, you can request that the review be
-initiated by clicking the <emphasis>Schedule a review for this release</emphasis> link
-that appears at the top of the release record page. This will invite you
-to select a review date. You must then follow up with the EMO to approve
-the review.</simpara>
-<note>
-<simpara>The EMO will likely notice that you’ve created the release record,
-connected with your PMC, and submitted an IP Log for review by the IP
-team and will take steps to initiate the actual review. However, since
-there is a great deal of variability in this process, send an email to
-<link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link> stating your intent to release.</simpara>
-</note>
-<simpara>The EMO will conclude the review on the scheduled end date and advise the
-project team of the outcome.</simpara>
-</section>
-<section xml:id="release-graduation">
-<title>Graduation Review</title>
-<simpara>The purpose of a <emphasis>graduation review</emphasis> is to confirm that the project has
-a working and demonstrable code base of sufficiently high quality
-active and sufficiently diverse communities; has adopters, developers, and users
-operating fully in the open following the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>; and
-is a credit to LocationTech and is functioning well within the larger LocationTech community</simpara>
-<simpara>Graduation reviews are generally combined with a <link linkend="release-review"><emphasis>release review</emphasis></link>
-(typically, but not necessarily the <emphasis>1.0</emphasis> release).
-Upon successful completion of a graduation review, a project will leave the
-incubation phase and be designated as a <emphasis>mature</emphasis> project.</simpara>
-<simpara>For a graduation review, release review documentation must be augmented to
-include demonstration of:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>solid working code with stable APIs;</simpara>
-</listitem>
-<listitem>
-<simpara>an established and growing community around the project;</simpara>
-</listitem>
-<listitem>
-<simpara>diverse multi-organization committer/contributor/developer activity; and</simpara>
-</listitem>
-<listitem>
-<simpara>operation in the open using open source rules of engagement.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The graduation review documentation should demonstrate that members have
-learned the ropes and logistics of being a LocationTech project. That is,
-the project "gets the LocationTech way".</simpara>
-</section>
-<section xml:id="release-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Can a release review fail? </simpara>
-</question>
-<answer>
-<simpara>Technically, yes. A release review can fail. In our history, however, this
-occurrs very rarely. We set up release reviews to succeed.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How often should we do releases? </simpara>
-</question>
-<answer>
-<simpara>This depends very much on the nature of your project and the expectations
-of your community and stake holders. If you’re not sure, connect with your
-mentors and top-level project for guidance.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How much effort should we put into this? </simpara>
-</question>
-<answer>
-<simpara>The amount of effort varies based on the nature of the team, and
-expectations of the community and stake holders. Generally, though, a project
-team shouldn’t spend more than a couple of hours working directly on the
-formal aspects of the release review.
-If the amount of effort seems too onerous, you may be trying too hard.
-Connect with your project mentors, top-level project’s PMC, or the
-<link xlink:href="mailto:emo@eclipse.org">EMO</link> for guidance.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>Click the <emphasis>Submit</emphasis> button on the <link linkend="ip-iplog-generator">IP Log generator</link>.
-You need to be logged in as project committer to have access to this button.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I accept contributions after I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>The short answer is <emphasis>yes</emphasis>. Please do accept contributions.
-If you require a new contribution questionnaire (for either a third
-party library or code contribution) after submitting the IP Log for
-review, please ask the <link xlink:href="mailto:emo-ip-team@eclipse.org">IP Team</link> if
-they want you to resubmit the IP Log.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I obtain PMC approval? </simpara>
-</question>
-<answer>
-<simpara>Send the the PMC a note via the top-level project’s <emphasis>PMC</emphasis> mailing list
-with a link to the release record. Note that the release record page
-has a handy link labeled <emphasis>Send Email the PMC</emphasis> under <emphasis>Committer Tools</emphasis>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>I need to do a release now. Can you fast-track the review? </simpara>
-</question>
-<answer>
-<simpara>While we do try to be as accommodating as possible, the answer is no.
-We have a well-defined process with predictable dates. Please plan
-accordingly.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can a project in the incubation phase do releases? </simpara>
-</question>
-<answer>
-<simpara>Yes. In fact, we encourage projects to do at least one release while
-in incubation phase.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What restrictions are placed on version names for incubating projects? </simpara>
-</question>
-<answer>
-<simpara>Projects in the incubation phase generally use version numbers that
-are less than 1.0. This is, however, a convention not a rule. If it makes sense
-for you community and adopters to use higher numbers, then do so.
-If you’re not sure, ask your top-level project PMC for advice.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I name/number milestone builds? </simpara>
-</question>
-<answer>
-<simpara>Milestone builds should contain the name/number of the release suffixed
-with "Mn" (e.g. the second milestone for EGit 3.2 may have a file
-named "egit-3.2M2"). Projects in the incubation phase may produce
-milestone builds for their graduation release, e.g "myProject-1.0M2".</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How can I get help? </simpara>
-</question>
-<answer>
-<simpara>Contact your mentors (for projects in the incubation phase), top-level
-project PMC, or the <link xlink:href="mailto:emo@eclipse.org">EMO</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="pmi">
-<title>Project Management Infrastructure (PMI)</title>
-<simpara>The LocationTech Project Management Infrastructure (PMI) consolidates
-project management activities into a single consistent location and experience.</simpara>
-<simpara>Project Management Infrastructure themes:</simpara>
-<simpara><emphasis>Improved consistency.</emphasis> Configuration/data-driven project web presence,
-direct linkage between releases, reviews, and plans. Information—​including
-basic project metadata, project plans, and release review information—​is
-captured and retained in a consistent (and easily leveraged) data-based
-format (rather than in multiple documents in arbitrary formats).</simpara>
-<simpara><emphasis>All-in-one-place.</emphasis> Project leads and committers are able to edit
-information in place on the project information pages. Text/information in
-one place with links in another is eliminated where possible. Comments and
-discussion related to reviews, elections, etc. are connected directly
-to the item being discussed.</simpara>
-<simpara><emphasis>Get started faster.</emphasis> By default, projects are provided with a data-driven
-website that includes consistent links to project releases, reviews,
-downloads, etc. Projects can opt to override the default and provide
-their own customized web presence. Setting up a project presence is a
-matter of configuration, not PHP programming against proprietary APIs.</simpara>
-<section xml:id="pmi-metadata">
-<title>Project Metadata?</title>
-<simpara>Project committers and project leads are responsible for maintaining
-their project’s metadata. This information is an important part of being
-an Eclipse project.</simpara>
-<simpara>Project metadata is:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Relatively static structural information such as the project
-description and scope, the names of the project’s mailing lists and
-newsgroups, the bugzilla products, source code repositories, etc.</simpara>
-</listitem>
-<listitem>
-<simpara>Historical information such as previous release downloads, release
-review slides and IP logs, etc.</simpara>
-</listitem>
-<listitem>
-<simpara>Status and future looking information such as the project and
-milestone plans, the features scheduled for the current release, release
-dates, etc.</simpara>
-</listitem>
-</orderedlist>
-<simpara>PMC members, and the Eclipse Foundation staff also have the ability to
-make changes on behalf of a project.</simpara>
-</section>
-<section xml:id="pmi-viewing">
-<title>Viewing</title>
-<simpara>The complete listing of all current
-<link xlink:href="http://www.locationtech.org/list-of-projects">LocationTech projects</link> provides
-one starting point for viewing projects. From here, you can link
-directly to a project information page. Navigation options are provided
-to help you move from one project to another.</simpara>
-</section>
-<section xml:id="pmi-commands-and-tools">
-<title>Commands and Tools</title>
-<simpara>Committers have access to several committer-specific
-commands and tools. The selection of commands available are context sensitive; only those
-commands that make sense for the logged in user are shown.</simpara>
-</section>
-<section xml:id="pmi-editing">
-<title>Editing Project Metadata</title>
-<simpara>Committers have the ability to edit the information managed and displayed
-on the project page.
-There are several sections on the page. When you switch the page into
-"Edit" mode, you will be provided with lots of help regarding the
-contents of each of the fields (note that the help text is currently
-rendered below the fields).</simpara>
-<simpara>Some of the fields are described below.</simpara>
-<section xml:id="pmi-description-and-scope">
-<title>Description and Scope</title>
-<simpara>The <emphasis>description</emphasis> should start with a concise paragraph of three to five
-sentences (e.g. suitable for display with a collection of other projects).
-A single paragraph is generally appropriate for the
-description.</simpara>
-<simpara>If more than a single simple paragraph is required to fully
-describe the project, it is possible to set a summary. The summary
-can be specified by toggling the "show summary" link to explicitly
-set a summary apart from the more detailed description, or the top
-part of the description can be designated as the summary by inserting
-a <emphasis>Teaser Break</emphasis> into the content.</simpara>
-<note>
-<simpara>providing a summary gives you control over what will get rendered.
-In views where we are displaying more than one project, the system
-will artifically cut short descriptions that are too long, potentially
-resulting in a description that looks <emphasis>weird</emphasis>.</simpara>
-</note>
-<simpara>The <emphasis>scope</emphasis> is intended for a more select audience; generally speaking the
-scope should be taken directly from the project’s proposal. Project
-members have the ability to change the text of the project scope, but
-should be careful to avoid changing the meaning. If the meaning of the
-scope needs to change, the Project Management Committee (PMC) must be
-contacted regarding a potential restructuring review.</simpara>
-</section>
-<section xml:id="pmi-downloads">
-<title>Downloads</title>
-<simpara>You can provide download information for your project in the "Downloads"
-section.</simpara>
-<simpara>The first entry is the main "Downloads URL". This manifests as a "Big
-Button" Download on the project page. What you put here is left to the
-project team to decide. It can be a link to a webpage, a direct link to
-a file download, or whatever else makes sense the project and community.</simpara>
-<simpara>Optional text can be included along with the "Big
-Button" Download, as well as links to zero or more Eclipse Marketplace,
-update/p2 sites, or other downloads. Each of the links can have an
-optional title (the link itself will be displayed if no title is
-provided). Note that no validation is done on the links to ensure that
-they are meaningful.</simpara>
-</section>
-<section xml:id="source-repositories">
-<title>Source Repositories</title>
-<simpara>The project can specify zero or more <emphasis role="strong">source repositories</emphasis>. These are
-displayed in the "Contribute to this Project" section.</simpara>
-<simpara>The values specified are used to query against a database of known
-existing source repositories (this database is updated nightly by a
-discovery process). Those repositories that are found in the database
-will be displayed with enhanced information (including links to
-repository mirrors, Gerrit, etc.). All values that you provide will be
-displayed, whether they point to real repositories or not. If the
-database does not contain your repository, the PMI will assume that the
-value is correct and try its best to display the information.</simpara>
-<simpara>Repositories should be specified using the file system path, e.g.
-<emphasis>/gitroot/egit/egit.git</emphasis>. The name that is displayed for the repository
-is extracted from the last segment of the URL.</simpara>
-<simpara>If a description file exists in the Git repository, the contents are
-automatically displayed under the repository name.</simpara>
-<note>
-<simpara>The script that we us to identify repositories attempts to identify a
-corresponding Gerrit interface for the repository. If it exists, the
-Gerrit URL is used in place of the Git one. If the repository uses
-Gerrit, then only the Gerrit URL is displayed. Otherwise, the "git://"
-and "ssh://" URLs are displayed.</simpara>
-</note>
-<simpara>You can use wildcards to match multiple repositories, e.g.
-<emphasis>/gitroot/virgo/*</emphasis>. Note that wildcards only work for repositories that
-exist on LocationTech infrastructure (they do not work for GitHub-based
-repositories, for example).</simpara>
-<simpara>Repositories are displayed in the order they are specified. The order
-can be changed in the edit screen by dragging entries into the desired
-order. All wildcard matches are sorted alphabetically by name at the end
-of the list.</simpara>
-<simpara>A <emphasis role="strong">Contribution Message</emphasis> should be provided; it is displayed at
-the top of the section and is one of the primary means by which the
-community will find the project code. Arbitrary text is permitted, but we recommend
-that you limit this content to a single paragraph with a few sentences
-that include a link to more information.</simpara>
-</section>
-<section xml:id="pmi-company-logos">
-<title>Company Logos</title>
-<simpara>Company logos sometimes appear on project pages under the following
-conditions"</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The company must be a <link xlink:href="http://eclipse.org/membership/">member</link> of the
-Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>The company needs to have their logo uploaded to the Portal;</simpara>
-</listitem>
-<listitem>
-<simpara>At least one committer has to be listed as an employee of the company
-in question;</simpara>
-</listitem>
-<listitem>
-<simpara>The committer must be on this project; and</simpara>
-</listitem>
-<listitem>
-<simpara>The committer must be active (must have made at least one commit in
-the last three months)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If all of those conditions are met and the logo is still not showing up,
-then it’s possible that the project meta-data doesn’t have the correct
-source code repository information specified.</simpara>
-</section>
-<section xml:id="pmi-build-technology">
-<title>Build Technology</title>
-<simpara>A project can specify a section of text, links, and a selection of the
-build technologies employed. Specifying this information makes it easier
-for members from the community to understand your build. Links can
-include direct links into the Hudson builds, pages of build
-instructions, or whatever else the project team feels will help the community build
-the project.</simpara>
-</section>
-<section xml:id="pmi-technology-types">
-<title>Technology Types</title>
-<simpara>A project can specify the types of technology produced by the project.
-This is specified in rather broad terms like "OSGi" or "Runtime". The
-various technology types manifest as checkboxes on the edit screen. This
-information is used to form connections between projects to assist in
-navigation and discovery.</simpara>
-<simpara>Clicking on one of the technology types, will take the user
-to a page that lists the projects that produce that particular type of
-technology, along with the summary of their description and project logo
-(if specified).</simpara>
-</section>
-</section>
-<section xml:id="pmi-releases">
-<title>Releases and Reviews</title>
-<simpara>Projects, Releases, and Reviews are presented as separate records. Each
-project record, obviously, represents information about a project. A
-project may have multiple releases; information about the release is
-represented in a release record. The release record also contains some
-review information. This information is included here, because all
-releases do not necessarily have a review (a project can opt to provide
-some <emphasis>review</emphasis> type information as part of a release record. A project
-can have multiple review records; as release reviews are the most common
-form of review, most review records will be joined to a release record.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/ProjectsReleasesReviews.png"/>
-</imageobject>
-<textobject><phrase>Releases and Reviews</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>A review record, however, does not require a release association. Some
-reviews are associated with proposals. Other have no other association
-(e.g. termination reviews).</simpara>
-<simpara>Each <link linkend="release">release</link> has its own record in the database. Records are connected
-directly to a single specific project; a subset of release records
-associated with a project are displayed on the project page. An existing
-release can be edited in much the same was as a project. Any logged in
-project member (committer or project lead) can click the "Edit" button.</simpara>
-<note>
-<simpara>_Create a single record for each release. <emphasis role="strong">Do not create release records
-for milestones.</emphasis> Enter milestone information in the <emphasis>Plan</emphasis> information
-for your release.</simpara>
-</note>
-<simpara>A project lead or committer can create a new release by clicking "Create a new release" under
-"Committer Commands" on the project page. This opens a dialog requesting
-that a date and name be specified. Both of these values can be changed later.</simpara>
-<section xml:id="pmi-release-description">
-<title>Description</title>
-<simpara>Describe the release in the <emphasis>Description</emphasis> section. The description
-should generally be a concise paragraph describing the focus of the
-release (e.g. adding certain functionality, fixing bugs, etc.) in a form
-that is appropriate in an aggregation (e.g. a page that displays the
-release information for all projects participating in an instance of the
-Simultaneous release). The description should provide enough information
-to encourage the reader to click the "find out more" link.</simpara>
-</section>
-<section xml:id="pmi-release-issues">
-<title>Issues</title>
-<simpara>The release record will automatically generate a list of targeted bugs.</simpara>
-<simpara>To populate this list:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Ensure that the Bugzilla Product is set the to correct value in the
-project metadata;</simpara>
-</listitem>
-<listitem>
-<simpara>Set the "target milestones" in Bugzilla need to match the name of your
-release.</simpara>
-</listitem>
-</itemizedlist>
-<note>
-<simpara>The matching algorithm tries to be as forgiving as possible, a release
- named "3.5", "3.5.0", or "3.5 (Luna)" will—​for example—​match target
- milestones named "3.5" ,"3.5M1", "3.5 M2", "3.5.0M3", etc., but will
- not match "3.5.1".</simpara>
-</note>
-<simpara>The bugs for all projects participating in the release will be included.
-Bugs are grouped by Bugzilla product and component.</simpara>
-</section>
-<section xml:id="pmi-release-plan">
-<title>Plan</title>
-<simpara><link linkend="releases-plan">Project plan</link> information belongs in the <emphasis>Plan</emphasis> section. This
-information <emphasis role="strong">should</emphasis> generally be provided early in the development
-cycle to allow the various communities the ability to understand and
-participate in the release. It is expected that the plan will evolve
-over time. Note that all projects are required to provide a plan for
-each major and minor release (plans are not required service releases).</simpara>
-</section>
-<section xml:id="pmi-release-milestones">
-<title>Milestones</title>
-<simpara>Enter the name, date, and optional description for each milestone
-expected with the release.</simpara>
-<simpara>Projects should generally include more than one milestone build with each
-release. To include additional milestones, click the "Add another item"
-button. Note that milestones can be dragged into the desired order. To
-remove a milestone, leave the "Name" field blank.</simpara>
-</section>
-<section xml:id="pmi-review">
-<title>Review</title>
-<simpara>The release has a <link linkend="release-review"><emphasis>Review</emphasis></link> section that can be used to provide
-information for the associated review. If you provide information here,
-the release record itself can be used as review documentation; no
-further documentation is required.</simpara>
-<simpara>Each section on the review page includes a little help to describe the
-sort of information that you should provide.</simpara>
-<simpara>All major and minor releases require a review. Service releases (i.e.
-bug fix releases that do not change public APIs or add new
-functionality) do not require a review.</simpara>
-<simpara>If a release requires a review, you can schedule one by clicking the
-"Schedule a review" button. The drop-down list above the button contains
-several options for review dates. Pick the one that works best for you.</simpara>
-<simpara>Note that this form will not appear if a review has already been
-scheduled, or the release date does not provide enough time to run a
-review (or is in the past). If a review has been scheduled, a link to
-the review will appear.</simpara>
-<simpara>You can edit the review document, but there’s really not all that much
-to edit. A free-form text field is available and can be used if there is
-some need to provide review-specific information that might not
-otherwise be an appropriate part of the release record. <emphasis>This field is
-intended for other types of review (e.g. restructuring or termination
-reviews); we decided to leave it available for release reviews for cases
-in which it might be useful rather than suppress it.</emphasis></simpara>
-<simpara>When the review is displayed, it automatically includes the <emphasis>review</emphasis>
-information from the release record; it shows the review-specific
-information at the top of the page, and includes the <emphasis>review</emphasis>
-information from the release as the rest of the page contents.</simpara>
-<simpara>This can make things a bit confusing when you want to make changes to
-the metadata for a review record. Just remember that the <emphasis>review</emphasis>
-information for a release is stored in the release record.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="glossary">
-<title>Glossary</title>
-<glossentry>
-<glossterm>Architecture Council </glossterm>
-<glossdef>
-<simpara>The Eclipse Architecture Council (AC) serves the community by identifying and
-tackling any issues that hinder Eclipse’s continued technological success and
-innovation, widespread adoption, and future growth. This involves technical
-architecture as well as open source processes and social aspects. Comprising
-the finest technical leaders from all community stake holders, it is the council’s
-goal to keep the projects successful and healthy, the processes simple and smooth,
-and the communities vibrant and cohesive.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Architecture Council Mentor </glossterm>
-<glossdef>
-<simpara>The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers.
-All new projects are required to have a minimum of two mentors taken from the ranks
-of the AC. Your project mentors will help you find answers to any questions you may
-have about the Eclipse Development Process and life-in-general within the Eclipse
-community. If your mentor doesn’t have an answer to your question, they can draw
-on the wisdom of the full AC and the EMO.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Board of Directors </glossterm>
-<glossdef>
-<simpara>The business and technical affairs of the Eclipse
-Foundation are managed by or under the direction of the Board of Directors
-(or more simply, "The Board").</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Committer </glossterm>
-<glossdef>
-<simpara>A committer is a software developer who has the necessary rights to write code
-into the project’s source code repository. Committers are responsible for ensuring
-that all code that gets written into the project’s source code repository is of
-sufficient quality. Further, they must ensure that all code written to an
-LocationTech source code repository is clean from an intellectual property point
-of view. This is discussed with more detail below.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Community </glossterm>
-<glossdef>
-<simpara>Community is a nebulous sort of term. Community is the group of individuals and
-organizations that gather around your project. In the case of some projects, the community
-is enormous. Other projects have smaller communities. Developing a
-community is a very important part of being a LocationTech project as it is from the
-community that you get feedback, contributions, fresh ideas, and ultimately new
-committers to help you implement your shared vision.
-The <emphasis>LocationTech Community</emphasis> is formed from the union of the communities that grow
-around individual projects.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Contribution Questionnaire </glossterm>
-<glossdef>
-<simpara>Prior to committing a significant contribution of content from a non-committer
-to a LocationTech project, the committer must fill out a <link linkend="ip-cq">contribution questionnaire</link> (CQ) and
-submit it to the IP Team for approval. In addition to the
-EMO, the relevant PMC must also provide a technical review and approval of the contribution.
-In general, ongoing development by project committers does not require EMO or PMC approval.
-When in doubt, consult the <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">Eclipse IP Due Diligence Process</link>.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Contributor </glossterm>
-<glossdef>
-<simpara>A contributor is anybody who makes contributions to the project. Contributions
-generally take the form of code patches, but may take other forms like comments
-on issues, additions to the documentation, answers to questions in forums, and
-more.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Dash Process </glossterm>
-<glossdef>
-<simpara>The Dash Process, or simply <emphasis>Dash</emphasis>, is a collection of scripts and processes that
-harvest project data for dissemination in charts, <link linkend="ip-iplog">IP Logs</link>, and more.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Dev-list </glossterm>
-<glossdef>
-<simpara>Every project has a <emphasis>development list</emphasis> or <emphasis>dev-list</emphasis>. All project
-committers must subscribe to the list. The dev-list should be the primary means
-of communication between project committers and is the means throuh which the
-Eclipse Foundation’s automated systems communicate with the project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Ecosystem </glossterm>
-<glossdef>
-<simpara>A commercial ecosystem is a system in which companies, organizations, and individuals
-all work together for mutual benefit. There already exists a vast ecosystem of companies
-that base significant parts of their business on LocationTech technology. This takes the
-form of including LocationTech code in products, providing support, and other services.
-You become part of an eco-system by filling the needs of commercial interests, being
-open and transparent, and being responsive to feedback.
-Ultimately, being part of a commercial ecosystem is a great way to ensure the
-longevity of your project: companies that build their business around your project
-are very motivated to contribute to your project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Eclipse </glossterm>
-<glossdef>
-<simpara>Now this is a tough one. For most people in the broader community, "Eclipse" refers to a
-Java IDE based on the JDT project and assembled by the Eclipse Packaging Project. However,
-the term "Eclipse" is also used to refer to the Eclipse Foundation, the eclipse.org website,
-the community, the eco-system, and—​of course—​The Eclipse Project (which is just one of
-the top-level projects hosted by the Eclipse Foundation). Confusing? Yes.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO </glossterm>
-<glossdef>
-<simpara>The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Architecture and Planning
-Councils. The EMO is responsible for providing services to the projects, facilitating
-project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse
-Development Process. The best method of contact with the EMO is by email (<link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link>).
-If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO Executive Director </glossterm>
-<glossdef>
-<simpara>The EMO Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. He is
-ultimately responsible for all the goings-on at the Eclipse Foundation.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO IP Team </glossterm>
-<glossdef>
-<simpara>The EMO Intellectual Property Team (commonly referred to
-as the <emphasis>IP Team</emphasis>) is responsible for implementing the intellectual
-property policy of the Eclipse Foundation.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO Records </glossterm>
-<glossdef>
-<simpara>The EMO Records Team (commonly referred to as <emphasis>EMO Records</emphasis>) is
-responsible for managing committer paperwork and other records
-on behalf of the Eclipse Foundation. Contact the EMO Records team via email
-(<link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>).</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Incubation Phase </glossterm>
-<glossdef>
-<simpara>The purpose of the incubation phase is to establish a fully-functioning open-source project.
-In this context, incubation is about developing the process, the community, and the technology.
-Incubation is a phase rather than a place: new projects may be incubated under any existing project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>IP Due Diligence Process </glossterm>
-<glossdef>
-<simpara>The <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">Intellectual Property Due Diligence Process</link> defines the process by which
-intellectual property is added to a project. All LocationTech committers must be familiar
-with this process.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>IP Log </glossterm>
-<glossdef>
-<simpara>An <link linkend="ip-iplog">IP Log</link> is a record of the intellectual property (IP) contributions to a project.
-This includes such as a list of all committers, past and present, that have worked on the
-code and (especially) those who have made contributions to the current code base.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Member Company </glossterm>
-<glossdef>
-<simpara>The Eclipse Foundation and Eclipse community is supported by our member organizations.
-Through this support, the Eclipse Foundation provides the open source community
-with IT, Intellectual Property, Mentors and Marketing services.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Parallel IP </glossterm>
-<glossdef>
-<simpara>The <link linkend="ip-parallel-ip">Parallel IP Process</link> allows a LocationTech projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Planning Council </glossterm>
-<glossdef>
-<simpara>The Planning Council is responsible for cross-project planning, architectural issues,
-user interface conflicts, and all other coordination and integration issues. The Planning
-Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Project</glossterm>
-<glossdef>
-<simpara>Projects are where the real work happens. Each project has code, committers,
-and resources including a web site, source code repositories, space on the build
-and download server, etc. Projects may act as a parent for one or more child
-projects. Each child project has its own identity, committers, and resource.
-Projects may, but do not necessarily, have a dedicated web site. Projects are sometimes referred
-to as <emphasis>subprojects</emphasis> or as <emphasis>components</emphasis>. The Eclipse Development Process, however,
-treats the terms project, subproject, and component as equivalent.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Project Lead </glossterm>
-<glossdef>
-<simpara>The project lead is more of a position of responsibility than one of power. The
-project lead is immediately responsible for the overall well-being of the project.
-They own and manage the project’s development process, coordinate development,
-facilitate discussion among project committers, ensure that the Eclipse IP
-policy is being observed by the project and more. If you have questions about
-your project, the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>, or anything else, ask
-your project lead.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>PMC </glossterm>
-<glossdef>
-<simpara>Each top-level project is governed by a Project Management Committee (PMC). The
-PMC has one or more leads along with several members. The PMC has numerous
-responsibilities, including the ultimate approval of committer elections, and
-approval of intellectual property contributions. Effectively, the PMC provides
-oversight for each of the projects that are part of the top-level project.
-If you have a question that your project lead cannot
-answer, ask the PMC.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>PMI </glossterm>
-<glossdef>
-<simpara>The Project Management Interface (PMI) is the system that tracks the state
-and progress of LocationTech projects. Project committers can modify the the
-information represented in the PMI, including the project description, and
-information about project releases. Automated systems use this information
-to, for example, generate dashboard and chart information for the project,
-intellectual property logs, etc.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Top-Level Project </glossterm>
-<glossdef>
-<simpara>A top-level project (sometimes referred to as a <emphasis>TLP</emphasis>) is effectively a
-container for projects that do the real work.
-A top-level project does not generally contain code; rather, a top-level project contains
-other projects. Each top-level project defines a charter that, among other
-things defines a scope for the types of projects that it contains. Top-level
-projects are managed by a Project Management Committee.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Webmaster </glossterm>
-<glossdef>
-<simpara>The Webmaster team is responsible for maintaining the IT infrastructure
-of the Eclipse Foundation and the LocationTech forge. You can contact the
-Webmaster team directly via email (<link xlink:href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</link>).</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Working Group </glossterm>
-<glossdef>
-<simpara>Eclipse <link xlink:href="https://www.eclipse.org/org/workinggroups">Working Groups</link> provide
-a vendor-neutral governance structure that allow organizations to freely
-collaborate on new technology development.</simpara>
-</glossdef>
-</glossentry>
-</chapter>
-<chapter xml:id="contact">
-<title>Getting Help</title>
-<simpara>If you have any questions, or are unsure of your responsibilities as a
-project lead or committer, please contact your project mentors or
-<link xlink:href="mailto:emo@eclipse.org">EMO</link>.</simpara>
-</chapter>
-</book>
\ No newline at end of file
diff --git a/handbook/locationtech.pdf b/handbook/locationtech.pdf
deleted file mode 100644
index 8fc526c..0000000
--- a/handbook/locationtech.pdf
+++ /dev/null
Binary files differ
diff --git a/handbook/polarsys.book.xml b/handbook/polarsys.book.xml
deleted file mode 100644
index 5708512..0000000
--- a/handbook/polarsys.book.xml
+++ /dev/null
@@ -1,2128 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?asciidoc-toc?>
-<?asciidoc-numbered?>
-<book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-<info>
-<title>PolarSys Project Handbook</title>
-<date>2015-08-18</date>
-</info>
-<preface>
-<title></title>
-<simpara>Copyright © 2015 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0</simpara>
-</preface>
-<chapter xml:id="preamble">
-<title>Overview</title>
-<simpara>This document provides you with the information that you need to
-create a new PolarSys open source project or become a committer
-on an existing one.</simpara>
-<simpara>While this document is focused on PolarSys, it makes several
-"Eclipse" references, including the <emphasis>Eclipse Foundation</emphasis>,
-<emphasis>Eclipse Development Process</emphasis>, and <emphasis>Eclipse Management Organization</emphasis>.
-The Eclipse Foundation is the legal entity that manages the operations
-of the PolarSys working group, software development forge, and community.
-Many of the provided services and contacts are so-named on
-that basis.</simpara>
-<simpara>The <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link> (EDP) is the foundational
-document for PolarSys projects and committers. It describes the
-manner in which we do open source software. The Eclipse Development
-Process does not prescribe any particular development methodology;
-it is more concerned with the larger-scale aspects of open source
-project lifecycle, including such things as reviews, processes for
-running votes and elections, bringing new committers onto a project, etc.
-This document will elaborate on some key points of the Eclipse Development
-Process.</simpara>
-<section xml:id="preamble-principles">
-<title>Principles</title>
-<simpara>Four basic principles lie at the heart of the Eclipse Development Process:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Transparency;</simpara>
-</listitem>
-<listitem>
-<simpara>Openness;</simpara>
-</listitem>
-<listitem>
-<simpara>Meritocracy; and</simpara>
-</listitem>
-<listitem>
-<simpara>Vendor neutrality</simpara>
-</listitem>
-</itemizedlist>
-<simpara>We refer to the first three as the "open source rules of engagement".</simpara>
-<simpara>To operate with <emphasis role="strong">transparency</emphasis>, a project’s discussions, minutes, deliberations,
-project plans, plans for new features, and other artifacts are open, public,
-and easily accessible.</simpara>
-<simpara><emphasis role="strong">Openness</emphasis> at PolarSys means quite a lot more than "open book" (which is
-really a synonym for transparent). The project is open to all;
-PolarSys provides the same opportunity to all. Everyone participates
-with the same rules; there are no rules to exclude any potential contributors
-which include, of course, direct competitors in the marketplace.</simpara>
-<simpara>PolarSys is a <emphasis role="strong">meritocracy</emphasis>. The more that somebody contributes, the more
-responsibility they will earn. A pattern of quality contribution to a project
-may lead to an invitation to join the project as a committer. Leadership roles
-in PolarSys are also merit-based and earned by peer acclaim. Merit must be
-demonstrated in publicly-accessible forums. Committers and project leads are
-added to a project via <link linkend="elections">election</link>.</simpara>
-<note>
-<simpara>Employment status has no bearing at whether or not somebody can participate
-in an open source project at PolarSys. Employment does not guarantee
-committer status; committer status must be earned by everybody.</simpara>
-</note>
-<simpara><emphasis role="strong">Vendor neutrality</emphasis> is similar to openness in that it’s concerned with
-maintaining a level playing field. No vendor is permitted to dominate a project,
-and nobody can be excluded from participating
-in a project based on their employment status. While
-project resources will contain copyright statements that assert ownership of
-various assets by individual vendors, the project itself must remain vendor
-neutral.</simpara>
-<simpara>Quality and intellectual property cleanliness are also important principles.</simpara>
-<simpara><emphasis role="strong">Quality</emphasis> means extensible frameworks and exemplary tools developed in an open,
-inclusive, and predictable process involving the entire community. From the
-consumption perspective, PolarSys quality means good for users (exemplary tools
-are cool/compelling to use, indicative of what is possible) and ready for
-use by adopters. From the creation perspective, PolarSys quality means working
-with a transparent and open process, open and welcoming to participation from
-technical leaders, regardless of affiliation.</simpara>
-<simpara><emphasis role="strong"><link linkend="ip">Intellectual property</link></emphasis> (IP) is any artifact that is made available from
-a PolarSys server (this includes source code management systems, the website,
-and the downloads server). Artifacts include (but are not limited to) such things
-as source code, images, XML and configuration files, documentation, and more.
-Strict rules govern the way that we manage IP and your responsibilities
-as a committer.</simpara>
-<simpara>Code produced by an PolarSys project is used by organizations to build products.
-These adopters of PolarSys technology need to have some assurance that the IP they’re
-basing their products on is <emphasis role="strong">clean</emphasis>: the organization or individuals who claim
-copyright of the code are the legitimate copyright holders, and the copyright
-holders legitimately agree to make the code available under the license(s) that
-the project works under. As a committer, you must be careful that you do not copy
-code and inadvertently claim it as your own.</simpara>
-</section>
-</chapter>
-<chapter xml:id="starting">
-<title>Starting an Open Source Project at PolarSys</title>
-<simpara>PolarSys open source projects start with a proposal that is made
-available to the community for review. At the end of the <emphasis>community
-review</emphasis> period, we engage in a <emphasis>creation review</emphasis>, and then
-provision the project resources.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/project-creation.png"/>
-</imageobject>
-<textobject><phrase>An overview of the Project Creation Process</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Use the <link xlink:href="https://www.polarsys.org/node/add/project-proposal">web form</link> to create a new project proposal.
-Instructions are provided on the form. All new proposals are created
-in <emphasis>draft</emphasis> mode, and are accessible only by the original author and
-anybody designated as a project lead or committer in the proposal.
-Only those individuals designated as a project lead may edit the
-proposal.</simpara>
-<note>
-<simpara>Keep track of the URL of the proposal. We do not provide
-public links to the document until after the proposal is opened for
-community review.</simpara>
-</note>
-<simpara>A proposal must minimally include a description of the project, a
-declaration of scope, and a list of prospective members (project
-leads and committers) before we make it accessible to the public
-for <emphasis>community review</emphasis>.</simpara>
-<simpara>When you feel that the proposal is ready, send a note to
-the Eclipse Management Organization (EMO) at <link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link> requesting that
-the proposal be made available to the public for review. The EMO
-will review the proposal and may provide feedback before initiating
-the <emphasis>community review</emphasis> period.</simpara>
-<simpara>At the beginning of the <emphasis>community review</emphasis> period, the EMO will
-announce the proposal on several channels (the <link xlink:href="http://www.eclipse.org/projects/project_activity.php">Project
-Activity News</link> page, Twitter, the
-<link xlink:href="http://www.eclipse.org/forums/eclipse.proposals">Proposals Forum</link>, blog post, and an email note
-to the Eclipse Foundation members and committers). The EMO will
-also open an record in the Eclipse Foundation’s issue tracker—​an
-instance of Bugzilla—​to track the progress of the proposal;
-the proposal’s author and project leads will be copied on that record.</simpara>
-<simpara>A proposal will be open for community review for a minimum of two
-weeks.</simpara>
-<simpara>The Eclipse Foundation holds the <emphasis>trademark</emphasis> for all PolarSys projects.
-Trademark assignment is undertaken prior to the creation of any new
-project. If you already have a trademark on your project name, that
-trademark must be assigned to the Eclipse Foundation. Be advised that
-trademark assignment can be a time-consuming process (it can take hours,
-days, or weeks depending on the circumstances surrounding the name).
-If you currently hold the trademark, you will be asked to complete a
-<link xlink:href="http://eclipse.org/legal/Trademark_Transfer_Agreement.pdf">Trademark Transfer Agreement</link>.</simpara>
-<simpara>The proposal must list two mentors from the Architecture Council.
-Members of the Architecture Council have considerable experience with
-Eclipse Foundation practices, and the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>.
-If you are already in contact with mentors who agree to help you with
-your project, please do list them in the proposal. Otherwise, the
-EMO will engage directly with the Architecture Council to identify
-mentors as necessary. Mentors are available to the project through the
-incubation phase; they are released from their duties when the project
-<link linkend="release-graduation">graduates</link>.</simpara>
-<simpara>When the project name trademark has been secured, mentors have been
-identified, and the proposal contents are finalized, the EMO will schedule
-a <emphasis>creation review</emphasis>. Reviews—​which run for a minimum of one week—​are
-scheduled twice a month, generally concluding on the first and third
-Wednesday of each month. The creation review may overlap with the
-<emphasis>community review</emphasis> period.</simpara>
-<note>
-<simpara>Creation reviews tend to always be successful. They should be
-considered low stress as the hard work has already been done in
-advance of the start of the review.</simpara>
-</note>
-<simpara>Following the creation review, the EMO will initiate the provisioning process.
-To gain committer status, some <link linkend="paperwork">committer paperwork</link> must be completed
-as part of the provisioning process. The exact nature of that
-paperwork depends on several factors, including the employment status
-of the individual and the Eclipse Foundation membership status of their employer.</simpara>
-<note>
-<simpara>If you can be ready with the paperwork in time for the completion of the
-creation review, then we can move quickly through the provisioning process.
-When we initiate provisioning, committers will be sent an email with
-instructions; please don’t send any paperwork in until after you receive
-those instructions.</simpara>
-</note>
-<section xml:id="starting-after-provisioning">
-<title>After Provisioning</title>
-<simpara>The Webmaster will send a note announcing the completion of the provisioning
-process. Before you commit any code into your project repository, you must
-submit your project’s <link linkend="ip-initial-contribution"><emphasis>initial contribution</emphasis></link> and
-list of third-party libraries for review by the IP team.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/post-creation.png"/>
-</imageobject>
-<textobject><phrase>Post creation activities</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Do not commit any code to your project’s source code repository until after
-you receive approval for the IP Team. Once you’ve received that approval,
-you can do builds and produce milestones for your first release. You must
-wait until after the IP Team has approved your initial contribution and use
-of third-party libraries before you do any official <link linkend="release">releases</link>.</simpara>
-</section>
-<section xml:id="starting-project-phases">
-<title>Project Phases</title>
-<simpara>All new projects start in the <emphasis>incubation phase</emphasis> (a project in the
-incubation phase is said to be <emphasis>incubating</emphasis>). The classification of
-a project in the incubation phase is not a statement about the quality
-of the project’s code; rather, incubation phase is more about the
-project team’s progress in practicing the open and public processes
-necessary to establish the three communities (developers, adopters,
-and users) around the project.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Egg-incubation.png"/>
-</imageobject>
-<textobject><phrase>The Incubation Logo</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>In order to alert potential consumers of the incubating nature,
-projects in the incubation phase must include <emphasis>incubation branding</emphasis>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Display the incubation logo on their project web page (if they have one);</simpara>
-</listitem>
-<listitem>
-<simpara>Displays the incubation logo on their project’s primary download page;</simpara>
-</listitem>
-<listitem>
-<simpara>Include the word "incubation" in the filename of all downloadable
-files (when technically feasible) for builds and milestones;</simpara>
-</listitem>
-<listitem>
-<simpara>When technically feasible, include the word "incubation" in features
-(e.g. about dialogs, feature lists, and installers).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>There are no incubation branding requirements for general
-user interface elements.</simpara>
-<simpara>For projects that produce OSGi artifacts, include the word
-"incubation" in the <emphasis>Bundle-Name</emphasis>, feature names, and p2 repositories.</simpara>
-<note>
-<simpara>The word "incubation" should not be included in technical
-namespaces (especially when it may result in confusion when the project
-leaves incubation). e.g. an OSGi bundle’s <emphasis>Bundle-SymbolicName</emphasis>, or a
-Java package name.</simpara>
-</note>
-<simpara>Incubating projects that correctly conform to the incubation branding
-rules outlined above may take advantage of the <link linkend="ip-parallel-ip">Parallel
-IP Process</link>. They are encouraged to produce milestone builds, make
-releases, and grow their community.</simpara>
-<simpara>When the project code is ready (e.g. stable APIs) and the project team
-has learned to operate as an open source project according to the
-Eclipse Development Process, the project may opt to <emphasis>graduate</emphasis> into
-the <emphasis>mature phase</emphasis>.</simpara>
-<simpara>Most of the lifetime of a PolarSys project is spent in the mature phase.
-A mature project is one that is a good open source citizen with open,
-transparent, and meritocractic behavior. The project is regularly
-and predictably releasing IP clean extensible frameworks and
-exemplary tools. The project is actively nurturing the three
-communities: developers, adopters, and users.</simpara>
-</section>
-<section xml:id="starting-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>How do I find Architecture Council mentors? </simpara>
-</question>
-<answer>
-<simpara>You don’t have to find them yourself. Focus on the content of the
-proposal. We can solicit mentors from the Architecture Council after
-the proposal has been opened for community review.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I change the proposal after it is posted? </simpara>
-</question>
-<answer>
-<simpara>Yes. The proposal can be changed any time before the start of the
-start of the creation review.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>When do I submit my code for review by the IP team? </simpara>
-</question>
-<answer>
-<simpara>Submit your code (initial contribution) for review after the project
-has been provisioned. The Eclipse Webmaster will let you know via
-email when provisioning is complete.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Does the new project have to use Git? </simpara>
-</question>
-<answer>
-<simpara>Yes. Git is the only source code management system that is currently
-permitted for new projects.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I host my project code on GitHub? </simpara>
-</question>
-<answer>
-<simpara>New projects can make use of <link linkend="resources-github">GitHub</link>. Official project repositories
-must be moved under the <link xlink:href="https://github.com/polarsys">PolarSys Organization</link> at GitHub.
-Official repositories are subject to the same intellectual
-property due diligence rules and processes that all Eclipse project
-repositories must follow.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How long should I let my project incubate? </simpara>
-</question>
-<answer>
-<simpara>It depends. Community expectations are one factor. Team experience
-with open source is another. If your team is new to open source,
-it may make sense to stay in incubation a little longer than a
-seasoned team with a mature code base might. As a general rule,
-though, projects should plan to leave incubation within a year.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Does the mature project code that I’m bring to PolarSys need to incubate? </simpara>
-</question>
-<answer>
-<simpara>Yes. All new projects start in the incubation phase. Remember
-that incubation is as much about the project team learning about
-how to operate as an open source project as it is about the
-project code. Project teams that "get it" can opt to exit
-incubation quickly (e.g. with their first release) if that
-makes sense for the team and the community.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What do all these terms (e.g. EMO) mean? </simpara>
-</question>
-<answer>
-<simpara>Please see the <link linkend="glossary">glossary</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="project-resources-and-services">
-<title>Project Resources and Services</title>
-<simpara>Open source projects at the Eclipse Foundation are required to make use
-of certain Eclipse Foundation services:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>All project issues must be tracked in the <link xlink:href="https://www.polarsys.org/bugs">PolarSys Bugzilla</link>
-instance;</simpara>
-</listitem>
-<listitem>
-<simpara>Source code must be maintained in source code repositories assigned to the
-project (e.g. a PolarSys <link xlink:href="https://git.polarsys.org/c">Git</link> or <link xlink:href="https://git.polarsys.org/r">Gerrit</link> instance,
-or the <link xlink:href="https://github.com/polarsys">PolarSys Organization</link> on GitHub);</simpara>
-</listitem>
-<listitem>
-<simpara>All third-party libraries used by the project must be tracked and
-approved for use by the Eclipse IP Team;</simpara>
-</listitem>
-<listitem>
-<simpara>Downloads must be distributed via a forge-specific downloads server;</simpara>
-</listitem>
-<listitem>
-<simpara>Developer (committer) communication must occur in the <emphasis>dev</emphasis> list
-provided to the project by the Eclipse; and</simpara>
-</listitem>
-<listitem>
-<simpara>Projects must keep their <link linkend="pmi-metadata">Project Metadata</link> up-to-date.</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="resources-source">
-<title>Source Code Management</title>
-<simpara>Your project must maintain source code in the repositories assigned to the
-project by the Eclipse Foundation. These official repositories must be
-the exclusive source of all project code delivered via the project’s assigned
-distribution channel (e.g. the download server).</simpara>
-<simpara>In order for your project to operate in an <emphasis>open</emphasis> manner, it must be possible
-for potential contributors to have access to the code base in its most current
-form, so all ongoing development must be regularly pushed to these canonical
-repositories.</simpara>
-<section xml:id="resources-cla">
-<title>Contributor License Agreement (CLA)</title>
-<simpara>The Eclipse Foundation has implemented <link xlink:href="https://www.eclipse.org/legal/CLA.php">Contributor License Agreements</link> (CLA)
-to improve <link linkend="ip">intellectual property</link> (IP) management and workflow. All
-contributors, who are not committers on the PolarSys project, must sign the CLA.</simpara>
-<simpara>You do <emphasis role="strong">not</emphasis> require a CLA to contribute to a project on which you have committer
-status.</simpara>
-</section>
-<section xml:id="resources-commit">
-<title>Git Commit Records</title>
-<simpara>Git commit records are required to take a specific form. The credentials
-of the actual author must be used to populate the <literal>Author</literal> field. The email
-address used must match the email address that the Eclipse Foundation has
-on file for the author (case-sensitive).</simpara>
-<simpara>The commit message is divided into three sections:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>One line (max 72 characters) summary;</simpara>
-</listitem>
-<listitem>
-<simpara>Description; and</simpara>
-</listitem>
-<listitem>
-<simpara>Footer.</simpara>
-</listitem>
-</orderedlist>
-<formalpara>
-<title>Example Git Commit Record</title>
-<para>
-<screen>commit d6cf52411377a039fc2906378711091a26e932cb
-Author: Some Body <somebody@somewhere.com> <co xml:id="CO1-1"/>
-Date: Wed May 29 16:17:36 2013 +0200
-
- Bug 350686 - Hide unwanted action bar items <co xml:id="CO1-2"/>
-
- This change hides unwanted 'Link with Editor' and
- 'Customize View...' items from the local toolbar
- and the view menu.
-
- Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 <co xml:id="CO1-3"/>
- Also-by: Some Bodyelse <somebodyelse@nowhere.com> <co xml:id="CO1-4"/>
- Signed-off-by: Some Body <somebody@somewhere.com> <co xml:id="CO1-5"/></screen>
-</para>
-</formalpara>
-<calloutlist>
-<callout arearefs="CO1-1">
-<para>The email address of the author must match the email address on the Eclipse Foundation account.</para>
-</callout>
-<callout arearefs="CO1-2">
-<para>Best practice: include the bug id in the commit message summary.</para>
-</callout>
-<callout arearefs="CO1-3">
-<para>Gerrit change id (only when pushing to Gerrit for review).</para>
-</callout>
-<callout arearefs="CO1-4">
-<para>Additional authors can be added using <literal>Also-by</literal> entries.</para>
-</callout>
-<callout arearefs="CO1-5">
-<para>Non-committers must <emphasis>sign-off</emphasis> the commit using the same email address as used in the author field.</para>
-</callout>
-</calloutlist>
-<simpara>The <emphasis>summary</emphasis> line is used in many places where Git commits are listed, ensure
-that this line is sensible by itself. The <emphasis>description</emphasis> area should be used to provide
-more detail about the commit. The footer area is used for extra fields and values.</simpara>
-<simpara>If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx")
-Gerrit Code Review will automatically add a link in the
-corresponding Bugzilla record back to the Gerrit record (this, of course, only
-applies to commits pushed to Gerrit).</simpara>
-<simpara>The <literal>Change-Id</literal> is used by <link linkend="resources-gerrit">Gerrit Code Review</link> to associate new versions
-of a change back to its original review. This field need only be specified if the
-repository is managed by Gerrit.</simpara>
-<simpara>Create a separate <literal>Also-by</literal> field for each additional author of a commit. This might
-apply, for example, if a commit has been authored via pair-programming, or the commit
-is the result of collapsing multiple commits authored by multiple developers.</simpara>
-<simpara>Commits that are provided by non-committers must have a <literal>Signed-off-by</literal> field in the
-footer indicating that the author is aware of the terms by which the contribution has been
-provided to the project. The non-committer must additionally have an Eclipse Foundation
-account and must have a signed <link linkend="resources-cla">Contributor License Agreement</link> (CLA)
-on file.</simpara>
-</section>
-<section xml:id="resources-git">
-<title>Git</title>
-<simpara>Those projects that want to use Git on the PolarSys forge, are assigned a
-directory in which they may create as many Git repositories as required.
-<link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Git">Open a bug</link> to request that the Webmaster create a new Git
-repository for your project. Alternatively, committers with shell accounts
-can create repositories themselves.</simpara>
-<formalpara>
-<title>Create a new Git repository</title>
-<para>
-<screen>> initrepo /gitroot/project/org.polarsys.repo.name.git</screen>
-</para>
-</formalpara>
-<simpara>For consistency, the name of the repository must end with <literal>.git</literal>.</simpara>
-<simpara>To set the description of the repository, use <literal>sftp</literal> or <literal>scp</literal> to copy a text file to
-<literal>/gitroot/project/org.polarsys.repo.name.git/description</literal>. Git repository
-descriptions should be limited to a paragraph of one or two sentences.</simpara>
-<simpara>Only project committers can push to a PolarSys Git repository. A push
-that includes commits that do not conform to the required form will be rejected.</simpara>
-<simpara>You can <link xlink:href="https://git.polarsys.org/c">browse PolarSys repositories</link> directly on the Git server.</simpara>
-</section>
-<section xml:id="resources-gerrit">
-<title>Gerrit Code Review</title>
-<simpara><link xlink:href="https://www.gerritcodereview.com/">Gerrit</link> provides web based code review and
-repository management for the Git version control system. Many projects use
-Gerrit to reduce barriers and encourage contribution to the project.
-<link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Gerrit">Open a bug</link> to request that the Webmaster configure your
-Git repository for Gerrit.</simpara>
-<simpara>Commits may be pushed directly to the Git repository through Gerrit by
-a project committer (e.g. to the <literal>master</literal> branch).</simpara>
-<simpara>Anybody can push to a <literal>refs/for/*</literal> branch for review in a Gerrit repository. A push
-that includes commits that do not conform to the required form will be rejected.
-Commits intended for review should have a
-<link xlink:href="https://git.eclipse.org/r/Documentation/user-changeid.html"><literal>Change-Id</literal></link></simpara>
-<simpara>You can <link xlink:href="https://git.polarsys.org/r">browse PolarSys repositories</link> directly on the Gerrit
-server.</simpara>
-</section>
-<section xml:id="resources-github">
-<title>GitHub</title>
-<simpara>Projects may opt to move some or all of their canonical source code repositories to the
-<link xlink:href="https://github.com/polarsys">PolarSys organization</link> on GitHub.</simpara>
-<note>
-<simpara>Projects that host source code on GitHub are not permitted to use GitHub
-Issues or Wiki.</simpara>
-</note>
-<simpara><link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=GitHub">Open a bug</link> to request that the Webmaster create a new, or move
-an existing, Git repository for your project. The Webmaster will install some
-<emphasis>hooks</emphasis> on your GitHub repository.</simpara>
-<simpara>The <emphasis>Committers hook</emphasis> grants designated project committers write access to the
-GitHub-hosted project repositories. Project committers must use the email address they
-provide to the Eclipse Foundation as their GitHub email address.</simpara>
-<simpara>The <link linkend="resources-cla">Contributor License Agreement</link> (CLA) hook will inspect incoming
-GitHub pull requests to ensure that the contributor has a valid CLA on file, and that
-the commit has been "signed-off" as required. Project committers should only merge pull
-<emphasis>green</emphasis> requests:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Github-cla-success.png"/>
-</imageobject>
-<textobject><phrase>Github cla success</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>The GitHub API does not give us a means of absolutely denying a merge; all we can
-do is warn you that the contributors have not signed a CLA:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/Github-cla-failure.png"/>
-</imageobject>
-<textobject><phrase>Github cla failure</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Do not merge unless you are absolutely certain that the contributer does have a
-valid CLA on file (e.g. the Contributor License Agreement Lookup Tool confirms
-that they have a CLA).</simpara>
-<simpara>You must manually check that the commit message includes the
-required "Signed-off-by" statement in the footer.</simpara>
-<simpara>The Webmaster creates and maintains a mirror of all GitHub-hosted
-repositories on Eclipse Foundation hardware.</simpara>
-</section>
-</section>
-<section xml:id="resources-libraries">
-<title>Third-party Libraries</title>
-<simpara>PolarSys projects must register all of their <link linkend="ip-third-party">third-party library</link> use with the
-IP Team.</simpara>
-</section>
-<section xml:id="resources-forums">
-<title>Forums and Outbound Communication</title>
-<simpara>All projects are assigned a <link xlink:href="http://www.polarsys.org/forums">user forum</link> as a point of contact between
-the user and adopter communities, and the project developers.</simpara>
-<simpara>The EMO strongly encourages the use of alternative communication channels for
-connecting with the community: your project team knows your community and how
-to best connect with them.</simpara>
-</section>
-<section xml:id="resources-website">
-<title>Project Websites</title>
-<simpara>Project websites are an excellent way to connect your project with
-your community. Many projects opt to use the <link linkend="pmi">Project Management Infrastructure</link>
-(PMI) as their project website,
-but if so-desired, a project may host a website on Eclipse Foundation-hosted
-servers.</simpara>
-<simpara>Project website sources are hosted in Git repositories maintained by the
-Eclipse Foundation. <link xlink:href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Website">Open a bug</link> to request that the Webmaster
-create a website for your project.</simpara>
-<note>
-<simpara>Alternative hosting services for project-specific websites are
-not permitted. Websites <emphasis>not</emphasis> hosted by the Eclipse Foundation are
-considered third-party and so are subject to the
-<link xlink:href="https://eclipse.org/legal/logo_guidelines.php">Guidelines for Eclipse
-Logo & Trademarks</link> (the Eclipse foundation asserts ownership of the
-project name trademark).</simpara>
-</note>
-</section>
-<section xml:id="resources-builds">
-<title>Builds</title>
-<simpara>Use of Eclipse Foundation-provided and hosted build services, the so-called
-<link xlink:href="http://wiki.eclipse.org/CBI">Common Build Infrastructure</link> (CBI) is strongly recommended, but n
-ot strictly required.</simpara>
-<simpara>Whether or not your project chooses to make use of provided build resources, it must
-be possible for members of the community to build project artifacts from
-source code with reasonable effort.</simpara>
-<section xml:id="resources-signing">
-<title>Signed Artifacts</title>
-<simpara>Where technically sensible, all downloadable artifacts should
-be <link xlink:href="https://wiki.eclipse.org/JAR_Signing">signed</link> by an Eclipse Foundation-provided certificate.</simpara>
-</section>
-</section>
-<section xml:id="resources-downloads">
-<title>Downloads</title>
-<simpara>Project artifacts (e.g. downloads) can be distributed via third-party
-services (e.g. Maven Central), but the Eclipse Foundation-provided
-infrastructure must be considered the primary source of project
-downloads.</simpara>
-<simpara>Project committers can <link xlink:href="https://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads">upload project artifacts</link> to the project’s
-directory on the download server.</simpara>
-</section>
-</chapter>
-<chapter xml:id="paperwork">
-<title>Committer Paperwork</title>
-<simpara>The Eclipse Foundation needs to ensure that all committers with write
-access to the code, web site, and issue tracking system understand their role in
-safeguarding the intellectual property of PolarSys. The Eclipse Foundation also
-needs to ensure that we have accurate records of the people who are
-acting as change agents on the projects. To ensure that
-committers understand their role, and that that Eclipse Foundation has
-accurate records, committers must provide documentation asserting
-that they have read, understood, and will follow the committer guidelines, and to have
-their employer sign that they agree that the new committer
-can participate at PolarSys and can contribute under the terms of the
-project license.</simpara>
-<simpara>All committers must complete the <emphasis>Committer Questionnaire</emphasis> and provide documentation
-as described below.</simpara>
-<section xml:id="paperwork-questionnaire">
-<title>Committer Questionnaire</title>
-<simpara>The <link xlink:href="http://portal.eclipse.org">Committer Questionnaire</link> is an online form that
-must be completed by all new committers. This form offers two separate paths:
-one for committers who work for a member company that has provided a signed
-Member Committer Agreement, and one for everybody else.</simpara>
-<note>
-<simpara>The <emphasis>Committer Questionnaire</emphasis> is accessible only after you have been elected as
-a committer on a project, either as an initial committer on a new project, or
-via election on an existing project.</simpara>
-</note>
-<simpara>Only member companies that have provided a signed Member Committer Agreement
-will be listed as member companies in the Committer Questionnaire.</simpara>
-</section>
-<section xml:id="paperwork-documents">
-<title>Documents</title>
-<simpara>The exact nature of the documentation required is dependent on your
-employments status.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/paperwork.png" width="75%" scalefit="1"/>
-</imageobject>
-<textobject><phrase>Paperwork requirements flowchart.</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Documents must be printed, signed and then returned either by fax
-(using the fax number on the form) or as scanned images via email
-to <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-<section xml:id="paperwork-mca">
-<title>Member Committer Agreement</title>
-<simpara>The <link xlink:href="http://www.eclipse.org/legal/committer_process/EclipseMemberCommitterAgreementFinal.pdf">Member Committer Agreement</link> (MCA) is used by member companies to
-cover all of their employees who participate in Eclipse Foundation projects
-as committers.</simpara>
-<simpara>If your employer has provided a signed MCA, then you most likely do not
-require any additional paperwork.</simpara>
-<note>
-<simpara>MCAs make committer paperwork easy, especially if you
-work for a member company that employs multiple committers. With an MCA a
-company can provide signed documentation once, rather than once for each
-employee (as required for an Individual Committer Agreement).</simpara>
-</note>
-<simpara>If your employer has not already provided an MCA, consult with your management
-team to determine who has the necessary authority to sign it on your company’s
-behalf. Provide the MCA in advance of the completion of your committer election
-or new project creation to streamline the committer provisioning process.
-If you and your management team are not sure whether or
-not your employer has an MCA, ask <link xlink:href="mailto:emo-records@eclipse.org">EMO Records</link>.</simpara>
-<simpara>If your employer is a member company that cannot provide a signed
-MCA, then you’ll have to complete an Individual Committer Agreement and
-Eclipse Committer Employer Consent Form.</simpara>
-</section>
-<section xml:id="paperwork-ica">
-<title>Individual Committer Agreement</title>
-<simpara>The Individual Committer Agreement (ICA) greement is used by committers
-who are not covered by an Member Committer Agreement.</simpara>
-<simpara>You will need to provide an ICA if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>You work for member company that has not signed a Member Committer Agreement;</simpara>
-</listitem>
-<listitem>
-<simpara>You work for a company that is not a member of the Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>You are self employed or not employed; or</simpara>
-</listitem>
-<listitem>
-<simpara>You are a student.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If you provide an Individual Committer Agreement, and are employed
-or self-employed, then you also need an <emphasis>Eclipse Committer Employer</emphasis>
-Consent Form.</simpara>
-</section>
-<section xml:id="paperwork-ececf">
-<title>Eclipse Committer Employer Consent Form</title>
-<simpara>Committers covered by an Individual Committer Agreement must document
-the consent of their employer when participating in Eclipse Foundatio
-projects by providing an Eclipse Committer Employer Consent Form (ECECF).</simpara>
-<simpara>You will need to provide an <link xlink:href="http://www.eclipse.org/legal/committer_process/employer_consent.pdf">ECECF</link> if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>You work for member company that has not signed a Member Committer Agreement;</simpara>
-</listitem>
-<listitem>
-<simpara>You work for a company that is not a member of the Eclipse Foundation; or</simpara>
-</listitem>
-<listitem>
-<simpara>You are self-employed.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If you are self employed, an owner of your own company, or
-have full ownership or part ownership in another company and has the
-authority to sign and submit the Eclipse Committer Employer Consent Form
-on your own behalf, then they should do so.</simpara>
-<simpara>Alternatively, you may arrange for the company that is
-your principal business customer to sign and submit the
-Eclipse Committer Employer Consent Form on your behalf.</simpara>
-</section>
-</section>
-<section xml:id="paperwork-existing">
-<title>Existing Committer</title>
-<simpara>If you are already a committer on an existing Eclipse Foundation project then
-additional paperwork may or may not be needed. The EMO IP Team will ask for
-additional documentation if required.</simpara>
-<simpara>If that MCA or ECECF already explicitly covers you for the
-new project, or that MCA or ECECF is universal (for all projects),
-then no additional paperwork is required</simpara>
-<simpara>If you are covered by an MCA or ECECF that does not include
-the new project, then the candidate must provide the documents as described
-above.</simpara>
-</section>
-<section xml:id="paperwork-not-employed">
-<title>Not Employed or Student</title>
-<simpara>If you are not employed or are a student, send a note to <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>
-explaining your not employed or student status.</simpara>
-<note>
-<simpara>We require this email because most new committers are employed by a company,
-the Eclipse Legal Team assumes that is the case for everyone, thus exceptions
-need to be noted.</simpara>
-</note>
-</section>
-<section xml:id="paperwork-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>What happens if I do not fill out the paperwork?</simpara>
-</question>
-<answer>
-<simpara>Then you don’t get your login and password for write-access to the
-source code repository(s). Sorry. No exceptions.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What happens if I cannot convince my employer to fill out the paperwork?</simpara>
-</question>
-<answer>
-<simpara>The Eclipse Board of Directors has taken a firm position that if you are
-employed then you must meet one of the scenarios described above. If you cannot
-convince your employer to fill out the necessary paperwork, then you may
-not have write-access to project resources. This is the
-Board’s position <emphasis>even if</emphasis> you are working on PolarSys projects on your
-own time. We realize that this prevents some talented and desirable
-people from being able to commit to the projects but this is our
-IP risk reduction strategy.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Where can I get help to discuss these documents with my management team? </simpara>
-</question>
-<answer>
-<simpara>The EMO and the Executive Director are happy to talk to your management
-and senior executives about these (and other) legal documents to
-help them understand why these documents are the best risk reduction
-solution for everyone involved (The Eclipse Foundation, you, and your
-employer); just contact us at <link xlink:href="mailto:license@eclipse.org">license@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What formats can be used to submit paper documentation? </simpara>
-</question>
-<answer>
-<simpara>The Eclipse Foundation accepts any of the following formats for
-submitting a paper form:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Print, sign, and postal mail the form to the Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>Print, sign, and fax the form to the Eclipse Foundation; or</simpara>
-</listitem>
-<listitem>
-<simpara>Print, sign, scan, and email to the scan as an attachment to the Foundation</simpara>
-</listitem>
-</itemizedlist>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What Email address should I use to send scanned documents? </simpara>
-</question>
-<answer>
-<simpara>Email scans of the completed paperwork to EMO Records at <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What if a committer changes employers? </simpara>
-</question>
-<answer>
-<simpara>If you change employers, please contact <link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="ip">
-<title>Intellectual Property</title>
-<simpara>PolarSys projects are expected to take necessary precautions to mitigate
-intellectual property (IP) risk to adopters. A company that integrates the code
-from your project, for example, does so with confidence that the code in the
-project can legally be distributed under the agreed-to terms. The
-<link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">IP Due Diligence Process</link>, managed by the Eclipse IP Team
-(commonly referred to as the <emphasis>IP Team</emphasis>), is in place to support this.</simpara>
-<simpara>All PolarSys committers must be familiar with the <link xlink:href="http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP
-Policy</link>.</simpara>
-<section xml:id="ip-initial-contribution">
-<title>Initial Contribution</title>
-<simpara>Code provenance tracking is critical (we need to know the source of all code
-that ends up in our repositories). To that end, all new projects are required to
-make an <emphasis>initial contribution</emphasis> before <emphasis role="strong">any</emphasis> code is committed to a project’s
-source code repository.</simpara>
-<simpara>The IP Team will review your initial contribution to ensure that the code can
-distributed through a PolarSys property. The IP Team will review the code to
-make sure that it hasn’t been copied inappropriately, that licenses are being
-used correctly, and so forth. As part of this process, the IP Team will
-research the source of all code; depending on the size of the contribution, this
-can be a time-consuming process.</simpara>
-<note>
-<simpara>A project cannot make a <link linkend="release">release</link> until the due diligence on
-the IP contained in that release—​including project code contributions and
-third-party libraries—​is complete.</simpara>
-</note>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit the initial contribution
-for review by the IP Team.</simpara>
-<simpara>The IP Team is not able to review the history of project code being moved to
-a PolarSys project. The IP Team will review a snapshot of the project code and
-that snapshot, the <emphasis>initial contribution</emphasis>, must be the first commit in the
-PolarSys repository. If your project uses an existing GitHub repository, the
-Webmaster team will help you obscure the the history into a hidden branch.</simpara>
-</section>
-<section xml:id="ip-project-code">
-<title>Project Code Contributions</title>
-<simpara>Some contributions of code to maintained by the project (i.e. committed to a
-project source code repository and maintained by the project team) must be
-reviewed by the IP Team. The <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">IP Due Diligence Process</link>
-provides help to determine whether or not the contribution needs to be reviewed
-by the IP Team. If you’re not sure, ask your project mentors or your PMC for
-assistance.</simpara>
-<simpara>All contributions of project code must be tracked in the project’s
-<link linkend="ip-iplog">IP Log</link>.</simpara>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit a project code
-contribution for review by the IP Team.</simpara>
-</section>
-<section xml:id="ip-third-party">
-<title>Third-Party Libraries</title>
-<simpara>All third-party libraries required by project code will have to be checked
-and approved by the IP Team.</simpara>
-<simpara>The IP Team must review a third-party library if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the Java/OSGi manifest for one of the project bundles makes a
-direct reference to a third-party library (either the library bundle
-or a package from the library);</simpara>
-</listitem>
-<listitem>
-<simpara>project code includes an import statement for a package from a
-third-party library;</simpara>
-</listitem>
-<listitem>
-<simpara>project code uses reflection or other means to reference a
-library’s APIs and implementation;</simpara>
-</listitem>
-<listitem>
-<simpara>project code uses OSGi Services to make a reference to a
-specific implementation of a service; or</simpara>
-</listitem>
-<listitem>
-<simpara>project code invokes a "command line" tool.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>This list is not intended to be exhaustive.</simpara>
-<simpara>The <link xlink:href="http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf">Guidelines for the Review of Third Party Dependencies</link> can help
-you determine how to classify your third-party libraries.</simpara>
-<note>
-<simpara>A project cannot make a <link linkend="release">release</link> until the due diligence on
-the IP contained in that release—​including project code contributions and
-third-party libraries—​is complete.</simpara>
-</note>
-<simpara>Create a <link linkend="ip-cq">contribution questionnaire</link> to submit a third-party
-library for review by the IP Team.</simpara>
-</section>
-<section xml:id="ip-ownership">
-<title>Ownership</title>
-<simpara>The author of a contribution (or their employer) retains ownership of the
-intellectual property contained in the contribution. As part of the contribution
-process, the contributor licenses their contribution under the project license.</simpara>
-</section>
-<section xml:id="ip-copyright-headers">
-<title>Copyright and License Headers</title>
-<simpara>All source files must include a file header that describes the copyright and
-license terms of the software.</simpara>
-<formalpara>
-<title>Example Copyright and License Header</title>
-<para>
-<screen>/*******************************************************************************
- * Copyright (c) 2015 Schmedly Inc. and others. <co xml:id="CO2-1"/>
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html <co xml:id="CO2-2"/>
- *
- * Contributors:
- * Wayne Beaton - initial API and implementation <co xml:id="CO2-3"/>
- *******************************************************************************/</screen>
-</para>
-</formalpara>
-<calloutlist>
-<callout arearefs="CO2-1">
-<para>Name the initial copyright owner; this must be a legal entity (e.g. a company or individual).
-If other organizations have contributed, include "and others".</para>
-</callout>
-<callout arearefs="CO2-2">
-<para>List project licenses.</para>
-</callout>
-<callout arearefs="CO2-3">
-<para>Optionally list the names of the contributors and the nature of their contribution.</para>
-</callout>
-</calloutlist>
-<simpara>Your project is not a legal entity and so it is inappropriate to list it as
-the copyright owner.</simpara>
-<warning>
-<simpara>The copyright owner is either an individual or their employer. Most
-employment contracts stipulate that the intellectual property creations of an
-employee are the property of the employer and so the employer should generally
-be listed as the copyright owner.</simpara>
-</warning>
-<simpara>For more information please see the <link xlink:href="https://www.eclipse.org/legal/copyrightandlicensenotice.php">Default Eclipse Foundation Copyright and License Notice</link>.</simpara>
-</section>
-<section xml:id="ip-licensing">
-<title>Licensing</title>
-<simpara>PolarSys top level projects define the standard licensing for their
-projectsd. If your project has non standard licensing requirements,
-you may need to make a presentation to the Eclipse board of directors
-to request their approval. The presentation need only briefly describe
-the project and why special licensing considerations are necessary.</simpara>
-</section>
-<section xml:id="ip-cq">
-<title>Contribution Questionnaires</title>
-<simpara>A Contribution Questionnaires (CQ) is the main interface
-between PolarSys committers and the IP Team.</simpara>
-<simpara>A CQ is started when a committer completes a <emphasis>questionnaire</emphasis> regarding
-a contribution or third-party library. In literal terms, a CQ is a
-record in a modified instance of Bugzilla, named <emphasis>IPZilla</emphasis>,
-that tracks the progress of the approval process. The CQ record is the
-primary communication channel between the submitting committer and the
-IP Team. CQ records persist indefinitely.</simpara>
-<note>
-<simpara>You can review existing CQs via <link xlink:href="https://dev.eclipse.org/ipzilla">IPZilla</link>. Note that
-IPZilla is accessible only by committers, Eclipse Foundation member company
-represenatives, and other specifically-designated individuals.</simpara>
-</note>
-<simpara>All significant contributions of code to be maintained by a PolarSys project, as
-defined by the Eclipse IP Due Diligence Process require a CQ.</simpara>
-<simpara>Projects require a CQ for every third-party library that project
-code makes direct use of (regardless of whether or not the library
-is directly distributed by the project. If your code makes indirect
-use of a third party library through another PolarSys
-project’s code, you do not require a CQ for that library.</simpara>
-<note>
-<simpara>CQs for third-party libraries are <emphasis>version-specific</emphasis>. That is,
-a separate CQ is required for different versions of the same library.</simpara>
-</note>
-<simpara>CQs are not generally required for ongoing work done by project
-committers. Consult the IP Due Diligence Process document for
-more information.</simpara>
-<section xml:id="ip-parallel-ip">
-<title>Parallel IP</title>
-<simpara>The <emphasis>Parallel IP Process</emphasis> allows PolarSys projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team. In practical terms, the Parallel
-IP Process permits—​with preliminary approval from the IP Team—​a
-project to check-in code contributions into their source code
-repository and run builds against third-party libraries
-without having to wait for the full IP Due Diligence Process to
-compete.</simpara>
-<note>
-<simpara>There is some risk associated with the Parallel IP Process.
-The IP Team will grant preliminary approval based on a cursory
-review of the contribution; but during their full review, they may
-uncover issues that require mitigation. This may require, for
-example, that some parts of a contribution be removed completely
-(history and all) from a source code repository.</simpara>
-</note>
-<simpara>Parallel IP manifests in two different ways: projects in the
-<emphasis>incubation phase</emphasis> may leverage the Parallel IP process for
-project code and third-party libraries. <emphasis>Mature phase</emphasis> projects
-may leverage parallel IP for new versions of third-party libraries
-for which previous versions have already been approved.</simpara>
-<simpara>To leverage the Parallel IP Process, projects still submit CQ.
-The difference is that once a CQ has been reviewed for
-license compatibility, the project will be authorized via IPzilla
-to check-in the code start working on it.</simpara>
-<simpara>All IP must be fully approved before it is included in a release.</simpara>
-</section>
-<section xml:id="ip-piggyback">
-<title>Piggyback CQs</title>
-<simpara>Many third party libraries have already been approved for use in PolarSys projects.
-Many of those are immediately available via the <link xlink:href="http://www.eclipse.org/orbit">Orbit Project</link>.
-While these libraries have already been cleared for use by all projects,
-their use must be tracked. Usage is tracked so that—​in the event that a issue is uncovered
-following the due diligence process—​we can mitigate the impact of that issue.</simpara>
-<simpara>In this case, a <emphasis>piggyback CQ</emphasis> can be created on top of an existing CQ. Piggyback CQs
-are generally approved very quickly as the due diligence work has already been completed.</simpara>
-</section>
-<section xml:id="ip-cq-workflow">
-<title>CQ Workflow</title>
-<simpara>The workflow for creating a CQ for a third-party library starts with a search of existing
-CQs. If an existing CQ can be found that is concerned with the same library and version,
-then a piggyback CQ is created. Piggyback CQs must be approved by the project’s Project
-Management Committee (PMC) before they are processed by the EMO IP Team.</simpara>
-<simpara>If an existing CQ cannot be found, a new one must be created. Once created, the source
-code for the third-party library must be attached to the record. The PMC must then approve
-the record. If the project is eligible to leverage the Parallel IP Process, the IP
-Team performs a cursory review of the record and—​if the CQ meets with the
-requirements—​tentatively approves the use of the library while the full review is
-undertaken in parallel.</simpara>
-<simpara>The IP team may require your assistance as it performs a deep analysis of the library.
-Once that analysis is complete and the IP team has made a decision, they will outline
-the next steps. These next steps may—​in the event that the library is rejected—​that
-the library be removed from the project VCS, or that some part be removed. Most often,
-the library is approved and the CQ is marked as such.</simpara>
-<simpara>Be advised that this process may take a while. The actual amount of time that it takes
-to process a CQ depends on numerous factors including the size of the queue, and the
-nature and size of the contribution.</simpara>
-</section>
-</section>
-<section xml:id="ip-iplog">
-<title>IP Logs</title>
-<simpara>An IP Log is a record of the intellectual property contributions to a project.
-This includes such as a list of all committers, past and present, that have
-worked on the code and (especially) those who have made contributions to
-the current code base.</simpara>
-<simpara>The IP Log is a big part of the official <link linkend="release">release cycle</link>. You are required to
-submit your project’s IP Log prior to scheduling a release, or restructuring
-review. We encourage you to keep your IP log current rather than rushing at the
-end. The IP Log includes important information about your project that lets
-adopters know where all the code comes from, who owns the copyrights, and so
-forth.</simpara>
-<simpara>Specifically, the log tracks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Licenses;</simpara>
-</listitem>
-<listitem>
-<simpara>Past and present committers;</simpara>
-</listitem>
-<listitem>
-<simpara>Third-party libraries; and</simpara>
-</listitem>
-<listitem>
-<simpara>Contributions from outside the project (i.e. non-committers)</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="ip-iplog-generator">
-<title>IP Log Generator</title>
-<simpara>The Automated IP Log Tool automatically generates an IP Log using information
-that is available to the Eclipse Foundation. The list of committers, for
-example is generated using information provided by the Dash project which itself
-pulls information out of source code repositories.</simpara>
-<simpara>The IP Log generator pulls information from multiple location to assemble the log:</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/ip-log-generator.png"/>
-</imageobject>
-<textobject><phrase>ip log generator</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<itemizedlist>
-<listitem>
-<simpara>Third-party libraries used by the project come from <emphasis>IPZilla</emphasis>;</simpara>
-</listitem>
-<listitem>
-<simpara>The <emphasis>Dash</emphasis> process scans the project source code repositories to assess committer activity;</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Dash</emphasis> also scans Git repositories for contributions;</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If you follow the guidelines for handling Git contributions, contributions received via
-Git in any branch will automatically appear in the log</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Contributions received as patches in <emphasis>Bugzilla</emphasis> that are marked <literal>iplog+</literal>
-will automatically appear in the log; and</simpara>
-</listitem>
-<listitem>
-<simpara>License information is obtained from the <emphasis>Foundation</emphasis> database</simpara>
-</listitem>
-</itemizedlist>
-<simpara>To fully leverage the value of the Automated IP Log Tool, you need to:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Keep your project metadata up-to-date;</simpara>
-</listitem>
-<listitem>
-<simpara>Follow the guidelines for handling Git contributions;</simpara>
-</listitem>
-<listitem>
-<simpara>Mark IP Contributions in Bugzilla; and</simpara>
-</listitem>
-<listitem>
-<simpara>Create <link linkend="ip-cq">contribution questionnaires</link> (CQs) where appropriate</simpara>
-</listitem>
-</itemizedlist>
-<warning>
-<simpara>Contributions should be recorded in <emphasis>one of</emphasis> Git or Bugzilla, not both.
-Setting the <emphasis>Author</emphasis> credentials on Git commits is the preferred mechanism.
-The IP Log generator is not smart enough to detect duplicate entries.</simpara>
-</warning>
-<simpara>Your project’s metadata is used to determine the identities of the source code
-repositories that Dash needs to scan to find out committer information. Specifically,
-you need to specify, in the <emphasis>Source Repositories</emphasis> section, a list of paths to source code
-repository locations.</simpara>
-<simpara>The Automated IP Log tool populates the <emphasis>Contributors</emphasis> section with information gathered
-from Git and Bugzilla. This section lists contributions from non-committers (this is
-time-sensitive, so contributions made by current committers before they became
-committers will also be included). Only non-committer contributions are recorded in
-the generated log.</simpara>
-<simpara><link linkend="resources-commit">Git commits</link> contributed by non-committers are identified by
-the author credentials on the commit record; the <emphasis>Author</emphasis> field must be set to the identity
-of the actual author of the commit.</simpara>
-<simpara>Alternatively, Bugzilla attachments can be marked with the <literal>iplog+</literal> flag.
-This flag setting indicates that the person who attached the bug is the contributor.
-To comply with the website terms of use, the person who attaches
-the contribution <emphasis role="strong">must</emphasis> be the person who has permission to make it available.
-You should ensure that this is the case before including the code in your project’s
-repository and flagging the entry.</simpara>
-<simpara>You can also flag an entire Bugzilla entry with <literal>iplog+</literal>. Doing so,
-however, indicates to the Automated IP Log tool that every single comment made by a non-committer
-in the bug report represents a potential contribution. For your own sanity, it’s a good practice
-to ask contributors to provide and attach patches that can be individually marked. Marking an
-entire bug represents an ongoing maintenance issue as new comments added to the bug from
-non-committers will show up in the generated log.</simpara>
-<simpara>That contributions flagged in Bugzilla will only appear in the IP Log if the bug is marked
-<literal>FIXED</literal> or <literal>CLOSED</literal>.</simpara>
-<simpara>The Third-Party Software section of the log is populated from IPZilla. The IP Team
-will mark your contributions in such a way that they will appear in
-the log. If third party software is not appearing properly, contact the
-<link xlink:href="mailto:emo-ip-team@eclipse.org">EMO IP Team</link> to make corrections.</simpara>
-</section>
-</section>
-<section xml:id="ip-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What do you do with the IP Log? </simpara>
-</question>
-<answer>
-<simpara>IP Log reviews occur in two stages. In the first stage, the EMO performs
-a technical assessment to make sure that the artifacts produced by the
-project are properly accounted for in the IP log. You may be asked to
-assist with the resolution of any discrepancies found during this assessment.
-In the second stage, the IP Team reviews the log to ensure that
-it matches their records. The IP log review concludes with approval by the IP Team.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>When should I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>The IP Log should be submitted for review by the IP Team two weeks before the planned
-end date for a release review or (if code moves are involved) a restructuring review.
-Note that the date of your review may be different from the date of the actual release.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Are there other reasons to submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>Generally no. If the IP Team requires an IP Log review outside of the context of
-a release or restructuring review, they’ll ask for it. It is not generally necessary
-to submit an IP Log for review outside of the context of a review.
-It is, however, good practice to do your own review of the generated
-IP Log periodically to make sure that it accurately reflects the state of the project.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I fix problems with the generated IP Log? </simpara>
-</question>
-<answer>
-<simpara>The IP Log is generated based on data from Eclipse Foundation servers. If the log
-is being generated incorrectly, then the underlying data needs to be fixed. If
-you spot a problem, send a note to <link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="release">
-<title>Releases</title>
-<simpara>Releases are formal for PolarSys projects. They start with planning,
-and end with a community review. You can capture as many future releases as you’d like. It’s
-common practice to specify releases three or six months into the future.</simpara>
-<simpara>Releases are broadly categorized as:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>Major</emphasis> releases include API changes (potential for downstream breakage);</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Minor</emphasis> releases add new functionality, but are API compatible with previous versions; and</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Service</emphasis> releases include bug fixes only and include no significant new functionality.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For all major and minor releases, you must engage in a <emphasis>release review</emphasis>.
-Release reviews are not required for bug-fix/service releases.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/release-cycle.png"/>
-</imageobject>
-<textobject><phrase>The release cycle</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara xml:id="releases-plan">A project plan is <emphasis>required</emphasis> for each major and minor project release.
-The plan should lay out in broad terms what the goals are for the
-release. As plans are a valuable means
-for the community to get involved with your project, the plan should be
-created at the beginning of the release cycle. By establishing the plan
-early, you give prospective contributors help in determining how they
-can most usefully contribute, and adopters can prepare their own
-development schedule and themes. Plans can change during the release
-cycle.</simpara>
-<simpara>Use the <link linkend="pmi">Project Management Interface</link> to create a new release
-record. At the start of the release cycle, your plan should minimally
-include a release number, date, and short description. Think of the
-description as an "elevator pitch": how would you describe the release
-in a fifteen second elevator ride? All aspects of a plan can change
-during the release cycle (including the date). If you do change the plan,
-make sure that the change is communicated via your project’s <emphasis>dev</emphasis> list
-and other project channels.</simpara>
-<simpara>The <emphasis>Plan</emphasis> tab in the release record contains numerous fields for capturing
-plan information. The amount of information that you should capture
-for a release plan varies by top-level project, so consult with your
-Project Management Committee (PMC) for advice.</simpara>
-<simpara>Producing regular builds is an important part of the release cycle.
-Builds are an important means of engaging with the community: adopters can
-help you test your code and test their own so that they can be ready for
-the eventual release. Plan to produce at least one <emphasis>milestone</emphasis> build (more
-are better, depending on the length of your release cycle), and capture
-the planned date for that milestone in the release record. It is also
-common practice to generate nightly and weekly integration builds. Ensure that
-your project’s downloads page provides the information required for the
-community to obtain your builds.</simpara>
-<simpara>All of your project’s <link linkend="ip">intellectual property</link> contributions
-must be approved by the IP Team before you can release
-(this includes third-party libraries and contributions of code to be
-maintained by the project).</simpara>
-<section xml:id="release-review">
-<title>Release Review</title>
-<simpara>A <emphasis>release review</emphasis> is a formal announcement of your release to the
-community and a request for feedback. In practical terms, experience
-has shown that those individuals and organizations who are interested
-in your project follow development throughout the release cycle and so
-are have likely already provided feedback during the development
-cycle (i.e. they are unlikely to provide feedback during the review
-period). With this in mind, the review generally serves as a means for
-a project to engage in a retrospective of the progress made during the
-release, discover areas of potential improvement, demonstrate that the
-project is operating in an open and transparent manner, and ensure that
-the development process and intellectual due diligence processes have
-been followed.</simpara>
-<simpara>Release reviews run for a week and always conclude on a Wednesday.</simpara>
-<note>
-<simpara>We schedule reviews to conclude on the <emphasis>first and
-third Wednesdays of the month</emphasis>. Your release date does not have to
-coincide with the review date (you can set the release date as
-necessary). The review must, however, conclude successfully before you
-can make the release official.</simpara>
-</note>
-<simpara>A <emphasis>release review</emphasis> requires review documentation and an intellectual
-property (IP) log check. The review process must be initiated at least
-two weeks in advance of the anticipated <emphasis>review</emphasis> date.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/release-review.png"/>
-</imageobject>
-<textobject><phrase>Release review work flow</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>Prepare the review documentation well in advance of the start of the
-review period. The release record which contains your project plan
-also includes a <emphasis>Review</emphasis> tab with appropriate fields for a review.
-As with the plan fields, all of the review fields are optional and
-the level of detail you need to provide varies by top-level project.
-You can assemble review information during the release cycle (there’s
-no need to wait until the end)</simpara>
-<simpara>The review materials must be approved by the PMC; send an email to
-the PMC’s mailing list asking for approval. The PMC will respond with
-feedback or a simple "+1" indicating approval.</simpara>
-<note>
-<simpara>Click the handy <emphasis>Send Email to the PMC</emphasis> link under <emphasis>Committer Tools</emphasis>
-on the release record page to connect with the PMC.</simpara>
-</note>
-<simpara>Submit the IP Log for review by the IP Team. The IP Team must approve
-the IP Log before we can schedule the review, so submitting this early
-is important. The <link linkend="ip-iplog-generator">IP Log generator</link> automatically
-collects information based on the information that the project team has
-provided to the IP Team through <link linkend="ip-cq">contribution questionnaires</link>
-in IPZilla, commits in the project’s source code repository, and
-other information in our databases. Carefully review the IP Log before
-submitting to the IP Team for their review.</simpara>
-<note>
-<simpara>Click the handy <emphasis>Generate IP Log</emphasis> link under <emphasis>Committer Tools</emphasis>
-on the release record page to open the IP Log generator.</simpara>
-</note>
-<simpara>The information used to generate an IP Log should always be up-to-date
-(don’t wait until the end of the release cycle to make it right).</simpara>
-<simpara>At any point in this process, you can request that the review be
-initiated by clicking the <emphasis>Schedule a review for this release</emphasis> link
-that appears at the top of the release record page. This will invite you
-to select a review date. You must then follow up with the EMO to approve
-the review.</simpara>
-<note>
-<simpara>The EMO will likely notice that you’ve created the release record,
-connected with your PMC, and submitted an IP Log for review by the IP
-team and will take steps to initiate the actual review. However, since
-there is a great deal of variability in this process, send an email to
-<link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link> stating your intent to release.</simpara>
-</note>
-<simpara>The EMO will conclude the review on the scheduled end date and advise the
-project team of the outcome.</simpara>
-</section>
-<section xml:id="release-graduation">
-<title>Graduation Review</title>
-<simpara>The purpose of a <emphasis>graduation review</emphasis> is to confirm that the project has
-a working and demonstrable code base of sufficiently high quality
-active and sufficiently diverse communities; has adopters, developers, and users
-operating fully in the open following the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>; and
-is a credit to PolarSys and is functioning well within the larger PolarSys community</simpara>
-<simpara>Graduation reviews are generally combined with a <link linkend="release-review"><emphasis>release review</emphasis></link>
-(typically, but not necessarily the <emphasis>1.0</emphasis> release).
-Upon successful completion of a graduation review, a project will leave the
-incubation phase and be designated as a <emphasis>mature</emphasis> project.</simpara>
-<simpara>For a graduation review, release review documentation must be augmented to
-include demonstration of:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>solid working code with stable APIs;</simpara>
-</listitem>
-<listitem>
-<simpara>an established and growing community around the project;</simpara>
-</listitem>
-<listitem>
-<simpara>diverse multi-organization committer/contributor/developer activity; and</simpara>
-</listitem>
-<listitem>
-<simpara>operation in the open using open source rules of engagement.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The graduation review documentation should demonstrate that members have
-learned the ropes and logistics of being a PolarSys project. That is,
-the project "gets the PolarSys way".</simpara>
-</section>
-<section xml:id="release-faq">
-<title>Frequently Asked Questions</title>
-<qandaset>
-<qandaentry>
-<question>
-<simpara>Can a release review fail? </simpara>
-</question>
-<answer>
-<simpara>Technically, yes. A release review can fail. In our history, however, this
-occurrs very rarely. We set up release reviews to succeed.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Do we really need to do this? </simpara>
-</question>
-<answer>
-<simpara>Yes.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How often should we do releases? </simpara>
-</question>
-<answer>
-<simpara>This depends very much on the nature of your project and the expectations
-of your community and stake holders. If you’re not sure, connect with your
-mentors and top-level project for guidance.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How much effort should we put into this? </simpara>
-</question>
-<answer>
-<simpara>The amount of effort varies based on the nature of the team, and
-expectations of the community and stake holders. Generally, though, a project
-team shouldn’t spend more than a couple of hours working directly on the
-formal aspects of the release review.
-If the amount of effort seems too onerous, you may be trying too hard.
-Connect with your project mentors, top-level project’s PMC, or the
-<link xlink:href="mailto:emo@eclipse.org">EMO</link> for guidance.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>Click the <emphasis>Submit</emphasis> button on the <link linkend="ip-iplog-generator">IP Log generator</link>.
-You need to be logged in as project committer to have access to this button.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can I accept contributions after I submit the IP Log for review? </simpara>
-</question>
-<answer>
-<simpara>The short answer is <emphasis>yes</emphasis>. Please do accept contributions.
-If you require a new contribution questionnaire (for either a third
-party library or code contribution) after submitting the IP Log for
-review, please ask the <link xlink:href="mailto:emo-ip-team@eclipse.org">IP Team</link> if
-they want you to resubmit the IP Log.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I obtain PMC approval? </simpara>
-</question>
-<answer>
-<simpara>Send the the PMC a note via the top-level project’s <emphasis>PMC</emphasis> mailing list
-with a link to the release record. Note that the release record page
-has a handy link labeled <emphasis>Send Email the PMC</emphasis> under <emphasis>Committer Tools</emphasis>.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>I need to do a release now. Can you fast-track the review? </simpara>
-</question>
-<answer>
-<simpara>While we do try to be as accommodating as possible, the answer is no.
-We have a well-defined process with predictable dates. Please plan
-accordingly.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>Can a project in the incubation phase do releases? </simpara>
-</question>
-<answer>
-<simpara>Yes. In fact, we encourage projects to do at least one release while
-in incubation phase.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>What restrictions are placed on version names for incubating projects? </simpara>
-</question>
-<answer>
-<simpara>Projects in the incubation phase generally use version numbers that
-are less than 1.0. This is, however, a convention not a rule. If it makes sense
-for you community and adopters to use higher numbers, then do so.
-If you’re not sure, ask your top-level project PMC for advice.</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How do I name/number milestone builds? </simpara>
-</question>
-<answer>
-<simpara>Milestone builds should contain the name/number of the release suffixed
-with "Mn" (e.g. the second milestone for EGit 3.2 may have a file
-named "egit-3.2M2"). Projects in the incubation phase may produce
-milestone builds for their graduation release, e.g "myProject-1.0M2".</simpara>
-</answer>
-</qandaentry>
-<qandaentry>
-<question>
-<simpara>How can I get help? </simpara>
-</question>
-<answer>
-<simpara>Contact your mentors (for projects in the incubation phase), top-level
-project PMC, or the <link xlink:href="mailto:emo@eclipse.org">EMO</link>.</simpara>
-</answer>
-</qandaentry>
-</qandaset>
-</section>
-</chapter>
-<chapter xml:id="pmi">
-<title>Project Management Infrastructure (PMI)</title>
-<simpara>The PolarSys Project Management Infrastructure (PMI) consolidates
-project management activities into a single consistent location and experience.</simpara>
-<simpara>Project Management Infrastructure themes:</simpara>
-<simpara><emphasis>Improved consistency.</emphasis> Configuration/data-driven project web presence,
-direct linkage between releases, reviews, and plans. Information—​including
-basic project metadata, project plans, and release review information—​is
-captured and retained in a consistent (and easily leveraged) data-based
-format (rather than in multiple documents in arbitrary formats).</simpara>
-<simpara><emphasis>All-in-one-place.</emphasis> Project leads and committers are able to edit
-information in place on the project information pages. Text/information in
-one place with links in another is eliminated where possible. Comments and
-discussion related to reviews, elections, etc. are connected directly
-to the item being discussed.</simpara>
-<simpara><emphasis>Get started faster.</emphasis> By default, projects are provided with a data-driven
-website that includes consistent links to project releases, reviews,
-downloads, etc. Projects can opt to override the default and provide
-their own customized web presence. Setting up a project presence is a
-matter of configuration, not PHP programming against proprietary APIs.</simpara>
-<section xml:id="pmi-metadata">
-<title>Project Metadata?</title>
-<simpara>Project committers and project leads are responsible for maintaining
-their project’s metadata. This information is an important part of being
-an Eclipse project.</simpara>
-<simpara>Project metadata is:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Relatively static structural information such as the project
-description and scope, the names of the project’s mailing lists and
-newsgroups, the bugzilla products, source code repositories, etc.</simpara>
-</listitem>
-<listitem>
-<simpara>Historical information such as previous release downloads, release
-review slides and IP logs, etc.</simpara>
-</listitem>
-<listitem>
-<simpara>Status and future looking information such as the project and
-milestone plans, the features scheduled for the current release, release
-dates, etc.</simpara>
-</listitem>
-</orderedlist>
-<simpara>PMC members, and the Eclipse Foundation staff also have the ability to
-make changes on behalf of a project.</simpara>
-</section>
-<section xml:id="pmi-viewing">
-<title>Viewing</title>
-<simpara>The complete listing of all current
-<link xlink:href="http://www.polarsys.org/list-of-projects">PolarSys projects</link> provides
-one starting point for viewing projects. From here, you can link
-directly to a project information page. Navigation options are provided
-to help you move from one project to another.</simpara>
-</section>
-<section xml:id="pmi-commands-and-tools">
-<title>Commands and Tools</title>
-<simpara>Committers have access to several committer-specific
-commands and tools. The selection of commands available are context sensitive; only those
-commands that make sense for the logged in user are shown.</simpara>
-</section>
-<section xml:id="pmi-editing">
-<title>Editing Project Metadata</title>
-<simpara>Committers have the ability to edit the information managed and displayed
-on the project page.
-There are several sections on the page. When you switch the page into
-"Edit" mode, you will be provided with lots of help regarding the
-contents of each of the fields (note that the help text is currently
-rendered below the fields).</simpara>
-<simpara>Some of the fields are described below.</simpara>
-<section xml:id="pmi-description-and-scope">
-<title>Description and Scope</title>
-<simpara>The <emphasis>description</emphasis> should start with a concise paragraph of three to five
-sentences (e.g. suitable for display with a collection of other projects).
-A single paragraph is generally appropriate for the
-description.</simpara>
-<simpara>If more than a single simple paragraph is required to fully
-describe the project, it is possible to set a summary. The summary
-can be specified by toggling the "show summary" link to explicitly
-set a summary apart from the more detailed description, or the top
-part of the description can be designated as the summary by inserting
-a <emphasis>Teaser Break</emphasis> into the content.</simpara>
-<note>
-<simpara>providing a summary gives you control over what will get rendered.
-In views where we are displaying more than one project, the system
-will artifically cut short descriptions that are too long, potentially
-resulting in a description that looks <emphasis>weird</emphasis>.</simpara>
-</note>
-<simpara>The <emphasis>scope</emphasis> is intended for a more select audience; generally speaking the
-scope should be taken directly from the project’s proposal. Project
-members have the ability to change the text of the project scope, but
-should be careful to avoid changing the meaning. If the meaning of the
-scope needs to change, the Project Management Committee (PMC) must be
-contacted regarding a potential restructuring review.</simpara>
-</section>
-<section xml:id="pmi-downloads">
-<title>Downloads</title>
-<simpara>You can provide download information for your project in the "Downloads"
-section.</simpara>
-<simpara>The first entry is the main "Downloads URL". This manifests as a "Big
-Button" Download on the project page. What you put here is left to the
-project team to decide. It can be a link to a webpage, a direct link to
-a file download, or whatever else makes sense the project and community.</simpara>
-<simpara>Optional text can be included along with the "Big
-Button" Download, as well as links to zero or more Eclipse Marketplace,
-update/p2 sites, or other downloads. Each of the links can have an
-optional title (the link itself will be displayed if no title is
-provided). Note that no validation is done on the links to ensure that
-they are meaningful.</simpara>
-</section>
-<section xml:id="source-repositories">
-<title>Source Repositories</title>
-<simpara>The project can specify zero or more <emphasis role="strong">source repositories</emphasis>. These are
-displayed in the "Contribute to this Project" section.</simpara>
-<simpara>The values specified are used to query against a database of known
-existing source repositories (this database is updated nightly by a
-discovery process). Those repositories that are found in the database
-will be displayed with enhanced information (including links to
-repository mirrors, Gerrit, etc.). All values that you provide will be
-displayed, whether they point to real repositories or not. If the
-database does not contain your repository, the PMI will assume that the
-value is correct and try its best to display the information.</simpara>
-<simpara>Repositories should be specified using the file system path, e.g.
-<emphasis>/gitroot/egit/egit.git</emphasis>. The name that is displayed for the repository
-is extracted from the last segment of the URL.</simpara>
-<simpara>If a description file exists in the Git repository, the contents are
-automatically displayed under the repository name.</simpara>
-<note>
-<simpara>The script that we us to identify repositories attempts to identify a
-corresponding Gerrit interface for the repository. If it exists, the
-Gerrit URL is used in place of the Git one. If the repository uses
-Gerrit, then only the Gerrit URL is displayed. Otherwise, the "git://"
-and "ssh://" URLs are displayed.</simpara>
-</note>
-<simpara>You can use wildcards to match multiple repositories, e.g.
-<emphasis>/gitroot/virgo/*</emphasis>. Note that wildcards only work for repositories that
-exist on PolarSys infrastructure (they do not work for GitHub-based
-repositories, for example).</simpara>
-<simpara>Repositories are displayed in the order they are specified. The order
-can be changed in the edit screen by dragging entries into the desired
-order. All wildcard matches are sorted alphabetically by name at the end
-of the list.</simpara>
-<simpara>A <emphasis role="strong">Contribution Message</emphasis> should be provided; it is displayed at
-the top of the section and is one of the primary means by which the
-community will find the project code. Arbitrary text is permitted, but we recommend
-that you limit this content to a single paragraph with a few sentences
-that include a link to more information.</simpara>
-</section>
-<section xml:id="pmi-company-logos">
-<title>Company Logos</title>
-<simpara>Company logos sometimes appear on project pages under the following
-conditions"</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The company must be a <link xlink:href="http://eclipse.org/membership/">member</link> of the
-Eclipse Foundation;</simpara>
-</listitem>
-<listitem>
-<simpara>The company needs to have their logo uploaded to the Portal;</simpara>
-</listitem>
-<listitem>
-<simpara>At least one committer has to be listed as an employee of the company
-in question;</simpara>
-</listitem>
-<listitem>
-<simpara>The committer must be on this project; and</simpara>
-</listitem>
-<listitem>
-<simpara>The committer must be active (must have made at least one commit in
-the last three months)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If all of those conditions are met and the logo is still not showing up,
-then it’s possible that the project meta-data doesn’t have the correct
-source code repository information specified.</simpara>
-</section>
-<section xml:id="pmi-build-technology">
-<title>Build Technology</title>
-<simpara>A project can specify a section of text, links, and a selection of the
-build technologies employed. Specifying this information makes it easier
-for members from the community to understand your build. Links can
-include direct links into the Hudson builds, pages of build
-instructions, or whatever else the project team feels will help the community build
-the project.</simpara>
-</section>
-<section xml:id="pmi-technology-types">
-<title>Technology Types</title>
-<simpara>A project can specify the types of technology produced by the project.
-This is specified in rather broad terms like "OSGi" or "Runtime". The
-various technology types manifest as checkboxes on the edit screen. This
-information is used to form connections between projects to assist in
-navigation and discovery.</simpara>
-<simpara>Clicking on one of the technology types, will take the user
-to a page that lists the projects that produce that particular type of
-technology, along with the summary of their description and project logo
-(if specified).</simpara>
-</section>
-</section>
-<section xml:id="pmi-releases">
-<title>Releases and Reviews</title>
-<simpara>Projects, Releases, and Reviews are presented as separate records. Each
-project record, obviously, represents information about a project. A
-project may have multiple releases; information about the release is
-represented in a release record. The release record also contains some
-review information. This information is included here, because all
-releases do not necessarily have a review (a project can opt to provide
-some <emphasis>review</emphasis> type information as part of a release record. A project
-can have multiple review records; as release reviews are the most common
-form of review, most review records will be joined to a release record.</simpara>
-<informalfigure>
-<mediaobject>
-<imageobject>
-<imagedata fileref="images/ProjectsReleasesReviews.png"/>
-</imageobject>
-<textobject><phrase>Releases and Reviews</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>A review record, however, does not require a release association. Some
-reviews are associated with proposals. Other have no other association
-(e.g. termination reviews).</simpara>
-<simpara>Each <link linkend="release">release</link> has its own record in the database. Records are connected
-directly to a single specific project; a subset of release records
-associated with a project are displayed on the project page. An existing
-release can be edited in much the same was as a project. Any logged in
-project member (committer or project lead) can click the "Edit" button.</simpara>
-<note>
-<simpara>_Create a single record for each release. <emphasis role="strong">Do not create release records
-for milestones.</emphasis> Enter milestone information in the <emphasis>Plan</emphasis> information
-for your release.</simpara>
-</note>
-<simpara>A project lead or committer can create a new release by clicking "Create a new release" under
-"Committer Commands" on the project page. This opens a dialog requesting
-that a date and name be specified. Both of these values can be changed later.</simpara>
-<section xml:id="pmi-release-description">
-<title>Description</title>
-<simpara>Describe the release in the <emphasis>Description</emphasis> section. The description
-should generally be a concise paragraph describing the focus of the
-release (e.g. adding certain functionality, fixing bugs, etc.) in a form
-that is appropriate in an aggregation (e.g. a page that displays the
-release information for all projects participating in an instance of the
-Simultaneous release). The description should provide enough information
-to encourage the reader to click the "find out more" link.</simpara>
-</section>
-<section xml:id="pmi-release-issues">
-<title>Issues</title>
-<simpara>The release record will automatically generate a list of targeted bugs.</simpara>
-<simpara>To populate this list:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Ensure that the Bugzilla Product is set the to correct value in the
-project metadata;</simpara>
-</listitem>
-<listitem>
-<simpara>Set the "target milestones" in Bugzilla need to match the name of your
-release.</simpara>
-</listitem>
-</itemizedlist>
-<note>
-<simpara>The matching algorithm tries to be as forgiving as possible, a release
- named "3.5", "3.5.0", or "3.5 (Luna)" will—​for example—​match target
- milestones named "3.5" ,"3.5M1", "3.5 M2", "3.5.0M3", etc., but will
- not match "3.5.1".</simpara>
-</note>
-<simpara>The bugs for all projects participating in the release will be included.
-Bugs are grouped by Bugzilla product and component.</simpara>
-</section>
-<section xml:id="pmi-release-plan">
-<title>Plan</title>
-<simpara><link linkend="releases-plan">Project plan</link> information belongs in the <emphasis>Plan</emphasis> section. This
-information <emphasis role="strong">should</emphasis> generally be provided early in the development
-cycle to allow the various communities the ability to understand and
-participate in the release. It is expected that the plan will evolve
-over time. Note that all projects are required to provide a plan for
-each major and minor release (plans are not required service releases).</simpara>
-</section>
-<section xml:id="pmi-release-milestones">
-<title>Milestones</title>
-<simpara>Enter the name, date, and optional description for each milestone
-expected with the release.</simpara>
-<simpara>Projects should generally include more than one milestone build with each
-release. To include additional milestones, click the "Add another item"
-button. Note that milestones can be dragged into the desired order. To
-remove a milestone, leave the "Name" field blank.</simpara>
-</section>
-<section xml:id="pmi-review">
-<title>Review</title>
-<simpara>The release has a <link linkend="release-review"><emphasis>Review</emphasis></link> section that can be used to provide
-information for the associated review. If you provide information here,
-the release record itself can be used as review documentation; no
-further documentation is required.</simpara>
-<simpara>Each section on the review page includes a little help to describe the
-sort of information that you should provide.</simpara>
-<simpara>All major and minor releases require a review. Service releases (i.e.
-bug fix releases that do not change public APIs or add new
-functionality) do not require a review.</simpara>
-<simpara>If a release requires a review, you can schedule one by clicking the
-"Schedule a review" button. The drop-down list above the button contains
-several options for review dates. Pick the one that works best for you.</simpara>
-<simpara>Note that this form will not appear if a review has already been
-scheduled, or the release date does not provide enough time to run a
-review (or is in the past). If a review has been scheduled, a link to
-the review will appear.</simpara>
-<simpara>You can edit the review document, but there’s really not all that much
-to edit. A free-form text field is available and can be used if there is
-some need to provide review-specific information that might not
-otherwise be an appropriate part of the release record. <emphasis>This field is
-intended for other types of review (e.g. restructuring or termination
-reviews); we decided to leave it available for release reviews for cases
-in which it might be useful rather than suppress it.</emphasis></simpara>
-<simpara>When the review is displayed, it automatically includes the <emphasis>review</emphasis>
-information from the release record; it shows the review-specific
-information at the top of the page, and includes the <emphasis>review</emphasis>
-information from the release as the rest of the page contents.</simpara>
-<simpara>This can make things a bit confusing when you want to make changes to
-the metadata for a review record. Just remember that the <emphasis>review</emphasis>
-information for a release is stored in the release record.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="glossary">
-<title>Glossary</title>
-<glossentry>
-<glossterm>Architecture Council </glossterm>
-<glossdef>
-<simpara>The Eclipse Architecture Council (AC) serves the community by identifying and
-tackling any issues that hinder Eclipse’s continued technological success and
-innovation, widespread adoption, and future growth. This involves technical
-architecture as well as open source processes and social aspects. Comprising
-the finest technical leaders from all community stake holders, it is the council’s
-goal to keep the projects successful and healthy, the processes simple and smooth,
-and the communities vibrant and cohesive.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Architecture Council Mentor </glossterm>
-<glossdef>
-<simpara>The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers.
-All new projects are required to have a minimum of two mentors taken from the ranks
-of the AC. Your project mentors will help you find answers to any questions you may
-have about the Eclipse Development Process and life-in-general within the Eclipse
-community. If your mentor doesn’t have an answer to your question, they can draw
-on the wisdom of the full AC and the EMO.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Board of Directors </glossterm>
-<glossdef>
-<simpara>The business and technical affairs of the Eclipse
-Foundation are managed by or under the direction of the Board of Directors
-(or more simply, "The Board").</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Committer </glossterm>
-<glossdef>
-<simpara>A committer is a software developer who has the necessary rights to write code
-into the project’s source code repository. Committers are responsible for ensuring
-that all code that gets written into the project’s source code repository is of
-sufficient quality. Further, they must ensure that all code written to an
-PolarSys source code repository is clean from an intellectual property point
-of view. This is discussed with more detail below.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Community </glossterm>
-<glossdef>
-<simpara>Community is a nebulous sort of term. Community is the group of individuals and
-organizations that gather around your project. In the case of some projects, the community
-is enormous. Other projects have smaller communities. Developing a
-community is a very important part of being a PolarSys project as it is from the
-community that you get feedback, contributions, fresh ideas, and ultimately new
-committers to help you implement your shared vision.
-The <emphasis>PolarSys Community</emphasis> is formed from the union of the communities that grow
-around individual projects.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Contribution Questionnaire </glossterm>
-<glossdef>
-<simpara>Prior to committing a significant contribution of content from a non-committer
-to a PolarSys project, the committer must fill out a <link linkend="ip-cq">contribution questionnaire</link> (CQ) and
-submit it to the IP Team for approval. In addition to the
-EMO, the relevant PMC must also provide a technical review and approval of the contribution.
-In general, ongoing development by project committers does not require EMO or PMC approval.
-When in doubt, consult the <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">Eclipse IP Due Diligence Process</link>.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Contributor </glossterm>
-<glossdef>
-<simpara>A contributor is anybody who makes contributions to the project. Contributions
-generally take the form of code patches, but may take other forms like comments
-on issues, additions to the documentation, answers to questions in forums, and
-more.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Dash Process </glossterm>
-<glossdef>
-<simpara>The Dash Process, or simply <emphasis>Dash</emphasis>, is a collection of scripts and processes that
-harvest project data for dissemination in charts, <link linkend="ip-iplog">IP Logs</link>, and more.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Dev-list </glossterm>
-<glossdef>
-<simpara>Every project has a <emphasis>development list</emphasis> or <emphasis>dev-list</emphasis>. All project
-committers must subscribe to the list. The dev-list should be the primary means
-of communication between project committers and is the means throuh which the
-Eclipse Foundation’s automated systems communicate with the project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Ecosystem </glossterm>
-<glossdef>
-<simpara>A commercial ecosystem is a system in which companies, organizations, and individuals
-all work together for mutual benefit. There already exists a vast ecosystem of companies
-that base significant parts of their business on PolarSys technology. This takes the
-form of including PolarSys code in products, providing support, and other services.
-You become part of an eco-system by filling the needs of commercial interests, being
-open and transparent, and being responsive to feedback.
-Ultimately, being part of a commercial ecosystem is a great way to ensure the
-longevity of your project: companies that build their business around your project
-are very motivated to contribute to your project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Eclipse </glossterm>
-<glossdef>
-<simpara>Now this is a tough one. For most people in the broader community, "Eclipse" refers to a
-Java IDE based on the JDT project and assembled by the Eclipse Packaging Project. However,
-the term "Eclipse" is also used to refer to the Eclipse Foundation, the eclipse.org website,
-the community, the eco-system, and—​of course—​The Eclipse Project (which is just one of
-the top-level projects hosted by the Eclipse Foundation). Confusing? Yes.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO </glossterm>
-<glossdef>
-<simpara>The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Architecture and Planning
-Councils. The EMO is responsible for providing services to the projects, facilitating
-project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse
-Development Process. The best method of contact with the EMO is by email (<link xlink:href="mailto:emo@eclipse.org">emo@eclipse.org</link>).
-If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO Executive Director </glossterm>
-<glossdef>
-<simpara>The EMO Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. He is
-ultimately responsible for all the goings-on at the Eclipse Foundation.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO IP Team </glossterm>
-<glossdef>
-<simpara>The EMO Intellectual Property Team (commonly referred to
-as the <emphasis>IP Team</emphasis>) is responsible for implementing the intellectual
-property policy of the Eclipse Foundation.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>EMO Records </glossterm>
-<glossdef>
-<simpara>The EMO Records Team (commonly referred to as <emphasis>EMO Records</emphasis>) is
-responsible for managing committer paperwork and other records
-on behalf of the Eclipse Foundation. Contact the EMO Records team via email
-(<link xlink:href="mailto:emo-records@eclipse.org">emo-records@eclipse.org</link>).</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Incubation Phase </glossterm>
-<glossdef>
-<simpara>The purpose of the incubation phase is to establish a fully-functioning open-source project.
-In this context, incubation is about developing the process, the community, and the technology.
-Incubation is a phase rather than a place: new projects may be incubated under any existing project.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>IP Due Diligence Process </glossterm>
-<glossdef>
-<simpara>The <link xlink:href="http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf">Intellectual Property Due Diligence Process</link> defines the process by which
-intellectual property is added to a project. All PolarSys committers must be familiar
-with this process.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>IP Log </glossterm>
-<glossdef>
-<simpara>An <link linkend="ip-iplog">IP Log</link> is a record of the intellectual property (IP) contributions to a project.
-This includes such as a list of all committers, past and present, that have worked on the
-code and (especially) those who have made contributions to the current code base.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Member Company </glossterm>
-<glossdef>
-<simpara>The Eclipse Foundation and Eclipse community is supported by our member organizations.
-Through this support, the Eclipse Foundation provides the open source community
-with IT, Intellectual Property, Mentors and Marketing services.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Parallel IP </glossterm>
-<glossdef>
-<simpara>The <link linkend="ip-parallel-ip">Parallel IP Process</link> allows a PolarSys projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Planning Council </glossterm>
-<glossdef>
-<simpara>The Planning Council is responsible for cross-project planning, architectural issues,
-user interface conflicts, and all other coordination and integration issues. The Planning
-Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Project</glossterm>
-<glossdef>
-<simpara>Projects are where the real work happens. Each project has code, committers,
-and resources including a web site, source code repositories, space on the build
-and download server, etc. Projects may act as a parent for one or more child
-projects. Each child project has its own identity, committers, and resource.
-Projects may, but do not necessarily, have a dedicated web site. Projects are sometimes referred
-to as <emphasis>subprojects</emphasis> or as <emphasis>components</emphasis>. The Eclipse Development Process, however,
-treats the terms project, subproject, and component as equivalent.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Project Lead </glossterm>
-<glossdef>
-<simpara>The project lead is more of a position of responsibility than one of power. The
-project lead is immediately responsible for the overall well-being of the project.
-They own and manage the project’s development process, coordinate development,
-facilitate discussion among project committers, ensure that the Eclipse IP
-policy is being observed by the project and more. If you have questions about
-your project, the <link xlink:href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Development Process</link>, or anything else, ask
-your project lead.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>PMC </glossterm>
-<glossdef>
-<simpara>Each top-level project is governed by a Project Management Committee (PMC). The
-PMC has one or more leads along with several members. The PMC has numerous
-responsibilities, including the ultimate approval of committer elections, and
-approval of intellectual property contributions. Effectively, the PMC provides
-oversight for each of the projects that are part of the top-level project.
-If you have a question that your project lead cannot
-answer, ask the PMC.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>PMI </glossterm>
-<glossdef>
-<simpara>The Project Management Interface (PMI) is the system that tracks the state
-and progress of PolarSys projects. Project committers can modify the the
-information represented in the PMI, including the project description, and
-information about project releases. Automated systems use this information
-to, for example, generate dashboard and chart information for the project,
-intellectual property logs, etc.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Top-Level Project </glossterm>
-<glossdef>
-<simpara>A top-level project (sometimes referred to as a <emphasis>TLP</emphasis>) is effectively a
-container for projects that do the real work.
-A top-level project does not generally contain code; rather, a top-level project contains
-other projects. Each top-level project defines a charter that, among other
-things defines a scope for the types of projects that it contains. Top-level
-projects are managed by a Project Management Committee.</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Webmaster </glossterm>
-<glossdef>
-<simpara>The Webmaster team is responsible for maintaining the IT infrastructure
-of the Eclipse Foundation and the PolarSys forge. You can contact the
-Webmaster team directly via email (<link xlink:href="mailto:webmaster@eclipse.org">webmaster@eclipse.org</link>).</simpara>
-</glossdef>
-</glossentry>
-<glossentry>
-<glossterm>Working Group </glossterm>
-<glossdef>
-<simpara>Eclipse <link xlink:href="https://www.eclipse.org/org/workinggroups">Working Groups</link> provide
-a vendor-neutral governance structure that allow organizations to freely
-collaborate on new technology development.</simpara>
-</glossdef>
-</glossentry>
-</chapter>
-<chapter xml:id="contact">
-<title>Getting Help</title>
-<simpara>If you have any questions, or are unsure of your responsibilities as a
-project lead or committer, please contact your project mentors or
-<link xlink:href="mailto:emo@eclipse.org">EMO</link>.</simpara>
-</chapter>
-</book>
\ No newline at end of file
diff --git a/handbook/polarsys.pdf b/handbook/polarsys.pdf
deleted file mode 100644
index f075c2f..0000000
--- a/handbook/polarsys.pdf
+++ /dev/null
Binary files differ
diff --git a/handbook/source/chapters/community.adoc b/handbook/source/chapters/community.adoc
deleted file mode 100644
index d9be563..0000000
--- a/handbook/source/chapters/community.adoc
+++ /dev/null
@@ -1,142 +0,0 @@
-[[community]]
-Community
----------
-
-The Eclipse Development Process is mostly concerned with engaging in
-activities that grow community involvement. An Eclipse project is
-considered successful only if a vibrant community develops around it
-and the project team grows in diversity.
-
-While the reviews and processes described by the EDP may seem onerous,
-they are a necessary part of community development. You should
-anticipate spending a significant amount of time responding to questions
-posed in various forums ({forumsUrl}[{forgeName} Forums],
-{mailingListsUrl}[mailing lists], and other places where your community
-gathers. You should plan on attending conferences, presenting webinars,
-writing papers, and more to support your project.
-
-Community and Eco-system development are two things that every committer
-should spend at least some time thinking about, and—hopefully—some time
-doing something about. Ultimately, it is difficult to call your project
-a success without these things. It is from the community and eco-system
-that you will draw additional contributions and other helpful input to
-make your open source project a success.
-
-[[community-barriers]]
-Lower the Barriers
-~~~~~~~~~~~~~~~~~~
-
-One of the most critical aspects of running an open source project is
-to grow user and adopter communities, invite contributions, and increase
-committer diversity. All {forgeName} projects must work to 'lower the
-barrier of entry'.
-
-To attract and support contributors:
-
-* Make it easy for contributors to find is the code, build it, and run tests;
-* Describe and disseminate the contribution process;
-* Maintain an open and transparent schedule of builds, milestones, releases, etc.;
-* Capture important decisions in public forums and invite participation (be transparent and open); and
-* Consider implementing a weekly phone call where you can discuss the schedule,
-the on-going work, and also the more complex/controversial technical things
-which would have not been easy to take care of by email.
-
-When somebody does show up to do some work on your project, help them be
-successful.
-
-To attact and support users:
-
-* Maintain a concise and clear description of the project on the website;
-* Provide a five minute tutorial to help users understand what the project
-does and why they should care;
-* Make sure that they know where they can go to get answers to their questions
-(e.g. a project forum); and
-* Provide great documentation, with a lot of ready-to-go examples.
-
-Include support for the website, and regular updates to your project documentation
-and tutorials as part of your project planning.
-
-[[community-forums]]
-Forums
-~~~~~~
-
-It is through {forumsUrl}[forums] that adopters tend communicate with a project.
-Very often, it is the only real support channel provided for those
-adopters.
-
-ifeval::["{forgeName}"=="Eclipse"]
-NOTE: Each project should have at least one committer monitor
-{forumsUrl}/eclipse.newcomer[eclipse.newcomer] to catch
-questions posed there and further extend the awareness of the project.
-endif::[]
-
-When your community asks questions, answer them as soon as possible. No
-question should go unanswered. Encourage all of the project committers
-to monitor the project forum(s), or--at very least--take turns.
-When sensible, incorporate the answers into the FAQ or some type of wiki
-recipe. Repeat this process for as many newsgroups as possible,
-because Eclipse's overall success will be
-reflected in your personal success. Your dedication to high-quality
-service and support is the fuel for your ecosystem and the success of
-that ecosystem is the most effective way to achieve maximum influence
-with your limited individual capacity.
-
-Adopter questions posed in developer mailing lists (and other
-'inappropriate' forums such as personal e-mail) should be answered
-politely. It is reasonable to recommend that the question (or future
-questions) be posed in the forum where it can be 'viewed by a larger
-audience as is more likely to receive a timely answer'.
-
-Avoid negativity, swearing, belittling, or other disparaging behaviour
-in your responses.
-
-All of the answers don't need to necessarily come from project
-committers: empower your community to answer questions in the newsgroup.
-When community members do provide answers that require further
-clarification (either they are not complete, or are not 100% correct),
-do so politely.
-
-The more welcome you make your community feel, the more likely it is
-that your project will be successful.
-
-[[community-bugzilla]]
-Bugzilla
-~~~~~~~~
-
-When your community reports a problem, fix it as soon as possible. Be
-sure to make a distinction between wish list items (I want more
-goodness) and actual defects (it's broken because it's not working the
-way it was designed to work). A list of 1,000 bugzillas that looks to the
-community like a list of 1,000 defects rather than like a list of 1,000
-wishes is bad publicity. Having 'no responses' in most of those reports,
-is also bad news. Your community will interpret it as a lack of respect,
-and no pleas about your lack of resource will help offset that negative
-perception.
-
-Ideally, every commit in your project's source code repository should have a
-corresponding Bugzilla record. Provide linkage to the record in the
-commit comment so that somebody browsing the history of your code can
-follow the links to find any discussion, or other useful information
-related to that commit. Consider including bug numbers directly in
-comments in the source code when the discussion contained in that bug is
-particularly useful. This will help your community and committers better
-understand why your code is implemented the way it is and give them a
-pre-existing place (i.e. the bug) to pose further questions.
-
-[[signs-of-success]]
-Signs of success
-~~~~~~~~~~~~~~~~
-
-Ultimately, everything above is about making it possible for a community
-to find out about your project and provide opportunity to get involved.
-Providing that opportunity is one thing, actually attracting a community
-is another.
-
-You are successful if (not an exclusive list):
-
-* A significant number of bugs raised against your project come from
-non-committers;
-* Non-committers are blogging about your project;
-* Articles, presentations, podcasts, webinars, etc. are being developed
-and presented by non-committers; and/or
-* You cease to be the center of the universe for your project.
diff --git a/handbook/source/chapters/contact.adoc b/handbook/source/chapters/contact.adoc
deleted file mode 100644
index 4895e17..0000000
--- a/handbook/source/chapters/contact.adoc
+++ /dev/null
@@ -1,7 +0,0 @@
-[[contact]]
-Getting Help
-------------
-
-If you have any questions, or are unsure of your responsibilities as a
-project lead or committer, please contact your project mentors or
-mailto:{emoEmail}[EMO].
diff --git a/handbook/source/chapters/elections.adoc b/handbook/source/chapters/elections.adoc
deleted file mode 100644
index a8372e3..0000000
--- a/handbook/source/chapters/elections.adoc
+++ /dev/null
@@ -1,104 +0,0 @@
-[[elections]]
-Elections
----------
-Roles in a project are assigned based on merit demonstrated in a
-publicly-accessible forum, in the form of an election. Elections
-start with a nomination that contains a statement of merit. The nature
-of a statement of merit varies widely, but is generally expected to
-to concisely state the impact that the nominee has had on the
-project.
-
-NOTE: Employment status has no bearing at whether or not somebody can participate
-in an open source project at {forgeName}. Employment does not, for example, guarantee
-committer status; committer status must be earned by everybody.
-
-[[elections-committer]]
-Committer Elections
-~~~~~~~~~~~~~~~~~~~
-A committer election starts with a statement of merit for the nominee.
-The statement of merit should, for example, include links to contributions
-made by the nominee (e.g. Git commits, Gerrit reviews, pull requests,
-or Bugzilla records).
-
-Use the {developerPortalUrl}[developer portal] to elect a committer.
-
-Only project committers may vote in a committer election. To be successful,
-the election must receive a minimum of three positive +pass:[+1]+ votes.
-Any committer can veto the election by casting a +pass:[-1]+ vote. For projects
-with three or fewer committers all committers must vote. Committer elections
-run for one week, but will end prematurely if all
-project committers vote +pass:[+1]+.
-
-Following a successful committer vote, the project's PMC will review
-the election results and then either approve or veto the election.
-An election may be vetoed, for example, if the PMC feels that the
-merit statement is not strong enough.
-
-The <<paperwork, paperwork>> process will automatically be initiated following
-PMC approval of an election.
-
-[[elections-pl]]
-Project Lead Elections
-~~~~~~~~~~~~~~~~~~~~~~
-Similar to a committer election, a project lead election starts with a
-statement of merit. The merit statement should, rather than focus on
-specific code contributions, focus instad on the leadership qualities
-expressed by the individual.
-
-.Project Lead merit statement
-=====================================================================
-Sounak has been part of the Ogee development since before the initial
-contribution. He played an important role ever since, as he is one of the key
-developers. With regards to the number of commits Sounak is currently the top
-committer of Ogee:
-http://git.eclipse.org/c/ogee/org.eclipse.ogee.git/stats/?period=q&ofs=10
-Apart from that Sounak took care of the project page and the build. For
-release 0.6 he also handled the review formalities for me. Finally I would
-like to mention a blog post he did at odata.org to promote Ogee in the OData
-community:
-http://www.odata.org/blog/eclipse-ogee
-=====================================================================
-
-Project leads are normally also committers. A project may have more than one
-project lead (so-called 'co-leads').
-
-Use the 'Nominate a Project Lead' link in the 'Committer Tools' block on the
-project's <<pmi,management page>> to start a project lead election.
-
-Only project committers can vote in a project lead election.
-To be successful, a project lead election must receive a minimum of three
-positive +pass:[+1]+ votes. Any committer can veto the election by
-casting a +pass:[-1]+ vote. For projects with three or fewer committers
-all committers must vote. Committer elections run for one week, but will
-end prematurely if all project committers vote +pass:[+1]+.
-
-Following a successful committer vote, the project's PMC will review
-the election results and then either approve or veto the election.
-A PMC-approved election will be referred to the EMO/ED as a recommendation
-for appointment. The final decision rests with the EMO/ED.
-
-[[elections-pmc-member]]
-PMC Member Elections
-~~~~~~~~~~~~~~~~~~~~
-The manner in which a top-level project's Project Management Committee
-(PMC) 'Member' is appointed varies by PMC. Some PMCs are set up to have a
-representative from each of the projects in the top-level project. Other
-PMCs are more exclusive and run an election similar to that of a project
-lead election.
-
-In all cases, the PMC Lead makes a recommendation to the EMO/ED to appoint
-a PMC Member. The final decision rests with the EMO/ED.
-
-[[elections-pmc-lead]]
-PMC Lead Appointments
-~~~~~~~~~~~~~~~~~~~~~
-PMC 'Leads' are are not elected. They are vetted by the EMO, approved by
-the Eclipse Board of Directors, and appointed by the EMO/ED.
-
-[[elections-faq]]
-Frequently Asked Questions
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-[qanda]
-Do we really need to do this? ::
- Yes.
diff --git a/handbook/source/chapters/glossary.adoc b/handbook/source/chapters/glossary.adoc
deleted file mode 100644
index d9a1ec2..0000000
--- a/handbook/source/chapters/glossary.adoc
+++ /dev/null
@@ -1,191 +0,0 @@
-[[glossary]]
-Glossary
---------
-
-[glossary]
-Architecture Council ::
- The Eclipse Architecture Council (AC) serves the community by identifying and
- tackling any issues that hinder Eclipse's continued technological success and
- innovation, widespread adoption, and future growth. This involves technical
- architecture as well as open source processes and social aspects. Comprising
- the finest technical leaders from all community stake holders, it is the council's
- goal to keep the projects successful and healthy, the processes simple and smooth,
- and the communities vibrant and cohesive.
-
-Architecture Council Mentor ::
- The Eclipse Architecture Council (AC) is a body of battle-hardened Eclipse committers.
- All new projects are required to have a minimum of two mentors taken from the ranks
- of the AC. Your project mentors will help you find answers to any questions you may
- have about the Eclipse Development Process and life-in-general within the Eclipse
- community. If your mentor doesn't have an answer to your question, they can draw
- on the wisdom of the full AC and the EMO.
-
-Board of Directors ::
- The business and technical affairs of the Eclipse
- Foundation are managed by or under the direction of the Board of Directors
- (or more simply, "The Board").
-
-Committer ::
- A committer is a software developer who has the necessary rights to write code
- into the project's source code repository. Committers are responsible for ensuring
- that all code that gets written into the project's source code repository is of
- sufficient quality. Further, they must ensure that all code written to an
- {forgeName} source code repository is clean from an intellectual property point
- of view. This is discussed with more detail below.
-
-Community ::
- Community is a nebulous sort of term. Community is the group of individuals and
- organizations that gather around your project. In the case of some projects, the community
- is enormous. Other projects have smaller communities. Developing a
- community is a very important part of being {aForgeName} project as it is from the
- community that you get feedback, contributions, fresh ideas, and ultimately new
- committers to help you implement your shared vision.
- The '{forgeName} Community' is formed from the union of the communities that grow
- around individual projects.
-
-Contribution Questionnaire ::
- Prior to committing a significant contribution of content from a non-committer
- to {aforgeName} project, the committer must fill out a <<ip-cq,contribution questionnaire>> (CQ) and
- submit it to the IP Team for approval. In addition to the
- EMO, the relevant PMC must also provide a technical review and approval of the contribution.
- In general, ongoing development by project committers does not require EMO or PMC approval.
- When in doubt, consult the {ipDueDiligenceUrl}[Eclipse IP Due Diligence Process].
-
-Contributor ::
- A contributor is anybody who makes contributions to the project. Contributions
- generally take the form of code patches, but may take other forms like comments
- on issues, additions to the documentation, answers to questions in forums, and
- more.
-
-Dash Process ::
- The Dash Process, or simply _Dash_, is a collection of scripts and processes that
- harvest project data for dissemination in charts, <<ip-iplog,IP Logs>>, and more.
-
-Dev-list ::
- Every project has a 'development list' or 'dev-list'. All project
- committers must subscribe to the list. The dev-list should be the primary means
- of communication between project committers and is the means throuh which the
- Eclipse Foundation's automated systems communicate with the project.
-
-Ecosystem ::
- A commercial ecosystem is a system in which companies, organizations, and individuals
- all work together for mutual benefit. There already exists a vast ecosystem of companies
- that base significant parts of their business on {forgeName} technology. This takes the
- form of including {forgeName} code in products, providing support, and other services.
- You become part of an eco-system by filling the needs of commercial interests, being
- open and transparent, and being responsive to feedback.
- Ultimately, being part of a commercial ecosystem is a great way to ensure the
- longevity of your project: companies that build their business around your project
- are very motivated to contribute to your project.
-
-Eclipse ::
- Now this is a tough one. For most people in the broader community, "Eclipse" refers to a
- Java IDE based on the JDT project and assembled by the Eclipse Packaging Project. However,
- the term "Eclipse" is also used to refer to the Eclipse Foundation, the eclipse.org website,
- the community, the eco-system, and--of course--The Eclipse Project (which is just one of
- the top-level projects hosted by the Eclipse Foundation). Confusing? Yes.
-
-EMO ::
- The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Architecture and Planning
- Councils. The EMO is responsible for providing services to the projects, facilitating
- project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse
- Development Process. The best method of contact with the EMO is by email ({emoEmail}).
- If you have a question that cannot be answered by project lead, mentor, or PMC, ask the EMO.
-
-EMO Executive Director ::
- The EMO Executive Director (EMO/ED) is the head-honcho at the Eclipse Foundation. He is
- ultimately responsible for all the goings-on at the Eclipse Foundation.
-
-EMO IP Team ::
- The EMO Intellectual Property Team (commonly referred to
- as the 'IP Team') is responsible for implementing the intellectual
- property policy of the Eclipse Foundation.
-
-EMO Records ::
- The EMO Records Team (commonly referred to as 'EMO Records') is
- responsible for managing committer paperwork and other records
- on behalf of the Eclipse Foundation. Contact the EMO Records team via email
- ({emoRecordsEmail}).
-
-Incubation Phase ::
- The purpose of the incubation phase is to establish a fully-functioning open-source project.
- In this context, incubation is about developing the process, the community, and the technology.
- Incubation is a phase rather than a place: new projects may be incubated under any existing project.
-
-IP Due Diligence Process ::
- The {ipDueDiligenceUrl}[Intellectual Property Due Diligence Process] defines the process by which
- intellectual property is added to a project. All {forgeName} committers must be familiar
- with this process.
-
-IP Log ::
- An <<ip-iplog,IP Log>> is a record of the intellectual property (IP) contributions to a project.
- This includes such as a list of all committers, past and present, that have worked on the
- code and (especially) those who have made contributions to the current code base.
-
-Member Company ::
- The Eclipse Foundation and Eclipse community is supported by our member organizations.
- Through this support, the Eclipse Foundation provides the open source community
- with IT, Intellectual Property, Mentors and Marketing services.
-
-Parallel IP ::
- The <<ip-parallel-ip,Parallel IP Process>> allows {aForgeName} projects to make use of
- project code contributions and third-party libraries before they
- are fully approved by the IP Team.
-
-Planning Council ::
- The Planning Council is responsible for cross-project planning, architectural issues,
- user interface conflicts, and all other coordination and integration issues. The Planning
- Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.
-
-Project::
- Projects are where the real work happens. Each project has code, committers,
- and resources including a web site, source code repositories, space on the build
- and download server, etc. Projects may act as a parent for one or more child
- projects. Each child project has its own identity, committers, and resource.
- Projects may, but do not necessarily, have a dedicated web site. Projects are sometimes referred
- to as 'subprojects' or as 'components'. The Eclipse Development Process, however,
- treats the terms project, subproject, and component as equivalent.
-
-Project Lead ::
- The project lead is more of a position of responsibility than one of power. The
- project lead is immediately responsible for the overall well-being of the project.
- They own and manage the project's development process, coordinate development,
- facilitate discussion among project committers, ensure that the Eclipse IP
- policy is being observed by the project and more. If you have questions about
- your project, the {edpUrl}[Eclipse Development Process], or anything else, ask
- your project lead.
-
-PMC ::
- Each top-level project is governed by a Project Management Committee (PMC). The
- PMC has one or more leads along with several members. The PMC has numerous
- responsibilities, including the ultimate approval of committer elections, and
- approval of intellectual property contributions. Effectively, the PMC provides
- oversight for each of the projects that are part of the top-level project.
- If you have a question that your project lead cannot
- answer, ask the PMC.
-
-PMI ::
- The Project Management Interface (PMI) is the system that tracks the state
- and progress of {forgeName} projects. Project committers can modify the the
- information represented in the PMI, including the project description, and
- information about project releases. Automated systems use this information
- to, for example, generate dashboard and chart information for the project,
- intellectual property logs, etc.
-
-Top-Level Project ::
- A top-level project (sometimes referred to as a 'TLP') is effectively a
- container for projects that do the real work.
- A top-level project does not generally contain code; rather, a top-level project contains
- other projects. Each top-level project defines a charter that, among other
- things defines a scope for the types of projects that it contains. Top-level
- projects are managed by a Project Management Committee.
-
-Webmaster ::
- The Webmaster team is responsible for maintaining the IT infrastructure
- of the Eclipse Foundation and the {forgeName} forge. You can contact the
- Webmaster team directly via email ({webmasterEmail}).
-
-Working Group ::
- Eclipse https://www.eclipse.org/org/workinggroups[Working Groups] provide
- a vendor-neutral governance structure that allow organizations to freely
- collaborate on new technology development.
diff --git a/handbook/source/chapters/ip.adoc b/handbook/source/chapters/ip.adoc
deleted file mode 100644
index d55fd57..0000000
--- a/handbook/source/chapters/ip.adoc
+++ /dev/null
@@ -1,374 +0,0 @@
-[[ip]]
-Intellectual Property
----------------------
-
-{forgeName} projects are expected to take necessary precautions to mitigate
-intellectual property (IP) risk to adopters. A company that integrates the code
-from your project, for example, does so with confidence that the code in the
-project can legally be distributed under the agreed-to terms. The
-{ipDueDiligenceUrl}[IP Due Diligence Process], managed by the Eclipse IP Team
-(commonly referred to as the 'IP Team'), is in place to support this.
-
-All {forgeName} committers must be familiar with the {ipPolicyUrl}[Eclipse IP
-Policy].
-
-[[ip-initial-contribution]]
-Initial Contribution
-~~~~~~~~~~~~~~~~~~~~
-Code provenance tracking is critical (we need to know the source of all code
-that ends up in our repositories). To that end, all new projects are required to
-make an 'initial contribution' before *any* code is committed to a project's
-source code repository.
-
-The IP Team will review your initial contribution to ensure that the code can
-distributed through {aForgeName} property. The IP Team will review the code to
-make sure that it hasn't been copied inappropriately, that licenses are being
-used correctly, and so forth. As part of this process, the IP Team will
-research the source of all code; depending on the size of the contribution, this
-can be a time-consuming process.
-
-NOTE: A project cannot make a <<release, release>> until the due diligence on
-the IP contained in that release--including project code contributions and
-third-party libraries--is complete.
-
-Create a <<ip-cq,contribution questionnaire>> to submit the initial contribution
-for review by the IP Team.
-
-The IP Team is not able to review the history of project code being moved to
-{aForgeName} project. The IP Team will review a snapshot of the project code and
-that snapshot, the 'initial contribution', must be the first commit in the
-{forgeName} repository. If your project uses an existing GitHub repository, the
-Webmaster team will help you obscure the the history into a hidden branch.
-
-[[ip-project-code]]
-Project Code Contributions
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Some contributions of code to maintained by the project (i.e. committed to a
-project source code repository and maintained by the project team) must be
-reviewed by the IP Team. The {ipDueDiligenceUrl}[IP Due Diligence Process]
-provides help to determine whether or not the contribution needs to be reviewed
-by the IP Team. If you're not sure, ask your project mentors or your PMC for
-assistance.
-
-All contributions of project code must be tracked in the project's
-<<ip-iplog,IP Log>>.
-
-Create a <<ip-cq,contribution questionnaire>> to submit a project code
-contribution for review by the IP Team.
-
-[[ip-third-party]]
-Third-Party Libraries
-~~~~~~~~~~~~~~~~~~~~~
-
-All third-party libraries required by project code will have to be checked
-and approved by the IP Team.
-
-The IP Team must review a third-party library if:
-
-* the Java/OSGi manifest for one of the project bundles makes a
-direct reference to a third-party library (either the library bundle
-or a package from the library);
-* project code includes an import statement for a package from a
-third-party library;
-* project code uses reflection or other means to reference a
-library's APIs and implementation;
-* project code uses OSGi Services to make a reference to a
-specific implementation of a service; or
-* project code invokes a "command line" tool.
-
-This list is not intended to be exhaustive.
-
-The {ipThirdParty}[Guidelines for the Review of Third Party Dependencies] can help
-you determine how to classify your third-party libraries.
-
-NOTE: A project cannot make a <<release, release>> until the due diligence on
-the IP contained in that release--including project code contributions and
-third-party libraries--is complete.
-
-Create a <<ip-cq,contribution questionnaire>> to submit a third-party
-library for review by the IP Team.
-
-[[ip-ownership]]
-Ownership
-~~~~~~~~~
-
-The author of a contribution (or their employer) retains ownership of the
-intellectual property contained in the contribution. As part of the contribution
-process, the contributor licenses their contribution under the project license.
-
-[[ip-copyright-headers]]
-Copyright and License Headers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-All source files must include a file header that describes the copyright and
-license terms of the software.
-
-.Example Copyright and License Header
------------------------------------------------------------------
-/*******************************************************************************
- * Copyright (c) 2015 Schmedly Inc. and others. <1>
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html <2>
- *
- * Contributors:
- * Wayne Beaton - initial API and implementation <3>
- *******************************************************************************/
------------------------------------------------------------------
-<1> Name the initial copyright owner; this must be a legal entity (e.g. a company or individual).
-If other organizations have contributed, include "and others".
-<2> List project licenses.
-<3> Optionally list the names of the contributors and the nature of their contribution.
-
-Your project is not a legal entity and so it is inappropriate to list it as
-the copyright owner.
-
-WARNING: The copyright owner is either an individual or their employer. Most
-employment contracts stipulate that the intellectual property creations of an
-employee are the property of the employer and so the employer should generally
-be listed as the copyright owner.
-
-For more information please see the {copyrightUrl}[Default Eclipse Foundation Copyright and License Notice].
-
-[[ip-licensing]]
-Licensing
-~~~~~~~~~
-
-{forgeName} top level projects define the standard licensing for their
-projectsd. If your project has non standard licensing requirements,
-you may need to make a presentation to the Eclipse board of directors
-to request their approval. The presentation need only briefly describe
-the project and why special licensing considerations are necessary.
-
-[[ip-cq]]
-Contribution Questionnaires
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A Contribution Questionnaires (CQ) is the main interface
-between {forgeName} committers and the IP Team.
-
-A CQ is started when a committer completes a 'questionnaire' regarding
-a contribution or third-party library. In literal terms, a CQ is a
-record in a modified instance of Bugzilla, named 'IPZilla',
-that tracks the progress of the approval process. The CQ record is the
-primary communication channel between the submitting committer and the
-IP Team. CQ records persist indefinitely.
-
-NOTE: You can review existing CQs via {ipzillaUrl}[IPZilla]. Note that
-IPZilla is accessible only by committers, Eclipse Foundation member company
-represenatives, and other specifically-designated individuals.
-
-All significant contributions of code to be maintained by {aForgeName} project, as
-defined by the Eclipse IP Due Diligence Process require a CQ.
-
-Projects require a CQ for every third-party library that project
-code makes direct use of (regardless of whether or not the library
-is directly distributed by the project. If your code makes indirect
-use of a third party library through another {forgeName}
-project's code, you do not require a CQ for that library.
-
-NOTE: CQs for third-party libraries are 'version-specific'. That is,
-a separate CQ is required for different versions of the same library.
-
-CQs are not generally required for ongoing work done by project
-committers. Consult the IP Due Diligence Process document for
-more information.
-
-[[ip-parallel-ip]]
-Parallel IP
-^^^^^^^^^^^
-
-The 'Parallel IP Process' allows {forgeName} projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team. In practical terms, the Parallel
-IP Process permits--with preliminary approval from the IP Team--a
-project to check-in code contributions into their source code
-repository and run builds against third-party libraries
-without having to wait for the full IP Due Diligence Process to
-compete.
-
-NOTE: There is some risk associated with the Parallel IP Process.
-The IP Team will grant preliminary approval based on a cursory
-review of the contribution; but during their full review, they may
-uncover issues that require mitigation. This may require, for
-example, that some parts of a contribution be removed completely
-(history and all) from a source code repository.
-
-Parallel IP manifests in two different ways: projects in the
-'incubation phase' may leverage the Parallel IP process for
-project code and third-party libraries. 'Mature phase' projects
-may leverage parallel IP for new versions of third-party libraries
-for which previous versions have already been approved.
-
-To leverage the Parallel IP Process, projects still submit CQ.
-The difference is that once a CQ has been reviewed for
-license compatibility, the project will be authorized via IPzilla
-to check-in the code start working on it.
-
-All IP must be fully approved before it is included in a release.
-
-[[ip-piggyback]]
-Piggyback CQs
-^^^^^^^^^^^^^
-
-Many third party libraries have already been approved for use in {forgeName} projects.
-Many of those are immediately available via the http://www.eclipse.org/orbit[Orbit Project].
-While these libraries have already been cleared for use by all projects,
-their use must be tracked. Usage is tracked so that--in the event that a issue is uncovered
-following the due diligence process--we can mitigate the impact of that issue.
-
-In this case, a 'piggyback CQ' can be created on top of an existing CQ. Piggyback CQs
-are generally approved very quickly as the due diligence work has already been completed.
-
-[[ip-cq-workflow]]
-CQ Workflow
-^^^^^^^^^^^
-
-The workflow for creating a CQ for a third-party library starts with a search of existing
-CQs. If an existing CQ can be found that is concerned with the same library and version,
-then a piggyback CQ is created. Piggyback CQs must be approved by the project's Project
-Management Committee (PMC) before they are processed by the EMO IP Team.
-
-If an existing CQ cannot be found, a new one must be created. Once created, the source
-code for the third-party library must be attached to the record. The PMC must then approve
-the record. If the project is eligible to leverage the Parallel IP Process, the IP
-Team performs a cursory review of the record and--if the CQ meets with the
-requirements--tentatively approves the use of the library while the full review is
-undertaken in parallel.
-
-The IP team may require your assistance as it performs a deep analysis of the library.
-Once that analysis is complete and the IP team has made a decision, they will outline
-the next steps. These next steps may--in the event that the library is rejected--that
-the library be removed from the project VCS, or that some part be removed. Most often,
-the library is approved and the CQ is marked as such.
-
-Be advised that this process may take a while. The actual amount of time that it takes
-to process a CQ depends on numerous factors including the size of the queue, and the
-nature and size of the contribution.
-
-[[ip-iplog]]
-IP Logs
-~~~~~~~
-
-An IP Log is a record of the intellectual property contributions to a project.
-This includes such as a list of all committers, past and present, that have
-worked on the code and (especially) those who have made contributions to
-the current code base.
-
-The IP Log is a big part of the official <<release, release cycle>>. You are required to
-submit your project's IP Log prior to scheduling a release, or restructuring
-review. We encourage you to keep your IP log current rather than rushing at the
-end. The IP Log includes important information about your project that lets
-adopters know where all the code comes from, who owns the copyrights, and so
-forth.
-
-Specifically, the log tracks:
-
-* Licenses;
-* Past and present committers;
-* Third-party libraries; and
-* Contributions from outside the project (i.e. non-committers)
-
-[[ip-iplog-generator]]
-IP Log Generator
-^^^^^^^^^^^^^^^^
-The Automated IP Log Tool automatically generates an IP Log using information
-that is available to the Eclipse Foundation. The list of committers, for
-example is generated using information provided by the Dash project which itself
-pulls information out of source code repositories.
-
-The IP Log generator pulls information from multiple location to assemble the log:
-
-image::images/ip-log-generator.png[]
-
-* Third-party libraries used by the project come from _IPZilla_;
-* The _Dash_ process scans the project source code repositories to assess committer activity;
-* _Dash_ also scans Git repositories for contributions;
-** If you follow the guidelines for handling Git contributions, contributions received via
-Git in any branch will automatically appear in the log
-* Contributions received as patches in _Bugzilla_ that are marked +pass:[iplog+]+
-will automatically appear in the log; and
-* License information is obtained from the _Foundation_ database
-
-To fully leverage the value of the Automated IP Log Tool, you need to:
-
-* Keep your project metadata up-to-date;
-* Follow the guidelines for handling Git contributions;
-* Mark IP Contributions in Bugzilla; and
-* Create <<ip-cq,contribution questionnaires>> (CQs) where appropriate
-
-WARNING: Contributions should be recorded in _one of_ Git or Bugzilla, not both.
-Setting the _Author_ credentials on Git commits is the preferred mechanism.
-The IP Log generator is not smart enough to detect duplicate entries.
-
-Your project's metadata is used to determine the identities of the source code
-repositories that Dash needs to scan to find out committer information. Specifically,
-you need to specify, in the _Source Repositories_ section, a list of paths to source code
-repository locations.
-
-The Automated IP Log tool populates the _Contributors_ section with information gathered
-from Git and Bugzilla. This section lists contributions from non-committers (this is
-time-sensitive, so contributions made by current committers before they became
-committers will also be included). Only non-committer contributions are recorded in
-the generated log.
-
-<<resources-commit,Git commits>> contributed by non-committers are identified by
-the author credentials on the commit record; the _Author_ field must be set to the identity
-of the actual author of the commit.
-
-Alternatively, Bugzilla attachments can be marked with the +pass:[iplog+]+ flag.
-This flag setting indicates that the person who attached the bug is the contributor.
-To comply with the website terms of use, the person who attaches
-the contribution *must* be the person who has permission to make it available.
-You should ensure that this is the case before including the code in your project's
-repository and flagging the entry.
-
-You can also flag an entire Bugzilla entry with +pass:[iplog+]+. Doing so,
-however, indicates to the Automated IP Log tool that every single comment made by a non-committer
-in the bug report represents a potential contribution. For your own sanity, it's a good practice
-to ask contributors to provide and attach patches that can be individually marked. Marking an
-entire bug represents an ongoing maintenance issue as new comments added to the bug from
-non-committers will show up in the generated log.
-
-That contributions flagged in Bugzilla will only appear in the IP Log if the bug is marked
-+FIXED+ or +CLOSED+.
-
-The Third-Party Software section of the log is populated from IPZilla. The IP Team
-will mark your contributions in such a way that they will appear in
-the log. If third party software is not appearing properly, contact the
-mailto:{ipTeamEmail}[EMO IP Team] to make corrections.
-
-[[ip-faq]]
-Frequently Asked Questions
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-[qanda]
-Do we really need to do this? ::
- Yes.
-
-What do you do with the IP Log? ::
- IP Log reviews occur in two stages. In the first stage, the EMO performs
- a technical assessment to make sure that the artifacts produced by the
- project are properly accounted for in the IP log. You may be asked to
- assist with the resolution of any discrepancies found during this assessment.
- In the second stage, the IP Team reviews the log to ensure that
- it matches their records. The IP log review concludes with approval by the IP Team.
-
-When should I submit the IP Log for review? ::
- The IP Log should be submitted for review by the IP Team two weeks before the planned
- end date for a release review or (if code moves are involved) a restructuring review.
- Note that the date of your review may be different from the date of the actual release.
-
-Are there other reasons to submit the IP Log for review? ::
- Generally no. If the IP Team requires an IP Log review outside of the context of
- a release or restructuring review, they'll ask for it. It is not generally necessary
- to submit an IP Log for review outside of the context of a review.
- It is, however, good practice to do your own review of the generated
- IP Log periodically to make sure that it accurately reflects the state of the project.
-
-How do I fix problems with the generated IP Log? ::
- The IP Log is generated based on data from Eclipse Foundation servers. If the log
- is being generated incorrectly, then the underlying data needs to be fixed. If
- you spot a problem, send a note to {emoEmail}.
\ No newline at end of file
diff --git a/handbook/source/chapters/links.adoc b/handbook/source/chapters/links.adoc
deleted file mode 100644
index c097a9a..0000000
--- a/handbook/source/chapters/links.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-[[links]]
-Links
------
-
-Here are some other links that should help you with the process:
-
-* link:Development Resources/HOWTO/Project Naming Policy[Project Naming Policy] - Selecting a name for your project;
-* link:Development Resources/HOWTO/Pre-Proposal Phase[ Pre-Proposal
-Phase] - The whole process for proposing a project;
-** link:#Proposal_Creation_Links[Create a new proposal] on one of the
-Eclipse Foundation Forges;
-** Examples: http://eclipse.org/proposals/technology.aether/[Aether],
-http://eclipse.org/proposals/mpc/[Marketplace Client]
-* link:Architecture Council[Architecture Council] - The role of the
-Architecture Council in a new project;
-* link:Development Resources/HOWTO/Creation Reviews[ Creation Reviews] -
-Scheduling the proposal's creation review; and
-* link:Development Resources/HOWTO/Incubation Phase[ Incubation Phase] -
-After the project has been created.
-* link:Community_Development_for_Eclipse_Projects[ Community
-Development] - Communities don't develop themselves! Some of the things
-you need to think about.
diff --git a/handbook/source/chapters/notices.adoc b/handbook/source/chapters/notices.adoc
deleted file mode 100644
index 8f82317..0000000
--- a/handbook/source/chapters/notices.adoc
+++ /dev/null
@@ -1,5 +0,0 @@
-[[notices]]
-Notices
--------
-
-Copyright (C) 2015 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0
\ No newline at end of file
diff --git a/handbook/source/chapters/paperwork.adoc b/handbook/source/chapters/paperwork.adoc
deleted file mode 100644
index 82101b9..0000000
--- a/handbook/source/chapters/paperwork.adoc
+++ /dev/null
@@ -1,183 +0,0 @@
-[[paperwork]]
-Committer Paperwork
--------------------
-
-The Eclipse Foundation needs to ensure that all committers with write
-access to the code, web site, and issue tracking system understand their role in
-safeguarding the intellectual property of {forgeName}. The Eclipse Foundation also
-needs to ensure that we have accurate records of the people who are
-acting as change agents on the projects. To ensure that
-committers understand their role, and that that Eclipse Foundation has
-accurate records, committers must provide documentation asserting
-that they have read, understood, and will follow the committer guidelines, and to have
-their employer sign that they agree that the new committer
-can participate at {forgeName} and can contribute under the terms of the
-project license.
-
-All committers must complete the 'Committer Questionnaire' and provide documentation
-as described below.
-
-[[paperwork-questionnaire]]
-Committer Questionnaire
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The {committerQuestionnaireUrl}[Committer Questionnaire] is an online form that
-must be completed by all new committers. This form offers two separate paths:
-one for committers who work for a member company that has provided a signed
-Member Committer Agreement, and one for everybody else.
-
-NOTE: The 'Committer Questionnaire' is accessible only after you have been elected as
-a committer on a project, either as an initial committer on a new project, or
-via election on an existing project.
-
-Only member companies that have provided a signed Member Committer Agreement
-will be listed as member companies in the Committer Questionnaire.
-
-[[paperwork-documents]]
-Documents
-~~~~~~~~~
-
-The exact nature of the documentation required is dependent on your
-employments status.
-
-image::images/paperwork.png["Paperwork requirements flowchart.", scaledwidth=75%]
-
-Documents must be printed, signed and then returned either by fax
-(using the fax number on the form) or as scanned images via email
-to {emoRecordsEmail}.
-
-[[paperwork-mca]]
-Member Committer Agreement
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The {mcaUrl}[Member Committer Agreement] (MCA) is used by member companies to
-cover all of their employees who participate in Eclipse Foundation projects
-as committers.
-
-If your employer has provided a signed MCA, then you most likely do not
-require any additional paperwork.
-
-NOTE: MCAs make committer paperwork easy, especially if you
-work for a member company that employs multiple committers. With an MCA a
-company can provide signed documentation once, rather than once for each
-employee (as required for an Individual Committer Agreement).
-
-If your employer has not already provided an MCA, consult with your management
-team to determine who has the necessary authority to sign it on your company's
-behalf. Provide the MCA in advance of the completion of your committer election
-or new project creation to streamline the committer provisioning process.
-If you and your management team are not sure whether or
-not your employer has an MCA, ask mailto:{emoRecordsEmail}[EMO Records].
-
-If your employer is a member company that cannot provide a signed
-MCA, then you'll have to complete an Individual Committer Agreement and
-Eclipse Committer Employer Consent Form.
-
-[[paperwork-ica]]
-Individual Committer Agreement
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Individual Committer Agreement (ICA) greement is used by committers
-who are not covered by an Member Committer Agreement.
-
-You will need to provide an ICA if:
-
-* You work for member company that has not signed a Member Committer Agreement;
-* You work for a company that is not a member of the Eclipse Foundation;
-* You are self employed or not employed; or
-* You are a student.
-
-If you provide an Individual Committer Agreement, and are employed
-or self-employed, then you also need an 'Eclipse Committer Employer'
-Consent Form.
-
-[[paperwork-ececf]]
-Eclipse Committer Employer Consent Form
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Committers covered by an Individual Committer Agreement must document
-the consent of their employer when participating in Eclipse Foundatio
-projects by providing an Eclipse Committer Employer Consent Form (ECECF).
-
-You will need to provide an {ececfUrl}[ECECF] if:
-
-* You work for member company that has not signed a Member Committer Agreement;
-* You work for a company that is not a member of the Eclipse Foundation; or
-* You are self-employed.
-
-If you are self employed, an owner of your own company, or
-have full ownership or part ownership in another company and has the
-authority to sign and submit the Eclipse Committer Employer Consent Form
-on your own behalf, then they should do so.
-
-Alternatively, you may arrange for the company that is
-your principal business customer to sign and submit the
-Eclipse Committer Employer Consent Form on your behalf.
-
-[[paperwork-existing]]
-Existing Committer
-~~~~~~~~~~~~~~~~~~
-
-If you are already a committer on an existing Eclipse Foundation project then
-additional paperwork may or may not be needed. The EMO IP Team will ask for
-additional documentation if required.
-
-If that MCA or ECECF already explicitly covers you for the
-new project, or that MCA or ECECF is universal (for all projects),
-then no additional paperwork is required
-
-If you are covered by an MCA or ECECF that does not include
-the new project, then the candidate must provide the documents as described
-above.
-
-[[paperwork-not-employed]]
-Not Employed or Student
-~~~~~~~~~~~~~~~~~~~~~~~
-
-If you are not employed or are a student, send a note to {emoRecordsEmail}
-explaining your not employed or student status.
-
-NOTE: We require this email because most new committers are employed by a company,
-the Eclipse Legal Team assumes that is the case for everyone, thus exceptions
-need to be noted.
-
-
-[[paperwork-faq]]
-Frequently Asked Questions
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-[qanda]
-What happens if I do not fill out the paperwork?::
- Then you don't get your login and password for write-access to the
- source code repository(s). Sorry. No exceptions.
-
-What happens if I cannot convince my employer to fill out the paperwork?::
- The Eclipse Board of Directors has taken a firm position that if you are
- employed then you must meet one of the scenarios described above. If you cannot
- convince your employer to fill out the necessary paperwork, then you may
- not have write-access to project resources. This is the
- Board's position _even if_ you are working on {forgeName} projects on your
- own time. We realize that this prevents some talented and desirable
- people from being able to commit to the projects but this is our
- IP risk reduction strategy.
-
-Where can I get help to discuss these documents with my management team? ::
- The EMO and the Executive Director are happy to talk to your management
- and senior executives about these (and other) legal documents to
- help them understand why these documents are the best risk reduction
- solution for everyone involved (The Eclipse Foundation, you, and your
- employer); just contact us at license@eclipse.org.
-
-What formats can be used to submit paper documentation? ::
- The Eclipse Foundation accepts any of the following formats for
- submitting a paper form:
- * Print, sign, and postal mail the form to the Eclipse Foundation;
- * Print, sign, and fax the form to the Eclipse Foundation; or
- * Print, sign, scan, and email to the scan as an attachment to the Foundation
-
-What Email address should I use to send scanned documents? ::
- Email scans of the completed paperwork to EMO Records at {emoRecordsEmail}.
-
-What if a committer changes employers? ::
- If you change employers, please contact {emoRecordsEmail}.
-
\ No newline at end of file
diff --git a/handbook/source/chapters/pmi.adoc b/handbook/source/chapters/pmi.adoc
deleted file mode 100644
index 26ac56c..0000000
--- a/handbook/source/chapters/pmi.adoc
+++ /dev/null
@@ -1,383 +0,0 @@
-[[pmi]]
-Project Management Infrastructure (PMI)
----------------------------------------
-The {forgeName} Project Management Infrastructure (PMI) consolidates
-project management activities into a single consistent location and experience.
-
-Project Management Infrastructure themes:
-
-_Improved consistency._ Configuration/data-driven project web presence,
-direct linkage between releases, reviews, and plans. Information--including
-basic project metadata, project plans, and release review information--is
-captured and retained in a consistent (and easily leveraged) data-based
-format (rather than in multiple documents in arbitrary formats).
-
-_All-in-one-place._ Project leads and committers are able to edit
-information in place on the project information pages. Text/information in
-one place with links in another is eliminated where possible. Comments and
-discussion related to reviews, elections, etc. are connected directly
-to the item being discussed.
-
-_Get started faster._ By default, projects are provided with a data-driven
-website that includes consistent links to project releases, reviews,
-downloads, etc. Projects can opt to override the default and provide
-their own customized web presence. Setting up a project presence is a
-matter of configuration, not PHP programming against proprietary APIs.
-
-[[pmi-metadata]]
-Project Metadata?
-~~~~~~~~~~~~~~~~~
-
-Project committers and project leads are responsible for maintaining
-their project's metadata. This information is an important part of being
-an Eclipse project.
-
-Project metadata is:
-
-1. Relatively static structural information such as the project
-description and scope, the names of the project's mailing lists and
-newsgroups, the bugzilla products, source code repositories, etc.
-2. Historical information such as previous release downloads, release
-review slides and IP logs, etc.
-3. Status and future looking information such as the project and
-milestone plans, the features scheduled for the current release, release
-dates, etc.
-
-PMC members, and the Eclipse Foundation staff also have the ability to
-make changes on behalf of a project.
-
-[[pmi-viewing]]
-Viewing
-~~~~~~~
-
-The complete listing of all current
-{projectListUrl}[{forgeName} projects] provides
-one starting point for viewing projects. From here, you can link
-directly to a project information page. Navigation options are provided
-to help you move from one project to another.
-
-[[pmi-commands-and-tools]]
-Commands and Tools
-~~~~~~~~~~~~~~~~~~
-
-Committers have access to several committer-specific
-commands and tools. The selection of commands available are context sensitive; only those
-commands that make sense for the logged in user are shown.
-
-[[pmi-editing]]
-Editing Project Metadata
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Committers have the ability to edit the information managed and displayed
-on the project page.
-There are several sections on the page. When you switch the page into
-"Edit" mode, you will be provided with lots of help regarding the
-contents of each of the fields (note that the help text is currently
-rendered below the fields).
-
-Some of the fields are described below.
-
-[[pmi-description-and-scope]]
-Description and Scope
-^^^^^^^^^^^^^^^^^^^^^
-
-The 'description' should start with a concise paragraph of three to five
-sentences (e.g. suitable for display with a collection of other projects).
-A single paragraph is generally appropriate for the
-description.
-
-If more than a single simple paragraph is required to fully
-describe the project, it is possible to set a summary. The summary
-can be specified by toggling the "show summary" link to explicitly
-set a summary apart from the more detailed description, or the top
-part of the description can be designated as the summary by inserting
-a 'Teaser Break' into the content.
-
-NOTE: providing a summary gives you control over what will get rendered.
-In views where we are displaying more than one project, the system
-will artifically cut short descriptions that are too long, potentially
-resulting in a description that looks _weird_.
-
-The 'scope' is intended for a more select audience; generally speaking the
-scope should be taken directly from the project's proposal. Project
-members have the ability to change the text of the project scope, but
-should be careful to avoid changing the meaning. If the meaning of the
-scope needs to change, the Project Management Committee (PMC) must be
-contacted regarding a potential restructuring review.
-
-[[pmi-downloads]]
-Downloads
-^^^^^^^^^
-
-You can provide download information for your project in the "Downloads"
-section.
-
-The first entry is the main "Downloads URL". This manifests as a "Big
-Button" Download on the project page. What you put here is left to the
-project team to decide. It can be a link to a webpage, a direct link to
-a file download, or whatever else makes sense the project and community.
-
-Optional text can be included along with the "Big
-Button" Download, as well as links to zero or more Eclipse Marketplace,
-update/p2 sites, or other downloads. Each of the links can have an
-optional title (the link itself will be displayed if no title is
-provided). Note that no validation is done on the links to ensure that
-they are meaningful.
-
-ifeval::["{forgeName}"=="Eclipse"]
-_The Eclipse Foundation strongly encourages all projects to create an
-maintain and http://marketplace.eclipse.org[Eclipse Marketplace]
-presence._
-endif::[]
-
-[[source-repositories]]
-Source Repositories
-^^^^^^^^^^^^^^^^^^^
-
-The project can specify zero or more *source repositories*. These are
-displayed in the "Contribute to this Project" section.
-
-The values specified are used to query against a database of known
-existing source repositories (this database is updated nightly by a
-discovery process). Those repositories that are found in the database
-will be displayed with enhanced information (including links to
-repository mirrors, Gerrit, etc.). All values that you provide will be
-displayed, whether they point to real repositories or not. If the
-database does not contain your repository, the PMI will assume that the
-value is correct and try its best to display the information.
-
-Repositories should be specified using the file system path, e.g.
-'/gitroot/egit/egit.git'. The name that is displayed for the repository
-is extracted from the last segment of the URL.
-
-If a description file exists in the Git repository, the contents are
-automatically displayed under the repository name.
-
-NOTE: The script that we us to identify repositories attempts to identify a
-corresponding Gerrit interface for the repository. If it exists, the
-Gerrit URL is used in place of the Git one. If the repository uses
-Gerrit, then only the Gerrit URL is displayed. Otherwise, the "git://"
-and "ssh://" URLs are displayed.
-
-You can use wildcards to match multiple repositories, e.g.
-'/gitroot/virgo/*'. Note that wildcards only work for repositories that
-exist on {forgeName} infrastructure (they do not work for GitHub-based
-repositories, for example).
-
-Repositories are displayed in the order they are specified. The order
-can be changed in the edit screen by dragging entries into the desired
-order. All wildcard matches are sorted alphabetically by name at the end
-of the list.
-
-A *Contribution Message* should be provided; it is displayed at
-the top of the section and is one of the primary means by which the
-community will find the project code. Arbitrary text is permitted, but we recommend
-that you limit this content to a single paragraph with a few sentences
-that include a link to more information.
-
-[[pmi-company-logos]]
-Company Logos
-^^^^^^^^^^^^^
-
-Company logos sometimes appear on project pages under the following
-conditions"
-
-* The company must be a http://eclipse.org/membership/[member] of the
-Eclipse Foundation;
-* The company needs to have their logo uploaded to the Portal;
-* At least one committer has to be listed as an employee of the company
-in question;
-* The committer must be on this project; and
-* The committer must be active (must have made at least one commit in
-the last three months)
-
-If all of those conditions are met and the logo is still not showing up,
-then it's possible that the project meta-data doesn't have the correct
-source code repository information specified.
-
-[[pmi-build-technology]]
-Build Technology
-^^^^^^^^^^^^^^^^
-
-A project can specify a section of text, links, and a selection of the
-build technologies employed. Specifying this information makes it easier
-for members from the community to understand your build. Links can
-include direct links into the Hudson builds, pages of build
-instructions, or whatever else the project team feels will help the community build
-the project.
-
-[[pmi-technology-types]]
-Technology Types
-^^^^^^^^^^^^^^^^
-
-A project can specify the types of technology produced by the project.
-This is specified in rather broad terms like "OSGi" or "Runtime". The
-various technology types manifest as checkboxes on the edit screen. This
-information is used to form connections between projects to assist in
-navigation and discovery.
-
-Clicking on one of the technology types, will take the user
-to a page that lists the projects that produce that particular type of
-technology, along with the summary of their description and project logo
-(if specified).
-
-[[pmi-releases]]
-Releases and Reviews
-~~~~~~~~~~~~~~~~~~~~
-
-Projects, Releases, and Reviews are presented as separate records. Each
-project record, obviously, represents information about a project. A
-project may have multiple releases; information about the release is
-represented in a release record. The release record also contains some
-review information. This information is included here, because all
-releases do not necessarily have a review (a project can opt to provide
-some _review_ type information as part of a release record. A project
-can have multiple review records; as release reviews are the most common
-form of review, most review records will be joined to a release record.
-
-image::images/ProjectsReleasesReviews.png["Releases and Reviews"]
-
-A review record, however, does not require a release association. Some
-reviews are associated with proposals. Other have no other association
-(e.g. termination reviews).
-
-Each <<release,release>> has its own record in the database. Records are connected
-directly to a single specific project; a subset of release records
-associated with a project are displayed on the project page. An existing
-release can be edited in much the same was as a project. Any logged in
-project member (committer or project lead) can click the "Edit" button.
-
-NOTE: _Create a single record for each release. *Do not create release records
-for milestones.* Enter milestone information in the 'Plan' information
-for your release.
-
-A project lead or committer can create a new release by clicking "Create a new release" under
-"Committer Commands" on the project page. This opens a dialog requesting
-that a date and name be specified. Both of these values can be changed later.
-
-[[pmi-release-description]]
-Description
-^^^^^^^^^^^
-
-Describe the release in the 'Description' section. The description
-should generally be a concise paragraph describing the focus of the
-release (e.g. adding certain functionality, fixing bugs, etc.) in a form
-that is appropriate in an aggregation (e.g. a page that displays the
-release information for all projects participating in an instance of the
-Simultaneous release). The description should provide enough information
-to encourage the reader to click the "find out more" link.
-
-[[pmi-release-issues]]
-Issues
-^^^^^^
-
-The release record will automatically generate a list of targeted bugs.
-
-To populate this list:
-
-* Ensure that the Bugzilla Product is set the to correct value in the
-project metadata;
-* Set the "target milestones" in Bugzilla need to match the name of your
-release.
-
-NOTE: The matching algorithm tries to be as forgiving as possible, a release
- named "3.5", "3.5.0", or "3.5 (Luna)" will--for example--match target
- milestones named "3.5" ,"3.5M1", "3.5 M2", "3.5.0M3", etc., but will
- not match "3.5.1".
-
-The bugs for all projects participating in the release will be included.
-Bugs are grouped by Bugzilla product and component.
-
-[[pmi-release-plan]]
-Plan
-^^^^
-
-<<releases-plan,Project plan>> information belongs in the 'Plan' section. This
-information *should* generally be provided early in the development
-cycle to allow the various communities the ability to understand and
-participate in the release. It is expected that the plan will evolve
-over time. Note that all projects are required to provide a plan for
-each major and minor release (plans are not required service releases).
-
-[[pmi-release-milestones]]
-Milestones
-^^^^^^^^^^
-
-Enter the name, date, and optional description for each milestone
-expected with the release.
-
-Projects should generally include more than one milestone build with each
-release. To include additional milestones, click the "Add another item"
-button. Note that milestones can be dragged into the desired order. To
-remove a milestone, leave the "Name" field blank.
-
-[[pmi-review]]
-Review
-^^^^^^
-
-The release has a <<release-review,'Review'>> section that can be used to provide
-information for the associated review. If you provide information here,
-the release record itself can be used as review documentation; no
-further documentation is required.
-
-Each section on the review page includes a little help to describe the
-sort of information that you should provide.
-
-All major and minor releases require a review. Service releases (i.e.
-bug fix releases that do not change public APIs or add new
-functionality) do not require a review.
-
-If a release requires a review, you can schedule one by clicking the
-"Schedule a review" button. The drop-down list above the button contains
-several options for review dates. Pick the one that works best for you.
-
-Note that this form will not appear if a review has already been
-scheduled, or the release date does not provide enough time to run a
-review (or is in the past). If a review has been scheduled, a link to
-the review will appear.
-
-You can edit the review document, but there's really not all that much
-to edit. A free-form text field is available and can be used if there is
-some need to provide review-specific information that might not
-otherwise be an appropriate part of the release record. _This field is
-intended for other types of review (e.g. restructuring or termination
-reviews); we decided to leave it available for release reviews for cases
-in which it might be useful rather than suppress it._
-
-When the review is displayed, it automatically includes the _review_
-information from the release record; it shows the review-specific
-information at the top of the page, and includes the _review_
-information from the release as the rest of the page contents.
-
-This can make things a bit confusing when you want to make changes to
-the metadata for a review record. Just remember that the _review_
-information for a release is stored in the release record.
-
-ifeval::["{forgeName}"=="Eclipse"]
-[[pmi-joining-a-simultaneous-release]]
-Joining a Simultaneous Release
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Projects cannot add themselves directly to a simultaneous release (e.g.
-https://projects.eclipse.org/releases/luna[Luna]), but rather must be
-added by the EMO (there is a
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=402190[bug open] to extend
-this ability to planning council members).
-
-To join a simultaneous release:
-
-1. Create a release record:
-* Provide at least a description of the release initially;
-* The date of the release should generally match that of the
-simultaneous release;
-2. Send a note to the planning council (Eclipse projects normally do
-this via the
-https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev[cross-project-issues-dev
-mailing list]) with the name of your project, the name/number of the
-release, and the offset.
-
-The offset indicates how many days after the start of the aggregation
-process for a milestone your project's bits will be available. If your
-project's bits depend on a +pass:[+1]+ project's bits then your project is
-probably a +pass:[+2]+ project, for example.
-endif::[]
\ No newline at end of file
diff --git a/handbook/source/chapters/preamble.adoc b/handbook/source/chapters/preamble.adoc
deleted file mode 100644
index ba754af..0000000
--- a/handbook/source/chapters/preamble.adoc
+++ /dev/null
@@ -1,92 +0,0 @@
-[[preamble]]
-Overview
---------
-This document provides you with the information that you need to
-create a new {forgeName} open source project or become a committer
-on an existing one.
-
-ifeval::["{forgeName}"!="Eclipse"]
-While this document is focused on {forgeName}, it makes several
-"Eclipse" references, including the 'Eclipse Foundation',
-'Eclipse Development Process', and 'Eclipse Management Organization'.
-The Eclipse Foundation is the legal entity that manages the operations
-of the {forgeName} working group, software development forge, and community.
-Many of the provided services and contacts are so-named on
-that basis.
-endif::[]
-
-The {edpUrl}[Eclipse Development Process] (EDP) is the foundational
-document for {forgeName} projects and committers. It describes the
-manner in which we do open source software. The Eclipse Development
-Process does not prescribe any particular development methodology;
-it is more concerned with the larger-scale aspects of open source
-project lifecycle, including such things as reviews, processes for
-running votes and elections, bringing new committers onto a project, etc.
-This document will elaborate on some key points of the Eclipse Development
-Process.
-
-[[preamble-principles]]
-Principles
-~~~~~~~~~~
-Four basic principles lie at the heart of the Eclipse Development Process:
-
-* Transparency;
-* Openness;
-* Meritocracy; and
-* Vendor neutrality
-
-We refer to the first three as the "open source rules of engagement".
-
-To operate with *transparency*, a project's discussions, minutes, deliberations,
-project plans, plans for new features, and other artifacts are open, public,
-and easily accessible.
-
-*Openness* at {forgeName} means quite a lot more than "open book" (which is
-really a synonym for transparent). The project is open to all;
-{forgeName} provides the same opportunity to all. Everyone participates
-with the same rules; there are no rules to exclude any potential contributors
-which include, of course, direct competitors in the marketplace.
-
-{forgeName} is a *meritocracy*. The more that somebody contributes, the more
-responsibility they will earn. A pattern of quality contribution to a project
-may lead to an invitation to join the project as a committer. Leadership roles
-in {forgeName} are also merit-based and earned by peer acclaim. Merit must be
-demonstrated in publicly-accessible forums. Committers and project leads are
-added to a project via <<elections, election>>.
-
-NOTE: Employment status has no bearing at whether or not somebody can participate
-in an open source project at {forgeName}. Employment does not guarantee
-committer status; committer status must be earned by everybody.
-
-*Vendor neutrality* is similar to openness in that it's concerned with
-maintaining a level playing field. No vendor is permitted to dominate a project,
-and nobody can be excluded from participating
-in a project based on their employment status. While
-project resources will contain copyright statements that assert ownership of
-various assets by individual vendors, the project itself must remain vendor
-neutral.
-
-Quality and intellectual property cleanliness are also important principles.
-
-*Quality* means extensible frameworks and exemplary tools developed in an open,
-inclusive, and predictable process involving the entire community. From the
-consumption perspective, {forgeName} quality means good for users (exemplary tools
-are cool/compelling to use, indicative of what is possible) and ready for
-use by adopters. From the creation perspective, {forgeName} quality means working
-with a transparent and open process, open and welcoming to participation from
-technical leaders, regardless of affiliation.
-
-*<<ip,Intellectual property>>* (IP) is any artifact that is made available from
-a {forgeName} server (this includes source code management systems, the website,
-and the downloads server). Artifacts include (but are not limited to) such things
-as source code, images, XML and configuration files, documentation, and more.
-Strict rules govern the way that we manage IP and your responsibilities
-as a committer.
-
-Code produced by an {forgeName} project is used by organizations to build products.
-These adopters of {forgeName} technology need to have some assurance that the IP they're
-basing their products on is *clean*: the organization or individuals who claim
-copyright of the code are the legitimate copyright holders, and the copyright
-holders legitimately agree to make the code available under the license(s) that
-the project works under. As a committer, you must be careful that you do not copy
-code and inadvertently claim it as your own.
diff --git a/handbook/source/chapters/release.adoc b/handbook/source/chapters/release.adoc
deleted file mode 100644
index 93f3d15..0000000
--- a/handbook/source/chapters/release.adoc
+++ /dev/null
@@ -1,229 +0,0 @@
-[[release]]
-Releases
---------
-
-Releases are formal for {forgeName} projects. They start with planning,
-and end with a community review. You can capture as many future releases as you'd like. It's
-common practice to specify releases three or six months into the future.
-
-Releases are broadly categorized as:
-
-* 'Major' releases include API changes (potential for downstream breakage);
-* 'Minor' releases add new functionality, but are API compatible with previous versions; and
-* 'Service' releases include bug fixes only and include no significant new functionality.
-
-For all major and minor releases, you must engage in a 'release review'.
-Release reviews are not required for bug-fix/service releases.
-
-image::images/release-cycle.png["The release cycle"]
-
-[[releases-plan]]
-A project plan is 'required' for each major and minor project release.
-The plan should lay out in broad terms what the goals are for the
-release. As plans are a valuable means
-for the community to get involved with your project, the plan should be
-created at the beginning of the release cycle. By establishing the plan
-early, you give prospective contributors help in determining how they
-can most usefully contribute, and adopters can prepare their own
-development schedule and themes. Plans can change during the release
-cycle.
-
-Use the <<pmi, Project Management Interface>> to create a new release
-record. At the start of the release cycle, your plan should minimally
-include a release number, date, and short description. Think of the
-description as an "elevator pitch": how would you describe the release
-in a fifteen second elevator ride? All aspects of a plan can change
-during the release cycle (including the date). If you do change the plan,
-make sure that the change is communicated via your project's 'dev' list
-and other project channels.
-
-The 'Plan' tab in the release record contains numerous fields for capturing
-plan information. The amount of information that you should capture
-for a release plan varies by top-level project, so consult with your
-Project Management Committee (PMC) for advice.
-
-Producing regular builds is an important part of the release cycle.
-Builds are an important means of engaging with the community: adopters can
-help you test your code and test their own so that they can be ready for
-the eventual release. Plan to produce at least one 'milestone' build (more
-are better, depending on the length of your release cycle), and capture
-the planned date for that milestone in the release record. It is also
-common practice to generate nightly and weekly integration builds. Ensure that
-your project's downloads page provides the information required for the
-community to obtain your builds.
-
-All of your project's <<ip,intellectual property>> contributions
-must be approved by the IP Team before you can release
-(this includes third-party libraries and contributions of code to be
-maintained by the project).
-
-[[release-review]]
-Release Review
-~~~~~~~~~~~~~~
-
-A 'release review' is a formal announcement of your release to the
-community and a request for feedback. In practical terms, experience
-has shown that those individuals and organizations who are interested
-in your project follow development throughout the release cycle and so
-are have likely already provided feedback during the development
-cycle (i.e. they are unlikely to provide feedback during the review
-period). With this in mind, the review generally serves as a means for
-a project to engage in a retrospective of the progress made during the
-release, discover areas of potential improvement, demonstrate that the
-project is operating in an open and transparent manner, and ensure that
-the development process and intellectual due diligence processes have
-been followed.
-
-Release reviews run for a week and always conclude on a Wednesday.
-
-NOTE: We schedule reviews to conclude on the 'first and
-third Wednesdays of the month'. Your release date does not have to
-coincide with the review date (you can set the release date as
-necessary). The review must, however, conclude successfully before you
-can make the release official.
-
-A 'release review' requires review documentation and an intellectual
-property (IP) log check. The review process must be initiated at least
-two weeks in advance of the anticipated 'review' date.
-
-image::images/release-review.png["Release review work flow"]
-
-Prepare the review documentation well in advance of the start of the
-review period. The release record which contains your project plan
-also includes a 'Review' tab with appropriate fields for a review.
-As with the plan fields, all of the review fields are optional and
-the level of detail you need to provide varies by top-level project.
-You can assemble review information during the release cycle (there's
-no need to wait until the end)
-
-The review materials must be approved by the PMC; send an email to
-the PMC's mailing list asking for approval. The PMC will respond with
-feedback or a simple "+1" indicating approval.
-
-NOTE: Click the handy 'Send Email to the PMC' link under 'Committer Tools'
-on the release record page to connect with the PMC.
-
-Submit the IP Log for review by the IP Team. The IP Team must approve
-the IP Log before we can schedule the review, so submitting this early
-is important. The <<ip-iplog-generator,IP Log generator>> automatically
-collects information based on the information that the project team has
-provided to the IP Team through <<ip-cq,contribution questionnaires>>
-in IPZilla, commits in the project's source code repository, and
-other information in our databases. Carefully review the IP Log before
-submitting to the IP Team for their review.
-
-NOTE: Click the handy 'Generate IP Log' link under 'Committer Tools'
-on the release record page to open the IP Log generator.
-
-The information used to generate an IP Log should always be up-to-date
-(don't wait until the end of the release cycle to make it right).
-
-At any point in this process, you can request that the review be
-initiated by clicking the 'Schedule a review for this release' link
-that appears at the top of the release record page. This will invite you
-to select a review date. You must then follow up with the EMO to approve
-the review.
-
-NOTE: The EMO will likely notice that you've created the release record,
-connected with your PMC, and submitted an IP Log for review by the IP
-team and will take steps to initiate the actual review. However, since
-there is a great deal of variability in this process, send an email to
-{emoEmail} stating your intent to release.
-
-The EMO will conclude the review on the scheduled end date and advise the
-project team of the outcome.
-
-[[release-graduation]]
-Graduation Review
-~~~~~~~~~~~~~~~~~
-
-The purpose of a 'graduation review' is to confirm that the project has
-a working and demonstrable code base of sufficiently high quality
-active and sufficiently diverse communities; has adopters, developers, and users
-operating fully in the open following the {edpUrl}[Eclipse Development Process]; and
-is a credit to {forgeName} and is functioning well within the larger {forgeName} community
-
-Graduation reviews are generally combined with a <<release-review, 'release review'>>
-(typically, but not necessarily the '1.0' release).
-Upon successful completion of a graduation review, a project will leave the
-incubation phase and be designated as a 'mature' project.
-
-For a graduation review, release review documentation must be augmented to
-include demonstration of:
-
-* solid working code with stable APIs;
-* an established and growing community around the project;
-* diverse multi-organization committer/contributor/developer activity; and
-* operation in the open using open source rules of engagement.
-
-The graduation review documentation should demonstrate that members have
-learned the ropes and logistics of being {aForgeName} project. That is,
-the project "gets the {forgeName} way".
-
-[[release-faq]]
-Frequently Asked Questions
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-[qanda]
-Can a release review fail? ::
- Technically, yes. A release review can fail. In our history, however, this
- occurrs very rarely. We set up release reviews to succeed.
-
-Do we really need to do this? ::
- Yes.
-
-How often should we do releases? ::
- This depends very much on the nature of your project and the expectations
- of your community and stake holders. If you're not sure, connect with your
- mentors and top-level project for guidance.
-
-How much effort should we put into this? ::
- The amount of effort varies based on the nature of the team, and
- expectations of the community and stake holders. Generally, though, a project
- team shouldn't spend more than a couple of hours working directly on the
- formal aspects of the release review.
- If the amount of effort seems too onerous, you may be trying too hard.
- Connect with your project mentors, top-level project's PMC, or the
- mailto:{emoEmail}[EMO] for guidance.
-
-
-How do I submit the IP Log for review? ::
- Click the 'Submit' button on the <<ip-iplog-generator,IP Log generator>>.
- You need to be logged in as project committer to have access to this button.
-
-Can I accept contributions after I submit the IP Log for review? ::
- The short answer is 'yes'. Please do accept contributions.
- If you require a new contribution questionnaire (for either a third
- party library or code contribution) after submitting the IP Log for
- review, please ask the mailto:{ipTeamEmail}[IP Team] if
- they want you to resubmit the IP Log.
-
-How do I obtain PMC approval? ::
- Send the the PMC a note via the top-level project's 'PMC' mailing list
- with a link to the release record. Note that the release record page
- has a handy link labeled 'Send Email the PMC' under 'Committer Tools'.
-
-I need to do a release now. Can you fast-track the review? ::
- While we do try to be as accommodating as possible, the answer is no.
- We have a well-defined process with predictable dates. Please plan
- accordingly.
-
-Can a project in the incubation phase do releases? ::
- Yes. In fact, we encourage projects to do at least one release while
- in incubation phase.
-
-What restrictions are placed on version names for incubating projects? ::
- Projects in the incubation phase generally use version numbers that
- are less than 1.0. This is, however, a convention not a rule. If it makes sense
- for you community and adopters to use higher numbers, then do so.
- If you're not sure, ask your top-level project PMC for advice.
-
-How do I name/number milestone builds? ::
- Milestone builds should contain the name/number of the release suffixed
- with "Mn" (e.g. the second milestone for EGit 3.2 may have a file
- named "egit-3.2M2"). Projects in the incubation phase may produce
- milestone builds for their graduation release, e.g "myProject-1.0M2".
-
-How can I get help? ::
- Contact your mentors (for projects in the incubation phase), top-level
- project PMC, or the mailto:{emoEmail}[EMO].
diff --git a/handbook/source/chapters/resources.adoc b/handbook/source/chapters/resources.adoc
deleted file mode 100644
index be15a1d..0000000
--- a/handbook/source/chapters/resources.adoc
+++ /dev/null
@@ -1,250 +0,0 @@
-[[project-resources-and-services]]
-Project Resources and Services
-------------------------------
-Open source projects at the Eclipse Foundation are required to make use
-of certain Eclipse Foundation services:
-
-* All project issues must be tracked in the {bugzillaUrl}[{forgeName} Bugzilla]
-instance;
-* Source code must be maintained in source code repositories assigned to the
-project (e.g. {aforgeName} {gitUrl}[Git] or {gerritUrl}[Gerrit] instance,
-or the {gitHubUrl}[{forgeName} Organization] on GitHub);
-* All third-party libraries used by the project must be tracked and
-approved for use by the Eclipse IP Team;
-* Downloads must be distributed via a forge-specific downloads server;
-* Developer (committer) communication must occur in the _dev_ list
-provided to the project by the Eclipse; and
-* Projects must keep their <<pmi-metadata, Project Metadata>> up-to-date.
-
-[[resources-source]]
-Source Code Management
-~~~~~~~~~~~~~~~~~~~~~~
-Your project must maintain source code in the repositories assigned to the
-project by the Eclipse Foundation. These official repositories must be
-the exclusive source of all project code delivered via the project's assigned
-distribution channel (e.g. the download server).
-
-In order for your project to operate in an _open_ manner, it must be possible
-for potential contributors to have access to the code base in its most current
-form, so all ongoing development must be regularly pushed to these canonical
-repositories.
-
-[[resources-cla]]
-Contributor License Agreement (CLA)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Eclipse Foundation has implemented {claUrl}[Contributor License Agreements] (CLA)
-to improve <<ip,intellectual property>> (IP) management and workflow. All
-contributors, who are not committers on the {forgeName} project, must sign the CLA.
-
-You do *not* require a CLA to contribute to a project on which you have committer
-status.
-
-[[resources-commit]]
-Git Commit Records
-^^^^^^^^^^^^^^^^^^
-Git commit records are required to take a specific form. The credentials
-of the actual author must be used to populate the +Author+ field. The email
-address used must match the email address that the Eclipse Foundation has
-on file for the author (case-sensitive).
-
-The commit message is divided into three sections:
-
-. One line (max 72 characters) summary;
-. Description; and
-. Footer.
-
-.Example Git Commit Record
-[source]
-------------------------------------------------------------
-commit d6cf52411377a039fc2906378711091a26e932cb
-Author: Some Body <somebody@somewhere.com> <1>
-Date: Wed May 29 16:17:36 2013 +0200
-
- Bug 350686 - Hide unwanted action bar items <2>
-
- This change hides unwanted 'Link with Editor' and
- 'Customize View...' items from the local toolbar
- and the view menu.
-
- Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 <3>
- Also-by: Some Bodyelse <somebodyelse@nowhere.com> <4>
- Signed-off-by: Some Body <somebody@somewhere.com> <5>
-------------------------------------------------------------
-
-<1> The email address of the author must match the email address on the Eclipse Foundation account.
-<2> Best practice: include the bug id in the commit message summary.
-<3> Gerrit change id (only when pushing to Gerrit for review).
-<4> Additional authors can be added using +Also-by+ entries.
-<5> Non-committers must _sign-off_ the commit using the same email address as used in the author field.
-
-The _summary_ line is used in many places where Git commits are listed, ensure
-that this line is sensible by itself. The _description_ area should be used to provide
-more detail about the commit. The footer area is used for extra fields and values.
-
-If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx")
-Gerrit Code Review will automatically add a link in the
-corresponding Bugzilla record back to the Gerrit record (this, of course, only
-applies to commits pushed to Gerrit).
-
-The +Change-Id+ is used by <<resources-gerrit,Gerrit Code Review>> to associate new versions
-of a change back to its original review. This field need only be specified if the
-repository is managed by Gerrit.
-
-Create a separate +Also-by+ field for each additional author of a commit. This might
-apply, for example, if a commit has been authored via pair-programming, or the commit
-is the result of collapsing multiple commits authored by multiple developers.
-
-Commits that are provided by non-committers must have a +Signed-off-by+ field in the
-footer indicating that the author is aware of the terms by which the contribution has been
-provided to the project. The non-committer must additionally have an Eclipse Foundation
-account and must have a signed <<resources-cla,Contributor License Agreement>> (CLA)
-on file.
-
-[[resources-git]]
-Git
-^^^
-Those projects that want to use Git on the {forgeName} forge, are assigned a
-directory in which they may create as many Git repositories as required.
-{gitRequestUrl}[Open a bug] to request that the Webmaster create a new Git
-repository for your project. Alternatively, committers with shell accounts
-can create repositories themselves.
-
-[subs="attributes"]
-.Create a new Git repository
------------------------------------------------------
-> initrepo /gitroot/project/{namespace}.repo.name.git
------------------------------------------------------
-
-For consistency, the name of the repository must end with +.git+.
-
-To set the description of the repository, use +sftp+ or +scp+ to copy a text file to
-+/gitroot/project/{namespace}.repo.name.git/description+. Git repository
-descriptions should be limited to a paragraph of one or two sentences.
-
-Only project committers can push to {aForgeName} Git repository. A push
-that includes commits that do not conform to the required form will be rejected.
-
-You can {gitUrl}[browse {forgeName} repositories] directly on the Git server.
-
-[[resources-gerrit]]
-Gerrit Code Review
-^^^^^^^^^^^^^^^^^^
-https://www.gerritcodereview.com/[Gerrit] provides web based code review and
-repository management for the Git version control system. Many projects use
-Gerrit to reduce barriers and encourage contribution to the project.
-{gerritRequestUrl}[Open a bug] to request that the Webmaster configure your
-Git repository for Gerrit.
-
-Commits may be pushed directly to the Git repository through Gerrit by
-a project committer (e.g. to the +master+ branch).
-
-Anybody can push to a +refs/for/*+ branch for review in a Gerrit repository. A push
-that includes commits that do not conform to the required form will be rejected.
-Commits intended for review should have a
-https://git.eclipse.org/r/Documentation/user-changeid.html[+Change-Id+]
-
-You can {gerritUrl}[browse {forgeName} repositories] directly on the Gerrit
-server.
-
-[[resources-github]]
-GitHub
-^^^^^^
-Projects may opt to move some or all of their canonical source code repositories to the
-{gitHubUrl}[{forgeName} organization] on GitHub.
-
-NOTE: Projects that host source code on GitHub are not permitted to use GitHub
-Issues or Wiki.
-
-{gitHubRequestUrl}[Open a bug] to request that the Webmaster create a new, or move
-an existing, Git repository for your project. The Webmaster will install some
-_hooks_ on your GitHub repository.
-
-The _Committers hook_ grants designated project committers write access to the
-GitHub-hosted project repositories. Project committers must use the email address they
-provide to the Eclipse Foundation as their GitHub email address.
-
-The <<resources-cla,Contributor License Agreement>> (CLA) hook will inspect incoming
-GitHub pull requests to ensure that the contributor has a valid CLA on file, and that
-the commit has been "signed-off" as required. Project committers should only merge pull
-_green_ requests:
-
-image::images/Github-cla-success.png[]
-
-The GitHub API does not give us a means of absolutely denying a merge; all we can
-do is warn you that the contributors have not signed a CLA:
-
-image::images/Github-cla-failure.png[]
-
-Do not merge unless you are absolutely certain that the contributer does have a
-valid CLA on file (e.g. the Contributor License Agreement Lookup Tool confirms
-that they have a CLA).
-
-You must manually check that the commit message includes the
-required "Signed-off-by" statement in the footer.
-
-The Webmaster creates and maintains a mirror of all GitHub-hosted
-repositories on Eclipse Foundation hardware.
-
-[[resources-libraries]]
-Third-party Libraries
-~~~~~~~~~~~~~~~~~~~~~
-{forgeName} projects must register all of their <<ip-third-party,third-party library>> use with the
-IP Team.
-
-[[resources-forums]]
-Forums and Outbound Communication
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-All projects are assigned a {forumsUrl}[user forum] as a point of contact between
-the user and adopter communities, and the project developers.
-
-The EMO strongly encourages the use of alternative communication channels for
-connecting with the community: your project team knows your community and how
-to best connect with them.
-
-[[resources-website]]
-Project Websites
-~~~~~~~~~~~~~~~~
-Project websites are an excellent way to connect your project with
-your community. Many projects opt to use the <<pmi,Project Management Infrastructure>>
-(PMI) as their project website,
-but if so-desired, a project may host a website on Eclipse Foundation-hosted
-servers.
-
-Project website sources are hosted in Git repositories maintained by the
-Eclipse Foundation. {websiteRequestUrl}[Open a bug] to request that the Webmaster
-create a website for your project.
-
-NOTE: Alternative hosting services for project-specific websites are
-not permitted. Websites _not_ hosted by the Eclipse Foundation are
-considered third-party and so are subject to the
-{trademarkGuidelinesUrl}[Guidelines for Eclipse
-Logo & Trademarks] (the Eclipse foundation asserts ownership of the
-project name trademark).
-
-[[resources-builds]]
-Builds
-~~~~~~
-Use of Eclipse Foundation-provided and hosted build services, the so-called
-{cbiUrl}[Common Build Infrastructure] (CBI) is strongly recommended, but n
-ot strictly required.
-
-Whether or not your project chooses to make use of provided build resources, it must
-be possible for members of the community to build project artifacts from
-source code with reasonable effort.
-
-[[resources-signing]]
-Signed Artifacts
-^^^^^^^^^^^^^^^^
-Where technically sensible, all downloadable artifacts should
-be {jarSigningUrl}[signed] by an Eclipse Foundation-provided certificate.
-
-[[resources-downloads]]
-Downloads
-~~~~~~~~~
-Project artifacts (e.g. downloads) can be distributed via third-party
-services (e.g. Maven Central), but the Eclipse Foundation-provided
-infrastructure must be considered the primary source of project
-downloads.
-
-Project committers can {downloadsUrl}[upload project artifacts] to the project's
-directory on the download server.
\ No newline at end of file
diff --git a/handbook/source/chapters/starting.adoc b/handbook/source/chapters/starting.adoc
deleted file mode 100644
index cce58f7..0000000
--- a/handbook/source/chapters/starting.adoc
+++ /dev/null
@@ -1,203 +0,0 @@
-[[starting]]
-Starting an Open Source Project at {forgeName}
-----------------------------------------------
-
-{forgeName} open source projects start with a proposal that is made
-available to the community for review. At the end of the 'community
-review' period, we engage in a 'creation review', and then
-provision the project resources.
-
-image::images/project-creation.png["An overview of the Project Creation Process"]
-
-Use the {createurl}[web form] to create a new project proposal.
-Instructions are provided on the form. All new proposals are created
-in 'draft' mode, and are accessible only by the original author and
-anybody designated as a project lead or committer in the proposal.
-Only those individuals designated as a project lead may edit the
-proposal.
-
-NOTE: Keep track of the URL of the proposal. We do not provide
-public links to the document until after the proposal is opened for
-community review.
-
-A proposal must minimally include a description of the project, a
-declaration of scope, and a list of prospective members (project
-leads and committers) before we make it accessible to the public
-for 'community review'.
-
-When you feel that the proposal is ready, send a note to
-the Eclipse Management Organization (EMO) at {emoEmail} requesting that
-the proposal be made available to the public for review. The EMO
-will review the proposal and may provide feedback before initiating
-the 'community review' period.
-
-At the beginning of the 'community review' period, the EMO will
-announce the proposal on several channels (the {activityUrl}[Project
-Activity News] page, Twitter, the
-{proposalsForum}[Proposals Forum], blog post, and an email note
-to the Eclipse Foundation members and committers). The EMO will
-also open an record in the Eclipse Foundation's issue tracker--an
-instance of Bugzilla--to track the progress of the proposal;
-the proposal's author and project leads will be copied on that record.
-
-A proposal will be open for community review for a minimum of two
-weeks.
-
-The Eclipse Foundation holds the 'trademark' for all {forgeName} projects.
-Trademark assignment is undertaken prior to the creation of any new
-project. If you already have a trademark on your project name, that
-trademark must be assigned to the Eclipse Foundation. Be advised that
-trademark assignment can be a time-consuming process (it can take hours,
-days, or weeks depending on the circumstances surrounding the name).
-If you currently hold the trademark, you will be asked to complete a
-{trademarkTransferUrl}[Trademark Transfer Agreement].
-
-The proposal must list two mentors from the Architecture Council.
-Members of the Architecture Council have considerable experience with
-Eclipse Foundation practices, and the {edpUrl}[Eclipse Development Process].
-If you are already in contact with mentors who agree to help you with
-your project, please do list them in the proposal. Otherwise, the
-EMO will engage directly with the Architecture Council to identify
-mentors as necessary. Mentors are available to the project through the
-incubation phase; they are released from their duties when the project
-<<release-graduation,graduates>>.
-
-When the project name trademark has been secured, mentors have been
-identified, and the proposal contents are finalized, the EMO will schedule
-a 'creation review'. Reviews--which run for a minimum of one week--are
-scheduled twice a month, generally concluding on the first and third
-Wednesday of each month. The creation review may overlap with the
-'community review' period.
-
-NOTE: Creation reviews tend to always be successful. They should be
-considered low stress as the hard work has already been done in
-advance of the start of the review.
-
-Following the creation review, the EMO will initiate the provisioning process.
-To gain committer status, some <<paperwork,committer paperwork>> must be completed
-as part of the provisioning process. The exact nature of that
-paperwork depends on several factors, including the employment status
-of the individual and the Eclipse Foundation membership status of their employer.
-
-NOTE: If you can be ready with the paperwork in time for the completion of the
-creation review, then we can move quickly through the provisioning process.
-When we initiate provisioning, committers will be sent an email with
-instructions; please don't send any paperwork in until after you receive
-those instructions.
-
-[[starting-after-provisioning]]
-After Provisioning
-~~~~~~~~~~~~~~~~~~
-
-The Webmaster will send a note announcing the completion of the provisioning
-process. Before you commit any code into your project repository, you must
-submit your project's <<ip-initial-contribution,'initial contribution'>> and
-list of third-party libraries for review by the IP team.
-
-image::images/post-creation.png["Post creation activities"]
-
-Do not commit any code to your project's source code repository until after
-you receive approval for the IP Team. Once you've received that approval,
-you can do builds and produce milestones for your first release. You must
-wait until after the IP Team has approved your initial contribution and use
-of third-party libraries before you do any official <<release,releases>>.
-
-[[starting-project-phases]]
-Project Phases
-~~~~~~~~~~~~~~
-
-All new projects start in the 'incubation phase' (a project in the
-incubation phase is said to be 'incubating'). The classification of
-a project in the incubation phase is not a statement about the quality
-of the project's code; rather, incubation phase is more about the
-project team's progress in practicing the open and public processes
-necessary to establish the three communities (developers, adopters,
-and users) around the project.
-
-image::images/Egg-incubation.png["The Incubation Logo"]
-
-In order to alert potential consumers of the incubating nature,
-projects in the incubation phase must include 'incubation branding':
-
-* Display the incubation logo on their project web page (if they have one);
-* Displays the incubation logo on their project's primary download page;
-* Include the word "incubation" in the filename of all downloadable
-files (when technically feasible) for builds and milestones;
-* When technically feasible, include the word "incubation" in features
-(e.g. about dialogs, feature lists, and installers).
-
-There are no incubation branding requirements for general
-user interface elements.
-
-For projects that produce OSGi artifacts, include the word
-"incubation" in the 'Bundle-Name', feature names, and p2 repositories.
-
-NOTE: The word "incubation" should not be included in technical
-namespaces (especially when it may result in confusion when the project
-leaves incubation). e.g. an OSGi bundle's 'Bundle-SymbolicName', or a
-Java package name.
-
-Incubating projects that correctly conform to the incubation branding
-rules outlined above may take advantage of the <<ip-parallel-ip, Parallel
-IP Process>>. They are encouraged to produce milestone builds, make
-releases, and grow their community.
-
-When the project code is ready (e.g. stable APIs) and the project team
-has learned to operate as an open source project according to the
-Eclipse Development Process, the project may opt to 'graduate' into
-the 'mature phase'.
-
-Most of the lifetime of {aForgeName} project is spent in the mature phase.
-A mature project is one that is a good open source citizen with open,
-transparent, and meritocractic behavior. The project is regularly
-and predictably releasing IP clean extensible frameworks and
-exemplary tools. The project is actively nurturing the three
-communities: developers, adopters, and users.
-
-[[starting-faq]]
-Frequently Asked Questions
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-[qanda]
-How do I find Architecture Council mentors? ::
- You don't have to find them yourself. Focus on the content of the
- proposal. We can solicit mentors from the Architecture Council after
- the proposal has been opened for community review.
-
-Can I change the proposal after it is posted? ::
- Yes. The proposal can be changed any time before the start of the
- start of the creation review.
-
-When do I submit my code for review by the IP team? ::
- Submit your code (initial contribution) for review after the project
- has been provisioned. The Eclipse Webmaster will let you know via
- email when provisioning is complete.
-
-Does the new project have to use Git? ::
- Yes. Git is the only source code management system that is currently
- permitted for new projects.
-
-Can I host my project code on GitHub? ::
- New projects can make use of <<resources-github,GitHub>>. Official project repositories
- must be moved under the {gitHubUrl}[{forgeName} Organization] at GitHub.
- Official repositories are subject to the same intellectual
- property due diligence rules and processes that all Eclipse project
- repositories must follow.
-
-How long should I let my project incubate? ::
- It depends. Community expectations are one factor. Team experience
- with open source is another. If your team is new to open source,
- it may make sense to stay in incubation a little longer than a
- seasoned team with a mature code base might. As a general rule,
- though, projects should plan to leave incubation within a year.
-
-Does the mature project code that I'm bring to {forgeName} need to incubate? ::
- Yes. All new projects start in the incubation phase. Remember
- that incubation is as much about the project team learning about
- how to operate as an open source project as it is about the
- project code. Project teams that "get it" can opt to exit
- incubation quickly (e.g. with their first release) if that
- makes sense for the team and the community.
-
-What do all these terms (e.g. EMO) mean? ::
- Please see the <<glossary,glossary>>.
\ No newline at end of file
diff --git a/handbook/source/config.adoc b/handbook/source/config.adoc
deleted file mode 100644
index d43a18b..0000000
--- a/handbook/source/config.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-:emoEmail: emo@eclipse.org
-:ipTeamEmail: emo-ip-team@eclipse.org
-:emoRecordsEmail: emo-records@eclipse.org
-:webmasterEmail: webmaster@eclipse.org
-:proposalsForum: http://www.eclipse.org/forums/eclipse.proposals
-:activityUrl: http://www.eclipse.org/projects/project_activity.php
-:edpUrl: http://www.eclipse.org/projects/dev_process/development_process.php
-:trademarkTransferUrl: http://eclipse.org/legal/Trademark_Transfer_Agreement.pdf
-:trademarkGuidelinesUrl: https://eclipse.org/legal/logo_guidelines.php
-:copyrightUrl: https://www.eclipse.org/legal/copyrightandlicensenotice.php
-
-:developerPortalUrl: http://portal.eclipse.org
-:committerQuestionnaireUrl: http://portal.eclipse.org
-:ipDueDiligenceUrl: http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
-:ipThirdParty: http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
-:ipPolicyUrl: http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf
-:mcaUrl: http://www.eclipse.org/legal/committer_process/EclipseMemberCommitterAgreementFinal.pdf
-:icaUrl: http://www.eclipse.org/legal/committer_process/EclipseIndividualCommitterAgreementFinal.pdf
-:ececfUrl: http://www.eclipse.org/legal/committer_process/employer_consent.pdf
-:ipzillaUrl: https://dev.eclipse.org/ipzilla
-
-:cbiUrl: http://wiki.eclipse.org/CBI
-:gitRequestUrl: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Git
-:gitHubRequestUrl: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=GitHub
-:gerritRequestUrl: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Gerrit
-:websiteRequestUrl: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Website
-:claUrl: https://www.eclipse.org/legal/CLA.php
-:claSignUrl: https://projects.eclipse.org/user/sign/cla
-:cooUrl: https://eclipse.org/legal/CoO.php
-
-:jarSigningUrl: https://wiki.eclipse.org/JAR_Signing
-:downloadsUrl: https://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads
-
-:linkcss:
-:stylesdir: ./resources
-:scriptsdir: ./resources
-
-:toc:
-:toc-placement: auto
\ No newline at end of file
diff --git a/handbook/source/eclipse.adoc b/handbook/source/eclipse.adoc
deleted file mode 100644
index 7b5bc64..0000000
--- a/handbook/source/eclipse.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-include::config.adoc[]
-
-:forgeName: Eclipse
-:aforgeName: an Eclipse
-:namespace: org.eclipse
-:forgeUrl: https://projects.eclipse.org
-:createUrl: https://projects.eclipse.org/node/add/project-proposal
-:projectListUrl: http://projects.eclipse.org/list-of-projects
-:bugzillaUrl: https://bugs.eclipse.org/bugs
-:gitUrl: https://git.eclipse.org/c
-:gerritUrl: https://git.eclipse.org/r
-:gitHubUrl: https://github.com/eclipse
-:forumsUrl: http://www.eclipse.org/forums
-:mailingListsUrl: http://www.eclipse.org/mail/
-
-:pmiSampleImage: images/pmi-egit25.png
-
-Eclipse Project Handbook
-========================
-
-Copyright (C) 2015 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0
-
-include::chapters/preamble.adoc[]
-
-include::chapters/starting.adoc[]
-
-include::chapters/resources.adoc[]
-
-include::chapters/paperwork.adoc[]
-
-include::chapters/ip.adoc[]
-
-include::chapters/elections.adoc[]
-
-include::chapters/release.adoc[]
-
-include::chapters/pmi.adoc[]
-
-// include::chapters/community.adoc[]
-
-// include::chapters/links.adoc[]
-
-include::chapters/glossary.adoc[]
-
-include::chapters/contact.adoc[]
diff --git a/handbook/source/images/cq-workflow.dot b/handbook/source/images/cq-workflow.dot
deleted file mode 100644
index 484d0d1..0000000
--- a/handbook/source/images/cq-workflow.dot
+++ /dev/null
@@ -1,38 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
- graph [ranksep="0.25", nodesep="0.25"];
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12]
- search [label="Search for Existing CQ"]
- piggyback_create [label="Create Piggyback CQ", group=g1]
- piggyback_pmc [label="PMC Approval", group=g1]
- piggyback_ip_team [label="IP Team Approval", group=g1]
-
- new_create [label="Create CQ", group=g2]
- new_pmc [label="PMC Approval", group=g2]
- new_cursory [label="Cursory Legal Review\nParallel IP Check-in Approval", group=g2]
- new_detailed[ label="Detailed Legal Review", group=g2]
-
- final[label="Final Approval"]
-
- node [shape=diamond;style=filled;fillcolor=white;fontsize=10];
- search_found [label="Found?"]
- parallel [label="Parallel IP?", group=g2]
-
- search -> search_found
- search_found -> piggyback_create [label="Yes"]
- piggyback_create -> piggyback_pmc -> piggyback_ip_team -> final
-
- search_found -> new_create [label="No"]
- new_create -> new_pmc -> parallel
-
- parallel -> new_cursory [label="Yes"]
- new_cursory -> new_detailed
-
- parallel -> new_detailed [label="No"]
-
- new_detailed -> final
-}
\ No newline at end of file
diff --git a/handbook/source/images/ip-log-generator.dot b/handbook/source/images/ip-log-generator.dot
deleted file mode 100644
index 2d9b5b4..0000000
--- a/handbook/source/images/ip-log-generator.dot
+++ /dev/null
@@ -1,28 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
- graph [ranksep="0.25", nodesep="0.25"];
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12]
- git [label="Git", group="g1"]
- committer [label="Committer Activity\n(Git via Dash)", group="g2"]
- pmi [label="Repositories\n(PMI)", group="g1"]
- contributions [label="Git Contributions\n(Git via Dash)"]
- licenses [label="Licenses\n(Foundation DB)", group="g2"]
- generator [label="IP Log Generator", group="g1"]
- contributions_bugzilla [label="Contributions\n(Bugzilla)"]
- iplog [label="IP Log", group="g1"]
-
- git -> committer
- git -> contributions
- pmi -> generator
- pmi -> committer
- pmi -> contributions
- committer -> generator
- contributions -> generator
- licenses -> generator
- contributions_bugzilla ->generator
- generator -> iplog
-}
\ No newline at end of file
diff --git a/handbook/source/images/paperwork.dot b/handbook/source/images/paperwork.dot
deleted file mode 100644
index e28197c..0000000
--- a/handbook/source/images/paperwork.dot
+++ /dev/null
@@ -1,49 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
- graph [ranksep="0.25", nodesep="0.25"]
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12]
-
- start [label="Start"]
- ica_ececf [label="Submit an ICA\nand ECECF"]
- ica_contact [label="Submit an ICA\nand contact EMO Records"]
- mca [label="Submit an MCA"]
- final [label="You're done!"]
-
- node [shape=diamond;style=filled;fillcolor=white;fontsize=10];
-
- is_committer [label="Are you already\na committer?"]
- is_member [label="Do you work for\na member company?"]
- has_mca [label="Has your company\nprovided an MCA?"]
- can_mca [label="Can your company\nprovide an MCA?"]
- is_employed [label="Are you\nemployed?"]
- is_self_employed [label="Are you\nself-employed?"]
-
- start -> is_committer
-
- is_committer -> final [label="Yes"]
- is_committer -> is_member [label="No"]
-
- is_member -> has_mca [label="Yes"]
- is_member -> is_employed [label="No"]
-
- is_employed -> ica_ececf [label="Yes"]
- is_employed -> is_self_employed [label="No"]
-
- is_self_employed -> ica_ececf [label="Yes"]
- is_self_employed -> ica_contact [label="No"]
-
- has_mca -> final [label="Yes"]
- has_mca -> can_mca [label="No"]
-
- can_mca -> mca [label="Yes"]
- can_mca -> ica_ececf [label="No"]
-
- ica_ececf -> final
- ica_contact -> final
- mca -> final
-
-}
\ No newline at end of file
diff --git a/handbook/source/images/post-creation.dot b/handbook/source/images/post-creation.dot
deleted file mode 100644
index 037ffaa..0000000
--- a/handbook/source/images/post-creation.dot
+++ /dev/null
@@ -1,22 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12];
- ic[label="Submit\nInitial Contribution", group=g1];
- git[label="Push to Git", group=g1];
- build[label="Build and Distribute", group=g1];
-
- // Nodes that define things that we need
- node [shape=plaintext;fillcolor=transparent;fontsize=10]
- ip_approval [label="IP Team\nApproval"]
-
- // Stitch the key points together
- ic -> git -> build;
-
- // Use grey lines to add in the things we need
- edge [color=grey]
- ip_approval-> git
-}
\ No newline at end of file
diff --git a/handbook/source/images/project-creation.dot b/handbook/source/images/project-creation.dot
deleted file mode 100644
index cf2f8a4..0000000
--- a/handbook/source/images/project-creation.dot
+++ /dev/null
@@ -1,37 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12];
- proposal[label="Project Proposal", group=g1];
- community[label="Community Review", group=g1];
- review[label="Creation Review", group=g1];
- provision[label="Provision", group=g1]
-
- // Nodes that define things that we need
- node [shape=plaintext;fillcolor=transparent;fontsize=10]
- approval [label="EMO\nApproval"]
- trademark [label="Trademark\nReview"]
- mentors [label="Mentors"]
- paperwork [label="Committer\nPaperwork"]
-
- // Stitch the key points together
- proposal -> community -> review -> provision
-
- // Use grey lines to add in the things we need
- edge [color=grey]
- approval -> community
- mentors -> review
- trademark -> review
- paperwork -> provision
-
- // Force the trademark and mentors boxes to
- // be on either side of the main process points.
- // Do this by creating invisible lines that would
- // cross if they are on the same side.
- node[style=invis] ic
- edge [style=invis]
- trademark -> ic
- mentors->provision
-}
\ No newline at end of file
diff --git a/handbook/source/images/project-lifecycle.dot b/handbook/source/images/project-lifecycle.dot
deleted file mode 100644
index 644e3a4..0000000
--- a/handbook/source/images/project-lifecycle.dot
+++ /dev/null
@@ -1,20 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
- graph [ranksep="0.25", nodesep="0.25"];
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12]
- proposal [label="Proposal", group=g1]
- incubation [label="Incubation", group=g1]
- mature [label="Mature", group=g1]
- archived [label="Archived"]
-
- proposal -> incubation [label="Creation Review"]
- incubation -> mature [label="Graduation Review"]
- incubation:nw -> incubation:w [label="Release Review"]
- mature:nw -> mature:w [label="Release Review"]
- incubation -> archived [label="Termination Review"]
- mature -> archived [label="Termination Review"]
-}
\ No newline at end of file
diff --git a/handbook/source/images/release-cycle.dot b/handbook/source/images/release-cycle.dot
deleted file mode 100644
index 28f0e9a..0000000
--- a/handbook/source/images/release-cycle.dot
+++ /dev/null
@@ -1,20 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
- rankdir=LR
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12];
- plan[label="Capture Plan", group=g1];
- implement[label="Implement", group=g1];
- milestone[label="Produce\nMilestone", group=g1];
- release[label="Release"]
-
- plan-> implement
- milestone -> release
- release->plan
-
- edge [splines=curved]
- milestone -> implement
- implement -> milestone
-}
\ No newline at end of file
diff --git a/handbook/source/images/release-review.dot b/handbook/source/images/release-review.dot
deleted file mode 100644
index f05755a..0000000
--- a/handbook/source/images/release-review.dot
+++ /dev/null
@@ -1,18 +0,0 @@
-digraph {
- // Graph properties
- bgcolor=transparent
-
- // Nodes that define the key points in the process
- node [shape=box;style=filled;fillcolor=white;fontsize=12;width=2]
- doc [label="Assemble\nReview Documentation", group=g1]
- pmc [label="PMC Review\nDocumentation", group=g1]
- iplog [label="Assemble\nIP Log", group=g2]
- ipteam [label="IP Team Review\nIP Log", group=g2]
- start [label="Start\nRelease Review", group=g3]
- end [label="End\nRelease Review", group=g3]
- publish [label="Publish Release", group=g3]
-
- doc -> pmc -> start
- iplog -> ipteam -> start
- start -> end -> publish
-}
\ No newline at end of file
diff --git a/handbook/source/locationtech.adoc b/handbook/source/locationtech.adoc
deleted file mode 100644
index 113b462..0000000
--- a/handbook/source/locationtech.adoc
+++ /dev/null
@@ -1,41 +0,0 @@
-include::config.adoc[]
-
-:forgeName: LocationTech
-:aforgeName: a LocationTech
-:namespace: org.locationtech
-:forgeUrl: https://www.locationtech.org
-:createUrl: https://www.locationtech.org/node/add/project-proposal
-:projectListUrl: http://www.locationtech.org/list-of-projects
-:bugzillaUrl: https://www.locationtech.org/bugs
-:gitUrl: https://git.locationtech.org/c
-:gerritUrl: https://git.locationtech.org/r
-:gitHubUrl: https://github.com/locationtech
-:forumsUrl: http://www.locationtech.org/forums
-:mailingListsUrl: http://www.locationtech.org/mail/
-
-LocationTech Project Handbook
-=============================
-
-include::chapters/notices.adoc[]
-
-include::chapters/preamble.adoc[]
-
-include::chapters/starting.adoc[]
-
-include::chapters/resources.adoc[]
-
-include::chapters/paperwork.adoc[]
-
-include::chapters/ip.adoc[]
-
-include::chapters/release.adoc[]
-
-include::chapters/pmi.adoc[]
-
-// include::chapters/community.adoc[]
-
-// include::chapters/links.adoc[]
-
-include::chapters/glossary.adoc[]
-
-include::chapters/contact.adoc[]
diff --git a/handbook/source/makefile b/handbook/source/makefile
deleted file mode 100644
index bcd9cae..0000000
--- a/handbook/source/makefile
+++ /dev/null
@@ -1,98 +0,0 @@
-all : ../eclipse.html ../eclipse.pdf \
- ../polarsys.html ../polarsys.pdf \
- ../locationtech.html ../locationtech.pdf \
- images
-.PHONY : all
-
-# IMAGES
-
-images : \
- ../images/project-creation.png \
- ../images/post-creation.png \
- ../images/release-cycle.png \
- ../images/release-review.png \
- ../images/paperwork.png \
- ../images/cq-workflow.png \
- ../images/project-lifecycle.png \
- ../images/ip-log-generator.png
-.PHONY : all
-
-../images/project-creation.png : images/project-creation.dot
- dot -Tpng images/project-creation.dot > ../images/project-creation.png
-
-../images/post-creation.png : images/post-creation.dot
- dot -Tpng images/post-creation.dot > ../images/post-creation.png
-
-../images/release-cycle.png : images/release-cycle.dot
- dot -Tpng images/release-cycle.dot > ../images/release-cycle.png
-
-../images/release-review.png : images/release-review.dot
- dot -Tpng images/release-review.dot > ../images/release-review.png
-
-../images/paperwork.png : images/paperwork.dot
- dot -Tpng images/paperwork.dot > ../images/paperwork.png
-
-../images/cq-workflow.png : images/cq-workflow.dot
- dot -Tpng images/cq-workflow.dot > ../images/cq-workflow.png
-
-../images/project-lifecycle.png : images/project-lifecycle.dot
- dot -Tpng images/project-lifecycle.dot > ../images/project-lifecycle.png
-
-../images/ip-log-generator.png : images/ip-log-generator.dot
- dot -Tpng images/ip-log-generator.dot > ../images/ip-log-generator.png
-
-# ECLIPSE
-
-../eclipse.book.xml : eclipse.adoc config.adoc chapters/* images
- asciidoctor -b docbook -d book -o ../eclipse.book.xml eclipse.adoc
-
-../eclipse.html : eclipse.adoc config.adoc chapters/* images
- asciidoctor -a stylesheet=handbook.css -b html5 -d book -o ../eclipse.html eclipse.adoc
-
-#../eclipse.html : ../eclipse.book.xml
-# xsltproc -o ../eclipse.html /usr/share/sgml/docbook/xsl-ns-stylesheets/xhtml-1_1/docbook.xsl ../eclipse.book.xml
-
-../eclipse.pdf : ../eclipse.book.xml
- xsltproc -xinclude -o ../eclipse.fo \
- --param toc.section.depth 1 \
- --param ulink.footnotes 1 \
- --param admon.graphics 1 \
- --xinclude \
- /usr/share/sgml/docbook/xsl-ns-stylesheets/fo/docbook.xsl ../eclipse.book.xml
- fop -v ../eclipse.fo -pdf ../eclipse.pdf
- rm ../eclipse.fo
-
-
-# POLARSYS
-
-../polarsys.book.xml : polarsys.adoc config.adoc chapters/* images
- asciidoctor -b docbook -d book -o ../polarsys.book.xml polarsys.adoc
-
-../polarsys.html : polarsys.adoc config.adoc chapters/* images
- asciidoctor -a stylesheet=github.css -b html5 -d book -o ../polarsys.html polarsys.adoc
-
-../polarsys.pdf : ../polarsys.book.xml
- xsltproc -xinclude -o ../polarsys.fo \
- --param toc.section.depth 1 \
- --param ulink.footnotes 1 \
- --param admon.graphics 1 \
- /usr/share/sgml/docbook/xsl-ns-stylesheets/fo/docbook.xsl ../polarsys.book.xml
- fop -v ../polarsys.fo -pdf ../polarsys.pdf
- rm ../polarsys.fo
-
-# LOCATIONTECH
-
-../locationtech.book.xml : locationtech.adoc config.adoc chapters/* images
- asciidoctor -b docbook -d book -o ../locationtech.book.xml locationtech.adoc
-
-../locationtech.html : locationtech.adoc config.adoc chapters/* images
- asciidoctor -a stylesheet=github.css -b html5 -d book -o ../locationtech.html locationtech.adoc
-
-../locationtech.pdf : ../locationtech.book.xml
- xsltproc -xinclude -o ../locationtech.fo \
- --param toc.section.depth 1 \
- --param ulink.footnotes 1 \
- --param admon.graphics 1 \
- /usr/share/sgml/docbook/xsl-ns-stylesheets/fo/docbook.xsl ../locationtech.book.xml
- fop -v ../locationtech.fo -pdf ../locationtech.pdf
- rm ../locationtech.fo
\ No newline at end of file
diff --git a/handbook/source/polarsys.adoc b/handbook/source/polarsys.adoc
deleted file mode 100644
index f0626a9..0000000
--- a/handbook/source/polarsys.adoc
+++ /dev/null
@@ -1,41 +0,0 @@
-include::config.adoc[]
-
-:forgeName: PolarSys
-:aforgeName: a PolarSys
-:namespace: org.polarsys
-:forgeUrl: https://www.polarsys.org
-:createUrl: https://www.polarsys.org/node/add/project-proposal
-:projectListUrl: http://www.polarsys.org/list-of-projects
-:bugzillaUrl: https://www.polarsys.org/bugs
-:gitUrl: https://git.polarsys.org/c
-:gerritUrl: https://git.polarsys.org/r
-:gitHubUrl: https://github.com/polarsys
-:forumsUrl: http://www.polarsys.org/forums
-:mailingListsUrl: http://www.polarsys.org/mail/
-
-PolarSys Project Handbook
-=========================
-
-Copyright (C) 2015 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0
-
-include::chapters/preamble.adoc[]
-
-include::chapters/starting.adoc[]
-
-include::chapters/resources.adoc[]
-
-include::chapters/paperwork.adoc[]
-
-include::chapters/ip.adoc[]
-
-include::chapters/release.adoc[]
-
-include::chapters/pmi.adoc[]
-
-// include::chapters/community.adoc[]
-
-// include::chapters/links.adoc[]
-
-include::chapters/glossary.adoc[]
-
-include::chapters/contact.adoc[]
diff --git a/handbook/trademarks.html b/handbook/trademarks.html
deleted file mode 100644
index ddc26aa..0000000
--- a/handbook/trademarks.html
+++ /dev/null
@@ -1,784 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-<meta charset="UTF-8">
-<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-<meta name="generator" content="Asciidoctor 1.5.2">
-<title>Eclipse Project Branding Requirements</title>
-<style>
-.imageblock {
- text-align: center;
- margin-bottom: 10px;
-}
-
-.imageblock img {
- max-width: 100%;
-}
-#toc { border-bottom: 0 solid #dddddd; padding-bottom: 0.5em; }
-#toc > ul { margin-left: 0.13333em; }
-#toc ul.sectlevel0 > li > a { font-style: italic; }
-#toc ul.sectlevel0 ul.sectlevel1 { margin: 0.5em 0; }
-#toc ul { font-family: helvetica, arial, freesans, clean, sans-serif; list-style-type: none; }
-#toc a { text-decoration: none; }
-#toc a:active { text-decoration: underline; }
-
-div.admonitionblock {
- margin-bottom: 1em;
- margin-left: 3em;
- margin-right: 3em;
- padding: 3px;
- background-color: #EEEEEE;
- border-radius: 10px;
-}
-
-div.admonitionblock td.icon, td.content {
- vertical-align: top;
-}
-
-div.admonitionblock td.icon div.title {
- height: 35px;
- margin-left: 35px;
- margin-right: 1em;
- font-weight: bold;
-}
-
-div.admonitionblock div.title {
- visibility: hidden;
- width: 0;'
-}
-
-div.note td.icon {
- background-image: url("/projects/handbook/images/note.png");
- background-repeat: no-repeat;
-}
-
-div.warning td.icon {
- background-image: url("/projects/handbook/images/warning.png");
- background-repeat: no-repeat;
-}
-
-div.exampleblock {
- margin-left: 3em;
- margin-right: 3em;
- margin-bottom: 1em;
-}
-
-div.exampleblock div.title {
- font-style: italic;
-}
-
-div.exampleblock div.content {
- border-style: solid;
- border-width: 1px;
- padding: 5px;
-}
-
-div.listingblock {
- margin-bottom: 1em;
- margin-left: 3em;
- margin-right: 3em;
- padding: 3px;
-}
-
-div.ulist li {
- padding-bottom: 0;
- margin-bottom: 0;
-}
-
-div.ulist li p {
- padding-bottom: 0;
- margin-bottom: 2px;
-}
-
-div.olist li {
- padding-bottom: 0;
- margin-bottom: 0;
-}
-
-div.olist li p {
- padding-bottom: 0;
- margin-bottom: 2px;
-}
-
-div.colist {
- margin-left: 3em;
-}
-
-div.colist li {
- padding-bottom: 0;
- margin-bottom: 0;
-}
-
-div.colist li p {
- padding-bottom: 0;
- margin-bottom: 2px;
-}
-
-div.sect1 h2 {
- font-weight: bold;
- border-top-style: solid;
- border-top-width: 1px;
-}
-</style>
-</head>
-<body class="book">
-<div id="header">
-</div>
-<div id="content">
-<div class="sect1">
-<h2 id="_eclipse_project_branding_requirements">Eclipse Project Branding Requirements</h2>
-<div class="sectionbody">
-<div class="paragraph">
-<p>These Eclipse Project Branding Requirements define how Eclipse Projects
-must use and display all Eclipse Foundation trademarks as well as how
-they showcase their project’s website within the Eclipse Community and
-ecosystem. The requirements described here are a complement to the
-<a href="https://eclipse.org/legal/logo_guidelines.php">Guidelines
-for Eclipse Logos & Trademarks</a>, targeting Eclipse open source project
-leads and committers specifically.</p>
-</div>
-<div class="paragraph">
-<p>These requirements are meant to promote and improve the image of all
-projects that are part of the Eclipse community, as well as to show that
-all Eclipse Projects are part of our community of developers, adopters
-and users that we believe is an important factor in our mutual success.
-While every project manages their own development within the broader
-<a href="http://www.eclipse.org/projects/dev_process/development_process.php">Eclipse
-Development Process</a>, a consistent public branding and web presence that
-ties all of our projects together benefits all of us.</p>
-</div>
-<div class="paragraph">
-<p>All projects must conform to these branding requirements before engaging
-in any Release or Graduation Review.</p>
-</div>
-<div class="sect2">
-<h3 id="h.b6kgqhfkzush">Naming, Branding, and Trademarks</h3>
-<div class="paragraph">
-<p>Naming and branding are important issues for project teams to consider:
-both for the project’s future success as well as to help support and
-share the good values from the Eclipse brand itself. Not only can a
-memorable name help new users and contributors find a project, having a
-distinctive name makes the trademark much stronger, and ensures that
-third parties will respect it.</p>
-</div>
-<div class="paragraph">
-<p>To ensure that future trademarks conflicts don’t arise, it is necessary
-to show other parties that Eclipse Foundation trademarks were chosen in
-good faith and with appropriate research. The Eclipse Foundation has
-no business infringing on
-pre-existing trademarks for the software products or services from other
-organizations, whether they are Member organizations or not.</p>
-</div>
-<div class="paragraph">
-<p>All Eclipse projects and corresponding software products are trademarks
-of the Eclipse Foundation. As a legal entity, the Eclipse Foundation
-owns all Eclipse Project and corresponding product trademarks on behalf
-of the the Eclipse community. This prevents companies from misusing or
-misrepresenting their products as being the projects. The EMO will
-initiate a trademark review as part of the project creation or renaming
-process. Existing project name trademarks must be transferred to the
-Eclipse Foundation (please see the
-<a href="https://www.eclipse.org/legal/Trademark_Transfer_Agreement.pdf">Trademark
-Transfer Agreement</a>).</p>
-</div>
-<div class="paragraph">
-<p>Who needs these requirements?</p>
-</div>
-<div class="ulist">
-<ul>
-<li>
-<p>Project teams that want to name or rename a software product;</p>
-</li>
-<li>
-<p>Project teams that want to rename their project; and</p>
-</li>
-<li>
-<p>Anyone submitting a new project proposal</p>
-</li>
-</ul>
-</div>
-<div class="paragraph">
-<p>All project and product names must be vetted and approved by the Eclipse
-Management EMO.</p>
-</div>
-<div class="sect3">
-<h4 id="h.reywfp69spb">Registered Trademarks</h4>
-<div class="paragraph">
-<p>Project teams may request legal trademark registration for their project
-or product name. Since trademark registration requires a non-trivial
-investment in time and money, project teams must work with their PMC and
-the EMO to determine whether not trademark registration is necessary,
-determine in which countries the trademark must be registered, and how
-that registration will impact the project (e.g. adding registration
-marks on the website and in products).</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.146rbehl95bh">Other Organization’s Trademarks</h4>
-<div class="paragraph">
-<p>Project teams must ensure that products names that include other
-organizations’ trademarks in names must be conform to those
-organizations’ trademark usage guidelines. For example, "Eclipse Paho
-Perl" is not appropriate, since it improperly uses the trademark "Perl"
-(which is a trademark of The Perl Foundation); a better project name
-would be "Eclipse Paho for Perl".</p>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.962dim3i7th6">Choosing a Name</h3>
-<div class="paragraph">
-<p>Naming and branding are challenging issues that generally require some
-real investment in time and energy. The best project names are
-distinctive and memorable.</p>
-</div>
-<div class="paragraph">
-<p>Project teams should start the process of securing the trademark for a
-name as early as is practical. This is required to ensure the Eclipse
-Management Organization (EMO) has sufficient time to review and approve
-the name.</p>
-</div>
-<div class="paragraph">
-<p>A project team should start this process:</p>
-</div>
-<div class="ulist">
-<ul>
-<li>
-<p>When they first begin preparing a project proposal;</p>
-</li>
-<li>
-<p>As soon as their project wants to name a new software product; or</p>
-</li>
-<li>
-<p>Before initiating a Restructuring Review to change a project name</p>
-</li>
-</ul>
-</div>
-<div class="admonitionblock note">
-<table>
-<tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-Renaming projects (i.e. after a project has been created
-and provisioned) requires significant work on the part of the
-infrastructure team, and can be disruptive and confusing for consumers.
-Project teams should start the process as early as possible once they
-have a candidate name.
-</td>
-</tr>
-</table>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.ti4570gzv58s">Project Names</h3>
-<div class="paragraph">
-<p>A project, as defined by the Eclipse Development Process, is the main
-operational unit at the Eclipse Foundation; all open source software
-development at Eclipse occurs within the context of a project. The
-Eclipse Foundation holds the trademark for all Eclipse Projects.</p>
-</div>
-<div class="paragraph">
-<p>All project names must be approved by the Eclipse Management
-Organization (EMO) either before a project is created or before an
-existing project is renamed.</p>
-</div>
-<div class="sect3">
-<h4 id="h.6pz6nm9c7q39">Formal Name</h4>
-<div class="paragraph">
-<p>The primary branding for any project name is fully-qualified formal name
-which includes the “Eclipse” prefix (e.g. “Eclipse Woolsey Intellectual
-Property Tools” or “Eclipse Communication Framework”). This ensures that
-the Project is associated with the Eclipse Foundation in the community,
-ecosystem, and the minds of users and adopters. However, Eclipse
-Projects are oftentimes known by any names: it is common for a project
-to have both a formal and a nickname or commonly-used acronym.</p>
-</div>
-<div class="paragraph">
-<p>The formal name may include a brand name and/or a descriptive name.</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="_brand_names">Brand Names</h4>
-<div class="paragraph">
-<p>Project teams should strongly consider choosing a brand name. “Woolsey”,
-“Apogy”, and “Whiskers” are examples of brand names that are distinctive
-and memorable; they make the project easier to talk and write about than
-a wordier descriptive name. These names are not descriptive and so don’t
-stand well on their own; combining a brand name with a descriptive name
-(e.g. “Eclipse Woolsey Intellectual Property Tools”) can help in this
-regard.</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.x65x8wq641nq">Descriptive Names</h4>
-<div class="paragraph">
-<p>Projects are encouraged to use a descriptive name. Descriptive names
-provide context that can help a casual viewer appreciate the purpose of
-the project in way that is difficult or impossible to convey with a
-brand name "Graphical Modeling Framework", "Trust Framework" or "Component
-Assembly Tools" are examples of descriptive names..</p>
-</div>
-<div class="paragraph">
-<p>The best names do not include the word "Project", and are—in formal
-contexts—prepended by "Eclipse". The project name should still work with
-or without the prefix. For example, "Graphical Modeling Framework" and
-"Eclipse Graphical Modeling Framework" are equally understandable.</p>
-</div>
-<div class="paragraph">
-<p>Descriptive names may optionally include the words "Framework",
-“Platform”, or "Tools" if the project has a specific emphasis on
-extensible frameworks, a platform, or obvious development tooling
-technology. 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", “Platform”, and "Tools" mean different
-things to different people and may be becoming overused.</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.ubvtlm5grxk7">Nicknames</h4>
-<div class="paragraph">
-<p>A project may have a nickname or common name that is a shorter form of
-the formal name (and will likely be the same as the brand name). The
-“Eclipse Woolsey Intellectual Property Tools” project may be referred to
-as “Eclipse Woosley” or simply “Woolsey”. An acronym may be used as a
-nickname (e.g. “ECF” and “GMF”).</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.wrd8rx2f8n4a">Acronyms For Long Names</h4>
-<div class="paragraph">
-<p>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”.</p>
-</div>
-<div class="admonitionblock note">
-<table>
-<tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-Acronyms often become brand names.
-</td>
-</tr>
-</table>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.m2cirixjfmha">Existing Software Product Names</h4>
-<div class="paragraph">
-<p>To avoid confusion between Eclipse Projects and commercial products,
-Eclipse projects may not be named after commercial products and vice
-versa. To ensure that users understand the source of software
-products—i.e. from an Eclipse Foundation project, or from a third party
-vendor—the brand for an Eclipse project must not include or be directly
-reminiscent of a commercial product.</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.z1hf5g76cu2l">Short Names and Ids</h4>
-<div class="paragraph">
-<p>Projects require a short name; this name is used to as an ID for the
-project in various parts of Eclipse Foundation infrastructure and should
-be as reflective of the formal name as possible. It may, for example,
-be a lowercase rendering of the brand name, or an acronym of a
-descriptive name.</p>
-</div>
-<div class="paragraph">
-<p>The short name may contain lowercase alphanumeric characters, dashes,
-and underlines. The short name may not contain periods (.). Short names
-are used in URLs like <a href="http://www.eclipse.org/<shortname>" class="bare">http://www.eclipse.org/<shortname></a>;, project
-download directories, and in other parts of the supported
-infrastructure.</p>
-</div>
-<div class="paragraph">
-<p>The short name is joined with the short name of the parent project(s) to
-form a qualified identifier for the project that is used as a key on
-many of the webpages and services generated and/or maintained for the
-project by the Eclipse Foundation. e.g. the "Eclipse Woolsey" project
-has a short name of "woolsey"; its qualified name is
-"technology.dash.woolsey", indicating that it is a subproject of the
-Eclipse Dash Project which is itself a subproject of the Eclipse
-Technology Top Level Project.</p>
-</div>
-<div class="paragraph">
-<p>Project names should always be referred to in a consistent casing, and
-used as an adjective (never as a noun or verb) like any trademark should
-be used (e.g. "Download Eclipse Woolsey software here", using the
-Woolsey name as an adjective for software).</p>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.wm8ruxb5m3zs">Product Names</h3>
-<div class="paragraph">
-<p>A product is a specific, downloadable software product that users or
-consumers might want to use in some way. Most projects release a product
-with the same name (e.g. the Eclipse Woolsey project releases a software
-product called “Eclipse Woolsey”) or some variation of the project name
-(e.g. “Eclipse Woolsey SDK”).</p>
-</div>
-<div class="paragraph">
-<p>Most open source projects produce products that share the project name.
-There are, however, numerous examples of projects that produce
-additional products. The Eclipse CDO project, for example, has a product
-named “Dawn”; and the Eclipse Graphical Editing Framework project has a
-product named “Zest”.</p>
-</div>
-<div class="paragraph">
-<p>Product names should also be prefixed with “Eclipse” when used in any
-formal context (e.g. Eclipse Dawn or Eclipse Zest).</p>
-</div>
-<div class="paragraph">
-<p>Project teams should work with their PMC to determine whether or not to
-pursue assertion of ownership of the trademark for product names.
-Project teams should work with the Eclipse Management Organization (EMO)
-to assert ownership of product trademarks.</p>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.yapbxqmqhj65">Project Descriptions</h3>
-<div class="paragraph">
-<p>All Eclipse Projects require a description. The project description must
-include a brief sentence or short paragraph (no bullets) that explains
-the primary function of the software deliverables provided. For example:</p>
-</div>
-<div class="paragraph">
-<p>The Eclipse C/C Development Tooling™ (CDT) project provides a fully
-functional C and C Integrated Development Environment based on the
-Eclipse Platform.</p>
-</div>
-<div class="paragraph">
-<p>The complete description can certainly include much more information,
-but starting with a short paragraph is a great service for new readers
-to the project’s website, and is important for the Eclipse Foundation to
-maintain an overall list of project trademarks for software products.
-While this trademark description style may sometimes seem clumsy in
-technical documentation, it is a critical way that the Eclipse
-Foundation enforces trademarks.</p>
-</div>
-<div class="paragraph">
-<p>Project teams may seek guidance from the PMC and EMO to ensure that the
-text is a proper trademark goods description; i.e. one that describes
-the specific functionality of the software available for download and
-use.</p>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.ynnxj6b4xpu8">Logos And Graphics</h3>
-<div class="paragraph">
-<p>Logos are important to recognize as trademarks as well. For a project’s
-official logo (if it has one, and especially if it uses the Eclipse
-globe in any way), the designer must ensure that it includes a small
-trademark (™) or registered trademark (®) symbol (as appropriate) in
-the graphic or immediately adjacent to it.</p>
-</div>
-<div class="paragraph">
-<p>Projects may may request to use the Eclipse Logo within their project
-logo, or otherwise create a derivative of the Eclipse Logo. However,
-they must contact the EMO to request the Board’s permission to do so.</p>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.y7bttvnw7rhl">Project Websites</h3>
-<div class="paragraph">
-<p>The official project website is the primary means of learning about the
-project and getting involved: people who are interested in contributing
-to the project come here to learn about technical details, and to
-observe the project’s development process.</p>
-</div>
-<div class="paragraph">
-<p>Eclipse Projects must host all project content on an eclipse.org domain,
-especially the official/primary website for project-related information,
-communications, access to source code, and downloads. This ensures both
-that the Eclipse Webmaster team can maintain the services, and informs
-consumers that the content comes from an Eclipse Project, and not a
-third party. This further ensures that the project remains independent
-of any specific vendor or single individual.</p>
-</div>
-<div class="paragraph">
-<p>All primary links to the project (including, for example, the project’s
-contribution guide) must point directly to the official website, and not
-to external sites or domains.</p>
-</div>
-<div class="sect3">
-<h4 id="h.1u0ktwuf08ij">Names</h4>
-<div class="paragraph">
-<p>The first reference to a project or product on
-every web page—especially in page titles or headers—must use the formal
-name and must include the relevant trademark (™) or registered trademark
-(®) symbol (e.g. “Eclipse Woolsey Intellectual Property Tools™”). If the
-webpage features an otherwise prominent reference to the project or
-product (e.g. in a callout), that reference should also use the formal
-name. Other references may use the nickname or acronym (e.g. “Eclipse
-Woolsey” or “Woolsey”) as appropriate.</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="h.b778fjf5ft8t">Footers</h4>
-<div class="paragraph">
-<p>All project web pages must include a footer that prominently displays an
-approved Eclipse Logo, important links back to key pages, and a
-copyright notice.</p>
-</div>
-<div class="paragraph">
-<p>Approved Eclipse logos are available on the
-<a href="https://www.eclipse.org/artwork">Eclipse Logos and Artwork</a> page.</p>
-</div>
-<div class="paragraph">
-<p>The following minimal set of links must be included on the footer of all
-pages in the official project website:</p>
-</div>
-<div class="ulist">
-<ul>
-<li>
-<p>Main Eclipse Foundation website (<a href="http://www.eclipse.org" class="bare">http://www.eclipse.org</a>);</p>
-</li>
-<li>
-<p>Privacy policy (<a href="http://www.eclipse.org/legal/privacy.php" class="bare">http://www.eclipse.org/legal/privacy.php</a>);</p>
-</li>
-<li>
-<p>Website terms of use (<a href="http://www.eclipse.org/legal/termsofuse.php" class="bare">http://www.eclipse.org/legal/termsofuse.php</a>);</p>
-</li>
-<li>
-<p>Copyright agent (<a href="http://www.eclipse.org/legal/copyright.php" class="bare">http://www.eclipse.org/legal/copyright.php</a>); and</p>
-</li>
-<li>
-<p>Legal (<a href="http://www.eclipse.org/legal" class="bare">http://www.eclipse.org/legal</a>).</p>
-</li>
-</ul>
-</div>
-<div class="admonitionblock note">
-<table>
-<tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-An appropriate footer is included automatically by the default website
-infrastructure and the PMI.
-</td>
-</tr>
-</table>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.bz2cm9hgcd3w">External Websites</h3>
-<div class="paragraph">
-<p>Websites on external (non-eclipse.org) domains that
-use a project name trademark (e.g. www.mosquitto.com) but are not hosted
-by the Eclipse Foundation, may be employed as user community portals.
-External websites may be appropriate for some forms of documentation,
-community-generated content, and pointers to community forums. The user
-portal may help the user find information about what the project
-software does and how to get it.</p>
-</div>
-<div class="paragraph">
-<p>Only existing, well-known domains that are already heavily linked and
-known by the community are permitted as external domains. For other
-historical domains that are not an important part of the project’s
-brand, permanent (301) redirects should point to the official project
-website hosted on Eclipse Foundation infrastructure.</p>
-</div>
-<div class="paragraph">
-<p>The user portal is not a replacement for a developer portal which takes
-form in the official project website as described by this document.</p>
-</div>
-<div class="paragraph">
-<p>Projects with widely-used historical domain names may continue using the
-non-eclipse.org domain with these considerations:</p>
-</div>
-<div class="ulist">
-<ul>
-<li>
-<p>Ownership of the domain name must be transferred to the Eclipse
-Foundation;</p>
-</li>
-<li>
-<p>The domain must be regarded and treated as a user community portal;</p>
-</li>
-<li>
-<p>The first and most prominent reference to an Eclipse Project or
-corresponding product name on every web page must use the formal name
-and must include the relevant trademark or registered trademark symbol
-(subsequent references may use the nickname or acronym as appropriate);</p>
-</li>
-<li>
-<p>All references to Eclipse Project names must be prefixed with
-“Eclipse”;</p>
-</li>
-<li>
-<p>The website must include trademark attributions for all Eclipse
-Foundation trademarks used on the site (see below); and</p>
-</li>
-<li>
-<p>Contributors must be directed to the eclipse.org site for information
-regarding contribution or related development activities.</p>
-</li>
-</ul>
-</div>
-<div class="paragraph">
-<p>User-focused portals must include a prominent text paragraph or sidebar
-that points to the official project website, so that users interested in
-contributing or otherwise participating in the open source project know
-where to go.</p>
-</div>
-<div class="sect3">
-<h4 id="h.uta5gh156zpk">Trademark Attributions</h4>
-<div class="paragraph">
-<p>The external website must include a prominent trademark attribution of
-all applicable Eclipse Foundation marks.</p>
-</div>
-<div class="paragraph">
-<p>For example:</p>
-</div>
-<div class="paragraph">
-<p>Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey,
-Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are
-either registered trademarks or trademarks of The Eclipse Foundation in
-the United States and/or other countries.</p>
-</div>
-<div class="paragraph">
-<p>This can appear anywhere on the website.</p>
-</div>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.6xxbwuuh99bj">Project Metadata</h3>
-<div class="paragraph">
-<p>All Projects must keep their metadata updated regularly in the central
-<a href="http://www.eclipse.org/projects/handbook#pmi">Eclipse
-Project Management Infrastructure (PMI)</a> tool. Projects using alternate
-site content generation and management tools must ensure that all
-relevant metadata is kept up-to-date in the PMI tool to ensure that
-other infrastructure tools and processes can make connections to and
-disseminate information for the project.</p>
-</div>
-<div class="paragraph">
-<p>The project description, scope, and other free-form text fields in the
-PMI must conform to the project naming guidelines.</p>
-</div>
-<div class="admonitionblock note">
-<table>
-<tr>
-<td class="icon">
-<div class="title">Note</div>
-</td>
-<td class="content">
-The PMI supports teasers or summaries for many fields; ensure that
-these teasers also conform to the guidelines.
-</td>
-</tr>
-</table>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.39dgz1gp8r8c">Code Namespaces</h3>
-<div class="paragraph">
-<p>Where applicable and supported by the programming languages and style
-used by the project, code namespaces must include the project’s short
-name.</p>
-</div>
-<div class="paragraph">
-<p>In Java, for example, package names must start with org.eclipse and use
-their short name in the third-segment (i.e. follow the pattern
-org.eclipse.<shortname>.<component>), e.g. org.eclipse.ecf.core,
-org.eclipse.woolsey.ui, and org.eclipse.buckminster.connector. Component
-names are left to the discretion of the project team.</p>
-</div>
-<div class="paragraph">
-<p>The project team must petition the Planning Council via their PMC to
-request exceptions.</p>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.ghk7e08e0moa">Branding Checklist</h3>
-<div class="paragraph">
-<p>All projects must conform to these branding guidelines before engaging
-in any Release or Graduation Review.</p>
-</div>
-<div class="paragraph">
-<p>Project branding checklist:</p>
-</div>
-<div class="ulist">
-<ul>
-<li>
-<p>The primary development website is hosted on Eclipse
-Foundation-provided infrastructure;</p>
-</li>
-<li>
-<p>The primary development website is accessible through
-www.eclipse.org/<short-name>;</p>
-</li>
-<li>
-<p>The first occurrence of project name on all webpages uses the formal
-name and is prefixed with “Eclipse”;</p>
-</li>
-<li>
-<p>The project website includes a concise description of the project (and
-includes all necessary marks);</p>
-</li>
-<li>
-<p>The required navigation links (e.g. www.eclipse.org) are included in
-the website footer;</p>
-</li>
-<li>
-<p>Attributions for all Eclipse Foundation marks are included, and
-trademark and registered trademark symbols are used appropriately;</p>
-</li>
-<li>
-<p>Attributions for all other marks are included, and trademark and
-registered trademark symbols are used appropriately;</p>
-</li>
-<li>
-<p>Logos and graphics include the trademark symbol;</p>
-</li>
-<li>
-<p>The product logo is used consistently; and</p>
-</li>
-<li>
-<p>PMI metadata complete and up to date</p>
-</li>
-</ul>
-</div>
-</div>
-<div class="sect2">
-<h3 id="h.qu3cv297t11o">Important Note</h3>
-<div class="paragraph">
-<p>Nothing in this Eclipse Foundation document shall be interpreted
-to allow any third party to claim any association with the Eclipse
-Foundation or any of its projects or to imply any approval or support by
-the Eclipse Foundation for any third party products, services, or
-events, unless specifically covered by an Eclipse Membership agreement.</p>
-</div>
-<div class="paragraph">
-<p>Questions? Project participants who have questions about Eclipse
-Foundation trademarks either used here or at third party sites - should
-contact the EMO Trademarks. Other organizations looking for information
-on how to use or refer to any Eclipse Foundation project trademarks or
-logos should see the
-<a href="http://eclipse.org/legal/logo_guidelines.php">Guidelines
-for Eclipse Logos & Trademarks</a>. A list of Eclipse Foundation
-trademarks and guidelines for reporting potential misuses of marks are
-also available.</p>
-</div>
-<div class="paragraph">
-<p>Thanks and credit to the Apache Software Foundation’s
-<a href="http://www.apache.org/foundation/marks/pmcs">Project
-Branding Requirements</a>, licensed under the Apache License, v2.0.</p>
-</div>
-</div>
-</div>
-</div>
-</div>
-<div id="footer">
-<div id="footer-text">
-Last updated 2016-03-31 22:21:01 -04:00
-</div>
-</div>
-</body>
-</html>
\ No newline at end of file
diff --git a/handbook/trademarks.php b/handbook/trademarks.php
index 383be67..2bb5799 100644
--- a/handbook/trademarks.php
+++ b/handbook/trademarks.php
@@ -1,61 +1,3 @@
<?php
-/*******************************************************************************
- * Copyright (c) 2015 Eclipse Foundation and others.
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html
- *
- * Contributors:
- * Wayne Beaton - initial API and implementation
- *******************************************************************************/
-require_once ($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");
-require_once ($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
-require_once ($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");
-$App = new App();
-$Nav = new Nav();
-$Menu = new Menu();
-
-$pageKeywords = "";
-$pageTitle = "Eclipse Project Handbook - Trademarks Draft";
-$pageAuthor = "Wayne Beaton";
-
-$contents = file_get_contents("./trademarks.html");
-
-ob_start();
-?>
-<style>
-body {
- background-image: url("../dev_process/images/draft.gif");
-}
-</style>
-
-<div id="maincontent">
-<h1>Draft Document</h1>
-<p>
- <b>This is a draft document.</b> The content provided here will be merged into the
- <a href="index.php">Eclipse Project Handbook</a> and this page deleted before the end of June 2016.
-</p>
-
-<p>
- AsciiDoc sources are available through the Eclipse Foundation's
- <a href="https://git.eclipse.org/r/#/admin/projects/dash/org.eclipse.dash.handbook">Gerrit instance</a>.
-</p>
-
-<pre>
-git clone ssh://<uid>@git.eclipse.org:29418/dash/org.eclipse.dash.handbook
-</pre>
-
-<p>Look for <code>/source/chapters/trademarks.adoc</code>. Contributions through Gerrit are welcome.</p>
-
-<p>Discuss this draft on <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=484595">Bug 484595</a>.</p>
-
-<?php echo $contents; ?>
-
-</div>
-
-<?php
-$html = ob_get_contents();
-ob_end_clean();
-$App->generatePage(null, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html );
+header("Location:./index.php#trademarks")
?>
\ No newline at end of file
