diff --git a/efsp/_projectCommon.php b/efsp/_projectCommon.php
new file mode 100644
index 0000000..26ddec2
--- /dev/null
+++ b/efsp/_projectCommon.php
@@ -0,0 +1,29 @@
+<?php
+/**
+ * Copyright (c) 2021 Eclipse Foundation.
+ *
+ * This program and the accompanying materials are made
+ * available under the terms of the Eclipse Public License 2.0
+ * which is available at https://www.eclipse.org/legal/epl-2.0/
+ */
+
+require_once ($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
+
+$theme = NULL;
+$App->Promotion = TRUE;
+
+$Nav = new Nav();
+$Nav->addNavSeparator("Specification Process", "index.php");
+$Nav->addCustomNav("Operations", "operations.php", "_self", 1);
+
+$Nav->addNavSeparator("Development Process", "/projects/dev_process");
+$Nav->addCustomNav("Project Handbook", "/projects/handbook", "_self", 1);
+$Nav->addCustomNav("Intellectual Property Policy", "/org/documents/Eclipse_IP_Policy.pdf", "_self", 1);
+
+$Nav->addNavSeparator("Working Groups", "/org/workinggroups");
+$Nav->addCustomNav("Process", "/org/workinggroups/industry_wg_process.php", "_self", 1);
+$Nav->addCustomNav("Operations", "/org/workinggroups/operations.php", "_self", 1);
+
+$Nav->addNavSeparator("Eclipse Foundation", "index.php");
+$Nav->addCustomNav("Legal Resources", "/legal/", "_self", 1);
+$Nav->addCustomNav("Contact Us", "/org/foundation/contact.php", "_self", 1);
diff --git a/efsp/content/operations.html b/efsp/content/operations.html
new file mode 100644
index 0000000..b24baf1
--- /dev/null
+++ b/efsp/content/operations.html
@@ -0,0 +1,632 @@
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Version 1.0. Effective March 31/2021.</p>
+</div>
+<div id="toc" class="toc">
+<div id="toctitle" class="title">Table of Contents</div>
+<ul class="sectlevel1">
+<li><a href="#efspo-related">Related Documents</a></li>
+<li><a href="#efspo-projects">Projects and Specifications</a></li>
+<li><a href="#efspo-wg">Working Groups and Specifications</a></li>
+<li><a href="#roles">Roles</a>
+<ul class="sectlevel2">
+<li><a href="#efspo-spec-committee">Specification Committee</a></li>
+<li><a href="#efspo-roles-pl">Project Lead(s)</a></li>
+<li><a href="#efspo-roles-rep">Participant Representative</a></li>
+</ul>
+</li>
+<li><a href="#efspo-reviews">Reviews</a>
+<ul class="sectlevel2">
+<li><a href="#efspo-reviews-creation">Creation Reviews</a></li>
+<li><a href="#efspo-reviews-plan">Plan Reviews</a></li>
+<li><a href="#efspo-reviews-release">Release Reviews</a></li>
+<li><a href="#efspo-reviews-progress">Progress Reviews</a></li>
+</ul>
+</li>
+<li><a href="#efspo-ballots">Ballots</a>
+<ul class="sectlevel2">
+<li><a href="#efspo-ballot-release">Release Review Ballot Template</a></li>
+<li><a href="#efspo-ballot-restructure">Restructuring Review Ballot Template</a></li>
+<li><a href="#efspo-ballot-details">Details</a></li>
+</ul>
+</li>
+<li><a href="#efspo-specializing">Specializing the EFSP</a>
+<ul class="sectlevel2">
+<li><a href="#minimum-values">Minimum Values</a></li>
+<li><a href="#specializing-the-process">Specializing the Process</a></li>
+</ul>
+</li>
+<li><a href="#efspo-faq">Frequently Asked Questions</a></li>
+</ul>
+</div>
+<div class="paragraph">
+<p>This document describes the operation of the <a href="https://www.eclipse.org/projects/efsp">Eclipse Foundation Specification Process</a> (EFSP) for use by Eclipse Foundation Working Groups engaged in specification development.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-related"><a class="anchor" href="#efspo-related"></a><a class="link" href="#efspo-related">Related Documents</a></h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The <a href="https://www.eclipse.org/projects/efsp">Eclipse Foundation Specification Process</a> (EFSP) provides definitions and a framework for the governance of open source development of specifications at the Eclipse Foundation.</p>
+</div>
+<div class="paragraph">
+<p>The <a href="https://www.eclipse.org/projects/dev_process">Eclipse Foundation Development Process</a> (EDP) is the foundation upon which the EFSP is based. It provides definitions and a framework for the governance of open source development at the Eclipse Foundation.</p>
+</div>
+<div class="paragraph">
+<p>The <a href="http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse Foundation Intellectual Property (IP) Policy</a> describes the policies and mechanisms that the Eclipse Foundation uses for accepting and licensing the intellectual property developed by Eclipse projects and specifications.</p>
+</div>
+<div class="paragraph">
+<p>The <a href="https://www.eclipse.org/org/workinggroups/process.php">Eclipse Foundation Working Group Process</a> (EFWGP) defines the process for creating and managing Eclipse Foundation Working Groups, and how Eclipse Foundation members lead, influence, and collaborate within Working Groups. The corresponding <a href="https://www.eclipse.org/org/workinggroups/operations.php">Eclipse Foundation Working Group Operations Guide</a> describes the lifecycle and operation of Eclipse Foundation Working Groups.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-note" title="Note"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>In the event of a conflict between this document and the documents listed above, the documents listed above take precedence.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-projects"><a class="anchor" href="#efspo-projects"></a><a class="link" href="#efspo-projects">Projects and Specifications</a></h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The EFSP focuses on specification <em>projects</em> in matters of governance (e.g. project structure, committers and project leads). That is, in matters of governance, open source projects are the atomic unit.</p>
+</div>
+<div class="paragraph">
+<p><strong>Specification projects are a special type of open source project.</strong> In mathematical terms, a specification project (as defined by the EFSP) can be thought of as a subtype of project (as defined by the EDP). The EDP describes governance that applies to both projects and specification projects; the EFSP defines additional governance that applies to specification projects.</p>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiBjb250ZW50U2NyaXB0VHlwZT0iYXBwbGljYXRpb24vZWNtYXNjcmlwdCIgY29udGVudFN0eWxlVHlwZT0idGV4dC9jc3MiIGhlaWdodD0iMjkxcHgiIHByZXNlcnZlQXNwZWN0UmF0aW89Im5vbmUiIHN0eWxlPSJ3aWR0aDoxNjNweDtoZWlnaHQ6MjkxcHg7IiB2ZXJzaW9uPSIxLjEiIHZpZXdCb3g9IjAgMCAxNjMgMjkxIiB3aWR0aD0iMTYzcHgiIHpvb21BbmRQYW49Im1hZ25pZnkiPjxkZWZzLz48Zz48IS0tY2xhc3MgUHJvamVjdC0tPjxyZWN0IGZpbGw9IiNGOEY4RjgiIGhlaWdodD0iNDgiIHN0eWxlPSJzdHJva2U6ICMzODM4Mzg7IHN0cm9rZS13aWR0aDogMS41OyIgd2lkdGg9Ijc2IiB4PSI0NiIgeT0iOCIvPjxlbGxpcHNlIGN4PSI2MSIgY3k9IjI0IiBmaWxsPSIjQzJDMkMyIiByeD0iMTEiIHJ5PSIxMSIgc3R5bGU9InN0cm9rZTogIzM4MzgzODsgc3Ryb2tlLXdpZHRoOiAxLjA7Ii8+PHBhdGggZD0iTTYzLjk2ODgsMjkuNjQwNiBRNjMuMzkwNiwyOS45Mzc1IDYyLjc1LDMwLjA3ODEgUTYyLjEwOTQsMzAuMjM0NCA2MS40MDYzLDMwLjIzNDQgUTU4LjkwNjMsMzAuMjM0NCA1Ny41NzgxLDI4LjU5MzggUTU2LjI2NTYsMjYuOTM3NSA1Ni4yNjU2LDIzLjgxMjUgUTU2LjI2NTYsMjAuNjg3NSA1Ny41NzgxLDE5LjAzMTMgUTU4LjkwNjMsMTcuMzc1IDYxLjQwNjMsMTcuMzc1IFE2Mi4xMDk0LDE3LjM3NSA2Mi43NSwxNy41MzEzIFE2My40MDYzLDE3LjY4NzUgNjMuOTY4OCwxNy45ODQ0IEw2My45Njg4LDIwLjcwMzEgUTYzLjM0MzgsMjAuMTI1IDYyLjc1LDE5Ljg1OTQgUTYyLjE1NjMsMTkuNTc4MSA2MS41MzEzLDE5LjU3ODEgUTYwLjE4NzUsMTkuNTc4MSA1OS41LDIwLjY1NjMgUTU4LjgxMjUsMjEuNzE4OCA1OC44MTI1LDIzLjgxMjUgUTU4LjgxMjUsMjUuOTA2MyA1OS41LDI2Ljk4NDQgUTYwLjE4NzUsMjguMDQ2OSA2MS41MzEzLDI4LjA0NjkgUTYyLjE1NjMsMjguMDQ2OSA2Mi43NSwyNy43ODEzIFE2My4zNDM4LDI3LjUgNjMuOTY4OCwyNi45MjE5IEw2My45Njg4LDI5LjY0MDYgWiAiLz48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMiIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nQW5kR2x5cGhzIiB0ZXh0TGVuZ3RoPSI0NCIgeD0iNzUiIHk9IjI4LjE1NDMiPlByb2plY3Q8L3RleHQ+PGxpbmUgc3R5bGU9InN0cm9rZTogIzM4MzgzODsgc3Ryb2tlLXdpZHRoOiAxLjU7IiB4MT0iNDciIHgyPSIxMjEiIHkxPSI0MCIgeTI9IjQwIi8+PGxpbmUgc3R5bGU9InN0cm9rZTogIzM4MzgzODsgc3Ryb2tlLXdpZHRoOiAxLjU7IiB4MT0iNDciIHgyPSIxMjEiIHkxPSI0OCIgeTI9IjQ4Ii8+PCEtLWNsYXNzIFNwZWNpZmljYXRpb25Qcm9qZWN0LS0+PHJlY3QgZmlsbD0iI0Y4RjhGOCIgaGVpZ2h0PSI0OCIgc3R5bGU9InN0cm9rZTogIzM4MzgzODsgc3Ryb2tlLXdpZHRoOiAxLjU7IiB3aWR0aD0iMTU2IiB4PSI2IiB5PSIxMzMiLz48ZWxsaXBzZSBjeD0iMjEiIGN5PSIxNDkiIGZpbGw9IiNDMkMyQzIiIHJ4PSIxMSIgcnk9IjExIiBzdHlsZT0ic3Ryb2tlOiAjMzgzODM4OyBzdHJva2Utd2lkdGg6IDEuMDsiLz48cGF0aCBkPSJNMjMuOTY4OCwxNTQuNjQwNiBRMjMuMzkwNiwxNTQuOTM3NSAyMi43NSwxNTUuMDc4MSBRMjIuMTA5NCwxNTUuMjM0NCAyMS40MDYzLDE1NS4yMzQ0IFExOC45MDYzLDE1NS4yMzQ0IDE3LjU3ODEsMTUzLjU5MzggUTE2LjI2NTYsMTUxLjkzNzUgMTYuMjY1NiwxNDguODEyNSBRMTYuMjY1NiwxNDUuNjg3NSAxNy41NzgxLDE0NC4wMzEzIFExOC45MDYzLDE0Mi4zNzUgMjEuNDA2MywxNDIuMzc1IFEyMi4xMDk0LDE0Mi4zNzUgMjIuNzUsMTQyLjUzMTMgUTIzLjQwNjMsMTQyLjY4NzUgMjMuOTY4OCwxNDIuOTg0NCBMMjMuOTY4OCwxNDUuNzAzMSBRMjMuMzQzOCwxNDUuMTI1IDIyLjc1LDE0NC44NTk0IFEyMi4xNTYzLDE0NC41NzgxIDIxLjUzMTMsMTQ0LjU3ODEgUTIwLjE4NzUsMTQ0LjU3ODEgMTkuNSwxNDUuNjU2MyBRMTguODEyNSwxNDYuNzE4OCAxOC44MTI1LDE0OC44MTI1IFExOC44MTI1LDE1MC45MDYzIDE5LjUsMTUxLjk4NDQgUTIwLjE4NzUsMTUzLjA0NjkgMjEuNTMxMywxNTMuMDQ2OSBRMjIuMTU2MywxNTMuMDQ2OSAyMi43NSwxNTIuNzgxMyBRMjMuMzQzOCwxNTIuNSAyMy45Njg4LDE1MS45MjE5IEwyMy45Njg4LDE1NC42NDA2IFogIi8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTIiIGxlbmd0aEFkanVzdD0ic3BhY2luZ0FuZEdseXBocyIgdGV4dExlbmd0aD0iMTI0IiB4PSIzNSIgeT0iMTUzLjE1NDMiPlNwZWNpZmljYXRpb25Qcm9qZWN0PC90ZXh0PjxsaW5lIHN0eWxlPSJzdHJva2U6ICMzODM4Mzg7IHN0cm9rZS13aWR0aDogMS41OyIgeDE9IjciIHgyPSIxNjEiIHkxPSIxNjUiIHkyPSIxNjUiLz48bGluZSBzdHlsZT0ic3Ryb2tlOiAjMzgzODM4OyBzdHJva2Utd2lkdGg6IDEuNTsiIHgxPSI3IiB4Mj0iMTYxIiB5MT0iMTczIiB5Mj0iMTczIi8+PCEtLWNsYXNzIFNwZWNpZmljYXRpb24tLT48cmVjdCBmaWxsPSIjRjhGOEY4IiBoZWlnaHQ9IjQ4IiBzdHlsZT0ic3Ryb2tlOiAjMzgzODM4OyBzdHJva2Utd2lkdGg6IDEuNTsiIHdpZHRoPSIxMTIiIHg9IjI4IiB5PSIyNDIiLz48ZWxsaXBzZSBjeD0iNDMiIGN5PSIyNTgiIGZpbGw9IiNDMkMyQzIiIHJ4PSIxMSIgcnk9IjExIiBzdHlsZT0ic3Ryb2tlOiAjMzgzODM4OyBzdHJva2Utd2lkdGg6IDEuMDsiLz48cGF0aCBkPSJNNDUuOTY4OCwyNjMuNjQwNiBRNDUuMzkwNiwyNjMuOTM3NSA0NC43NSwyNjQuMDc4MSBRNDQuMTA5NCwyNjQuMjM0NCA0My40MDYzLDI2NC4yMzQ0IFE0MC45MDYzLDI2NC4yMzQ0IDM5LjU3ODEsMjYyLjU5MzggUTM4LjI2NTYsMjYwLjkzNzUgMzguMjY1NiwyNTcuODEyNSBRMzguMjY1NiwyNTQuNjg3NSAzOS41NzgxLDI1My4wMzEzIFE0MC45MDYzLDI1MS4zNzUgNDMuNDA2MywyNTEuMzc1IFE0NC4xMDk0LDI1MS4zNzUgNDQuNzUsMjUxLjUzMTMgUTQ1LjQwNjMsMjUxLjY4NzUgNDUuOTY4OCwyNTEuOTg0NCBMNDUuOTY4OCwyNTQuNzAzMSBRNDUuMzQzOCwyNTQuMTI1IDQ0Ljc1LDI1My44NTk0IFE0NC4xNTYzLDI1My41NzgxIDQzLjUzMTMsMjUzLjU3ODEgUTQyLjE4NzUsMjUzLjU3ODEgNDEuNSwyNTQuNjU2MyBRNDAuODEyNSwyNTUuNzE4OCA0MC44MTI1LDI1Ny44MTI1IFE0MC44MTI1LDI1OS45MDYzIDQxLjUsMjYwLjk4NDQgUTQyLjE4NzUsMjYyLjA0NjkgNDMuNTMxMywyNjIuMDQ2OSBRNDQuMTU2MywyNjIuMDQ2OSA0NC43NSwyNjEuNzgxMyBRNDUuMzQzOCwyNjEuNSA0NS45Njg4LDI2MC45MjE5IEw0NS45Njg4LDI2My42NDA2IFogIi8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTIiIGxlbmd0aEFkanVzdD0ic3BhY2luZ0FuZEdseXBocyIgdGV4dExlbmd0aD0iODAiIHg9IjU3IiB5PSIyNjIuMTU0MyI+U3BlY2lmaWNhdGlvbjwvdGV4dD48bGluZSBzdHlsZT0ic3Ryb2tlOiAjMzgzODM4OyBzdHJva2Utd2lkdGg6IDEuNTsiIHgxPSIyOSIgeDI9IjEzOSIgeTE9IjI3NCIgeTI9IjI3NCIvPjxsaW5lIHN0eWxlPSJzdHJva2U6ICMzODM4Mzg7IHN0cm9rZS13aWR0aDogMS41OyIgeDE9IjI5IiB4Mj0iMTM5IiB5MT0iMjgyIiB5Mj0iMjgyIi8+PHBhdGggZD0iTTg0LDc2LjE3IEM4NCw5NS4yOSA4NCwxMTcuMDIgODQsMTMyLjk3ICIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTogIzM4MzgzODsgc3Ryb2tlLXdpZHRoOiAxLjA7Ii8+PHBvbHlnb24gZmlsbD0ibm9uZSIgcG9pbnRzPSI3Nyw3Ni4xNCw4NCw1Ni4xNCw5MSw3Ni4xNCw3Nyw3Ni4xNCIgc3R5bGU9InN0cm9rZTogIzM4MzgzODsgc3Ryb2tlLXdpZHRoOiAxLjA7Ii8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTMiIGxlbmd0aEFkanVzdD0ic3BhY2luZ0FuZEdseXBocyIgdGV4dExlbmd0aD0iNTEiIHg9Ijg1IiB5PSI5OS4wNjY5Ij5zdWJ0eXBlPC90ZXh0PjxwYXRoIGQ9Ik04NCwxOTQuMyBDODQsMjEwLjAyIDg0LDIyNy45NiA4NCwyNDEuODMgIiBmaWxsPSJub25lIiBzdHlsZT0ic3Ryb2tlOiAjMzgzODM4OyBzdHJva2Utd2lkdGg6IDEuMDsiLz48cG9seWdvbiBmaWxsPSIjMzgzODM4IiBwb2ludHM9Ijg0LDE4MS4yMiw4MCwxODcuMjIsODQsMTkzLjIyLDg4LDE4Ny4yMiw4NCwxODEuMjIiIHN0eWxlPSJzdHJva2U6ICMzODM4Mzg7IHN0cm9rZS13aWR0aDogMS4wOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEzIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmdBbmRHbHlwaHMiIHRleHRMZW5ndGg9IjgiIHg9Ijc1LjAyNSIgeT0iMjAxLjAzNDgiPjE8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTMiIGxlbmd0aEFkanVzdD0ic3BhY2luZ0FuZEdseXBocyIgdGV4dExlbmd0aD0iMjQiIHg9IjU2LjkyNSIgeT0iMjMwLjc5ODUiPjEuLm48L3RleHQ+PC9nPjwvc3ZnPg==" alt="Specification Project (EFSP) is a subtype of project (EDP) that contains specifications." width="163" height="291"/>
+</div>
+<div class="title">Specification Project (EFSP) is a subtype of project (EDP) that contains specifications.</div>
+</div>
+<div class="paragraph">
+<p><strong>A specification project may be the host of more than one specification.</strong></p>
+</div>
+<div class="paragraph">
+<p><strong>A specification project may have more than one Git repository.</strong></p>
+</div>
+<div class="paragraph">
+<p><strong>Git repositories are assigned to <em>projects</em> not <em>specifications</em>.</strong> Project resources, like Git repositories, are managed by the Eclipse Foundation at the <em>project</em> level.</p>
+</div>
+<div class="paragraph">
+<p><strong>Committer status is granted on <em>projects</em> not <em>specifications</em>.</strong> That is an individual is said to be a committer on the corresponding <em>project</em>, and as such has committer-level access to all resources assigned to the project. In the case of specification projects that manage the lifecycle of multiple specifications, all committers have the same level of access to all resources (e.g., Git repositories) allocated for all specifications.</p>
+</div>
+<div class="paragraph">
+<p><strong>There is no formal notion of <em>specification</em> lead.</strong> Specification projects must have one or more <a href="#efspo-roles-pl">project leads</a>, as that role is defined in the EDP. Specification projects may choose to have a de facto notion of a specification lead, but that role has no formal standing in the specification process.</p>
+</div>
+<div class="paragraph">
+<p><strong>Development of a new version of an existing specification occurs in the context of the existing specification project.</strong> That is, the specification project, along with its team of committers and associated resources, persists beyond the release of any particular version of a specification. After a specification is released, the same specification project with its associated committers and resources are used to plan, develop, and release subsequent versions of the specification.</p>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+CjwhRE9DVFlQRSBzdmcgUFVCTElDICItLy9XM0MvL0RURCBTVkcgMS4xLy9FTiIKICJodHRwOi8vd3d3LnczLm9yZy9HcmFwaGljcy9TVkcvMS4xL0RURC9zdmcxMS5kdGQiPgo8IS0tIEdlbmVyYXRlZCBieSBncmFwaHZpeiB2ZXJzaW9uIDIuNDIuNCAoMCkKIC0tPgo8IS0tIFBhZ2VzOiAxIC0tPgo8c3ZnIHdpZHRoPSI0NTFwdCIgaGVpZ2h0PSIxODhwdCIKIHZpZXdCb3g9IjAuMDAgMC4wMCA0NTEuMDAgMTg4LjAwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj4KPGcgaWQ9ImdyYXBoMCIgY2xhc3M9ImdyYXBoIiB0cmFuc2Zvcm09InNjYWxlKDEgMSkgcm90YXRlKDApIHRyYW5zbGF0ZSg0IDE4NCkiPgo8IS0tIHN0YXJ0IC0tPgo8ZyBpZD0ibm9kZTEiIGNsYXNzPSJub2RlIj4KPHRpdGxlPnN0YXJ0PC90aXRsZT4KPGVsbGlwc2UgZmlsbD0id2hpdGUiIHN0cm9rZT0iYmxhY2siIGN4PSIzOCIgY3k9Ii0xNjIiIHJ4PSIxOCIgcnk9IjE4Ii8+CjwvZz4KPCEtLSBwcm9wb3NhbCAtLT4KPGcgaWQ9Im5vZGUyIiBjbGFzcz0ibm9kZSI+Cjx0aXRsZT5wcm9wb3NhbDwvdGl0bGU+CjxwYXRoIGZpbGw9IndoaXRlIiBzdHJva2U9ImJsYWNrIiBkPSJNMTMzLjUsLTE4MEMxMzMuNSwtMTgwIDg2LjUsLTE4MCA4Ni41LC0xODAgODAuNSwtMTgwIDc0LjUsLTE3NCA3NC41LC0xNjggNzQuNSwtMTY4IDc0LjUsLTE1NiA3NC41LC0xNTYgNzQuNSwtMTUwIDgwLjUsLTE0NCA4Ni41LC0xNDQgODYuNSwtMTQ0IDEzMy41LC0xNDQgMTMzLjUsLTE0NCAxMzkuNSwtMTQ0IDE0NS41LC0xNTAgMTQ1LjUsLTE1NiAxNDUuNSwtMTU2IDE0NS41LC0xNjggMTQ1LjUsLTE2OCAxNDUuNSwtMTc0IDEzOS41LC0xODAgMTMzLjUsLTE4MCIvPgo8dGV4dCB0ZXh0LWFuY2hvcj0ibWlkZGxlIiB4PSIxMTAiIHk9Ii0xNTguOSIgZm9udC1mYW1pbHk9IlRpbWVzLHNlcmlmIiBmb250LXNpemU9IjEyLjAwIj5Qcm9wb3NhbDwvdGV4dD4KPC9nPgo8IS0tIHN0YXJ0JiM0NTsmZ3Q7cHJvcG9zYWwgLS0+CjxnIGlkPSJlZGdlMSIgY2xhc3M9ImVkZ2UiPgo8dGl0bGU+c3RhcnQmIzQ1OyZndDtwcm9wb3NhbDwvdGl0bGU+CjxwYXRoIGZpbGw9Im5vbmUiIHN0cm9rZT0iYmxhY2siIGQ9Ik01Ni4xNywtMTYyQzU2LjE3LC0xNjIgNjQuNDMsLTE2MiA2NC40MywtMTYyIi8+Cjxwb2x5Z29uIGZpbGw9ImJsYWNrIiBzdHJva2U9ImJsYWNrIiBwb2ludHM9IjY0LjQzLC0xNjUuNSA3NC40MywtMTYyIDY0LjQzLC0xNTguNSA2NC40MywtMTY1LjUiLz4KPC9nPgo8IS0tIGNyZWF0aW9uX3JldmlldyAtLT4KPGcgaWQ9Im5vZGUzIiBjbGFzcz0ibm9kZSI+Cjx0aXRsZT5jcmVhdGlvbl9yZXZpZXc8L3RpdGxlPgo8cG9seWdvbiBmaWxsPSJ3aGl0ZSIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIyMzIuNSwtMTgwIDE2My41LC0xODAgMTYzLjUsLTE0NCAyMzIuNSwtMTQ0IDIzMi41LC0xODAiLz4KPHRleHQgdGV4dC1hbmNob3I9Im1pZGRsZSIgeD0iMTk4IiB5PSItMTY1LjQiIGZvbnQtZmFtaWx5PSJUaW1lcyxzZXJpZiIgZm9udC1zaXplPSIxMi4wMCI+Q3JlYXRpb248L3RleHQ+Cjx0ZXh0IHRleHQtYW5jaG9yPSJtaWRkbGUiIHg9IjE5OCIgeT0iLTE1Mi40IiBmb250LWZhbWlseT0iVGltZXMsc2VyaWYiIGZvbnQtc2l6ZT0iMTIuMDAiPlJldmlldzwvdGV4dD4KPC9nPgo8IS0tIHByb3Bvc2FsJiM0NTsmZ3Q7Y3JlYXRpb25fcmV2aWV3IC0tPgo8ZyBpZD0iZWRnZTIiIGNsYXNzPSJlZGdlIj4KPHRpdGxlPnByb3Bvc2FsJiM0NTsmZ3Q7Y3JlYXRpb25fcmV2aWV3PC90aXRsZT4KPHBhdGggZmlsbD0ibm9uZSIgc3Ryb2tlPSJibGFjayIgZD0iTTE0NS41NCwtMTYyQzE0NS41NCwtMTYyIDE1My40NywtMTYyIDE1My40NywtMTYyIi8+Cjxwb2x5Z29uIGZpbGw9ImJsYWNrIiBzdHJva2U9ImJsYWNrIiBwb2ludHM9IjE1My40NywtMTY1LjUgMTYzLjQ3LC0xNjIgMTUzLjQ3LC0xNTguNSAxNTMuNDcsLTE2NS41Ii8+CjwvZz4KPCEtLSBkZXZlbG9wbWVudCAtLT4KPGcgaWQ9Im5vZGU2IiBjbGFzcz0ibm9kZSI+Cjx0aXRsZT5kZXZlbG9wbWVudDwvdGl0bGU+Cjxwb2x5Z29uIGZpbGw9IndoaXRlIiBzdHJva2U9ImJsYWNrIiBwb2ludHM9IjI0NS41LC0xMDggMTUwLjUsLTEwOCAxNTAuNSwtNzIgMjQ1LjUsLTcyIDI0NS41LC0xMDgiLz4KPHRleHQgdGV4dC1hbmNob3I9Im1pZGRsZSIgeD0iMTk4IiB5PSItODYuOSIgZm9udC1mYW1pbHk9IlRpbWVzLHNlcmlmIiBmb250LXNpemU9IjEyLjAwIj5EZXZlbG9wbWVudDwvdGV4dD4KPC9nPgo8IS0tIGNyZWF0aW9uX3JldmlldyYjNDU7Jmd0O2RldmVsb3BtZW50IC0tPgo8ZyBpZD0iZWRnZTMiIGNsYXNzPSJlZGdlIj4KPHRpdGxlPmNyZWF0aW9uX3JldmlldyYjNDU7Jmd0O2RldmVsb3BtZW50PC90aXRsZT4KPHBhdGggZmlsbD0ibm9uZSIgc3Ryb2tlPSJibGFjayIgZD0iTTE5OCwtMTQzLjgzQzE5OCwtMTQzLjgzIDE5OCwtMTE4LjQxIDE5OCwtMTE4LjQxIi8+Cjxwb2x5Z29uIGZpbGw9ImJsYWNrIiBzdHJva2U9ImJsYWNrIiBwb2ludHM9IjIwMS41LC0xMTguNDEgMTk4LC0xMDguNDEgMTk0LjUsLTExOC40MSAyMDEuNSwtMTE4LjQxIi8+CjwvZz4KPCEtLSBwbGFuIC0tPgo8ZyBpZD0ibm9kZTQiIGNsYXNzPSJub2RlIj4KPHRpdGxlPnBsYW48L3RpdGxlPgo8cG9seWdvbiBmaWxsPSJ3aGl0ZSIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSI1NCwtMTA4IDAsLTEwOCAwLC03MiA1NCwtNzIgNTQsLTEwOCIvPgo8dGV4dCB0ZXh0LWFuY2hvcj0ibWlkZGxlIiB4PSIyNyIgeT0iLTg2LjkiIGZvbnQtZmFtaWx5PSJUaW1lcyxzZXJpZiIgZm9udC1zaXplPSIxMi4wMCI+UGxhbjwvdGV4dD4KPC9nPgo8IS0tIHBsYW5fcmV2aWV3IC0tPgo8ZyBpZD0ibm9kZTUiIGNsYXNzPSJub2RlIj4KPHRpdGxlPnBsYW5fcmV2aWV3PC90aXRsZT4KPHBvbHlnb24gZmlsbD0id2hpdGUiIHN0cm9rZT0iYmxhY2siIHBvaW50cz0iMTMyLC0xMDggNzIsLTEwOCA3MiwtNzIgMTMyLC03MiAxMzIsLTEwOCIvPgo8dGV4dCB0ZXh0LWFuY2hvcj0ibWlkZGxlIiB4PSIxMDIiIHk9Ii05My40IiBmb250LWZhbWlseT0iVGltZXMsc2VyaWYiIGZvbnQtc2l6ZT0iMTIuMDAiPlBsYW48L3RleHQ+Cjx0ZXh0IHRleHQtYW5jaG9yPSJtaWRkbGUiIHg9IjEwMiIgeT0iLTgwLjQiIGZvbnQtZmFtaWx5PSJUaW1lcyxzZXJpZiIgZm9udC1zaXplPSIxMi4wMCI+UmV2aWV3PC90ZXh0Pgo8L2c+CjwhLS0gcGxhbiYjNDU7Jmd0O3BsYW5fcmV2aWV3IC0tPgo8ZyBpZD0iZWRnZTQiIGNsYXNzPSJlZGdlIj4KPHRpdGxlPnBsYW4mIzQ1OyZndDtwbGFuX3JldmlldzwvdGl0bGU+CjxwYXRoIGZpbGw9Im5vbmUiIHN0cm9rZT0iYmxhY2siIGQ9Ik01NC4wOCwtOTBDNTQuMDgsLTkwIDYxLjkxLC05MCA2MS45MSwtOTAiLz4KPHBvbHlnb24gZmlsbD0iYmxhY2siIHN0cm9rZT0iYmxhY2siIHBvaW50cz0iNjEuOTEsLTkzLjUgNzEuOTEsLTkwIDYxLjkxLC04Ni41IDYxLjkxLC05My41Ii8+CjwvZz4KPCEtLSBwbGFuX3JldmlldyYjNDU7Jmd0O2RldmVsb3BtZW50IC0tPgo8ZyBpZD0iZWRnZTUiIGNsYXNzPSJlZGdlIj4KPHRpdGxlPnBsYW5fcmV2aWV3JiM0NTsmZ3Q7ZGV2ZWxvcG1lbnQ8L3RpdGxlPgo8cGF0aCBmaWxsPSJub25lIiBzdHJva2U9ImJsYWNrIiBkPSJNMTMyLjExLC05MEMxMzIuMTEsLTkwIDE0MC40MSwtOTAgMTQwLjQxLC05MCIvPgo8cG9seWdvbiBmaWxsPSJibGFjayIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIxNDAuNDEsLTkzLjUgMTUwLjQxLC05MCAxNDAuNDEsLTg2LjUgMTQwLjQxLC05My41Ii8+CjwvZz4KPCEtLSBtaWxlc3RvbmUgLS0+CjxnIGlkPSJub2RlNyIgY2xhc3M9Im5vZGUiPgo8dGl0bGU+bWlsZXN0b25lPC90aXRsZT4KPHBhdGggZmlsbD0id2hpdGUiIHN0cm9rZT0iYmxhY2siIGQ9Ik0zMjYuNSwtMTA4QzMyNi41LC0xMDggMjc1LjUsLTEwOCAyNzUuNSwtMTA4IDI2OS41LC0xMDggMjYzLjUsLTEwMiAyNjMuNSwtOTYgMjYzLjUsLTk2IDI2My41LC04NCAyNjMuNSwtODQgMjYzLjUsLTc4IDI2OS41LC03MiAyNzUuNSwtNzIgMjc1LjUsLTcyIDMyNi41LC03MiAzMjYuNSwtNzIgMzMyLjUsLTcyIDMzOC41LC03OCAzMzguNSwtODQgMzM4LjUsLTg0IDMzOC41LC05NiAzMzguNSwtOTYgMzM4LjUsLTEwMiAzMzIuNSwtMTA4IDMyNi41LC0xMDgiLz4KPHRleHQgdGV4dC1hbmNob3I9Im1pZGRsZSIgeD0iMzAxIiB5PSItODYuOSIgZm9udC1mYW1pbHk9IlRpbWVzLHNlcmlmIiBmb250LXNpemU9IjEyLjAwIj5NaWxlc3RvbmU8L3RleHQ+CjwvZz4KPCEtLSBkZXZlbG9wbWVudCYjNDU7Jmd0O21pbGVzdG9uZSAtLT4KPGcgaWQ9ImVkZ2U2IiBjbGFzcz0iZWRnZSI+Cjx0aXRsZT5kZXZlbG9wbWVudCYjNDU7Jmd0O21pbGVzdG9uZTwvdGl0bGU+CjxwYXRoIGZpbGw9Im5vbmUiIHN0cm9rZT0iYmxhY2siIGQ9Ik0yNDUuNTgsLTk2QzI0NS41OCwtOTYgMjUzLjQ5LC05NiAyNTMuNDksLTk2Ii8+Cjxwb2x5Z29uIGZpbGw9ImJsYWNrIiBzdHJva2U9ImJsYWNrIiBwb2ludHM9IjI1My40OSwtOTkuNSAyNjMuNDksLTk2IDI1My40OSwtOTIuNSAyNTMuNDksLTk5LjUiLz4KPC9nPgo8IS0tIHJjIC0tPgo8ZyBpZD0ibm9kZTkiIGNsYXNzPSJub2RlIj4KPHRpdGxlPnJjPC90aXRsZT4KPHBhdGggZmlsbD0id2hpdGUiIHN0cm9rZT0iYmxhY2siIGQ9Ik0yMzMuNSwtMzZDMjMzLjUsLTM2IDE2Mi41LC0zNiAxNjIuNSwtMzYgMTU2LjUsLTM2IDE1MC41LC0zMCAxNTAuNSwtMjQgMTUwLjUsLTI0IDE1MC41LC0xMiAxNTAuNSwtMTIgMTUwLjUsLTYgMTU2LjUsMCAxNjIuNSwwIDE2Mi41LDAgMjMzLjUsMCAyMzMuNSwwIDIzOS41LDAgMjQ1LjUsLTYgMjQ1LjUsLTEyIDI0NS41LC0xMiAyNDUuNSwtMjQgMjQ1LjUsLTI0IDI0NS41LC0zMCAyMzkuNSwtMzYgMjMzLjUsLTM2Ii8+Cjx0ZXh0IHRleHQtYW5jaG9yPSJtaWRkbGUiIHg9IjE5OCIgeT0iLTIxLjQiIGZvbnQtZmFtaWx5PSJUaW1lcyxzZXJpZiIgZm9udC1zaXplPSIxMi4wMCI+U3BlY2lmaWNhdGlvbjwvdGV4dD4KPHRleHQgdGV4dC1hbmNob3I9Im1pZGRsZSIgeD0iMTk4IiB5PSItOC40IiBmb250LWZhbWlseT0iVGltZXMsc2VyaWYiIGZvbnQtc2l6ZT0iMTIuMDAiPlZlcnNpb248L3RleHQ+CjwvZz4KPCEtLSBkZXZlbG9wbWVudCYjNDU7Jmd0O3JjIC0tPgo8ZyBpZD0iZWRnZTEwIiBjbGFzcz0iZWRnZSI+Cjx0aXRsZT5kZXZlbG9wbWVudCYjNDU7Jmd0O3JjPC90aXRsZT4KPHBhdGggZmlsbD0ibm9uZSIgc3Ryb2tlPSJibGFjayIgZD0iTTE5OCwtNzEuODNDMTk4LC03MS44MyAxOTgsLTQ2LjQxIDE5OCwtNDYuNDEiLz4KPHBvbHlnb24gZmlsbD0iYmxhY2siIHN0cm9rZT0iYmxhY2siIHBvaW50cz0iMjAxLjUsLTQ2LjQxIDE5OCwtMzYuNDEgMTk0LjUsLTQ2LjQxIDIwMS41LC00Ni40MSIvPgo8L2c+CjwhLS0gbWlsZXN0b25lJiM0NTsmZ3Q7ZGV2ZWxvcG1lbnQgLS0+CjxnIGlkPSJlZGdlNyIgY2xhc3M9ImVkZ2UiPgo8dGl0bGU+bWlsZXN0b25lJiM0NTsmZ3Q7ZGV2ZWxvcG1lbnQ8L3RpdGxlPgo8cGF0aCBmaWxsPSJub25lIiBzdHJva2U9ImJsYWNrIiBkPSJNMjYzLjIzLC04NEMyNjMuMjMsLTg0IDI1NS41OSwtODQgMjU1LjU5LC04NCIvPgo8cG9seWdvbiBmaWxsPSJibGFjayIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIyNTUuNTksLTgwLjUgMjQ1LjU5LC04NCAyNTUuNTksLTg3LjUgMjU1LjU5LC04MC41Ii8+CjwvZz4KPCEtLSBwcm9ncmVzc19yZXZpZXcgLS0+CjxnIGlkPSJub2RlOCIgY2xhc3M9Im5vZGUiPgo8dGl0bGU+cHJvZ3Jlc3NfcmV2aWV3PC90aXRsZT4KPHBvbHlnb24gZmlsbD0id2hpdGUiIHN0cm9rZT0iYmxhY2siIHBvaW50cz0iNDI3LjUsLTEwOCAzNTYuNSwtMTA4IDM1Ni41LC03MiA0MjcuNSwtNzIgNDI3LjUsLTEwOCIvPgo8dGV4dCB0ZXh0LWFuY2hvcj0ibWlkZGxlIiB4PSIzOTIiIHk9Ii05My40IiBmb250LWZhbWlseT0iVGltZXMsc2VyaWYiIGZvbnQtc2l6ZT0iMTIuMDAiPlByb2dyZXNzPC90ZXh0Pgo8dGV4dCB0ZXh0LWFuY2hvcj0ibWlkZGxlIiB4PSIzOTIiIHk9Ii04MC40IiBmb250LWZhbWlseT0iVGltZXMsc2VyaWYiIGZvbnQtc2l6ZT0iMTIuMDAiPlJldmlldzwvdGV4dD4KPC9nPgo8IS0tIG1pbGVzdG9uZSYjNDU7Jmd0O3Byb2dyZXNzX3JldmlldyAtLT4KPGcgaWQ9ImVkZ2U4IiBjbGFzcz0iZWRnZSI+Cjx0aXRsZT5taWxlc3RvbmUmIzQ1OyZndDtwcm9ncmVzc19yZXZpZXc8L3RpdGxlPgo8cGF0aCBmaWxsPSJub25lIiBzdHJva2U9ImJsYWNrIiBkPSJNMzM4LjU0LC05MEMzMzguNTQsLTkwIDM0Ni4zLC05MCAzNDYuMywtOTAiLz4KPHBvbHlnb24gZmlsbD0iYmxhY2siIHN0cm9rZT0iYmxhY2siIHBvaW50cz0iMzQ2LjMsLTkzLjUgMzU2LjMsLTkwIDM0Ni4zLC04Ni41IDM0Ni4zLC05My41Ii8+CjwvZz4KPCEtLSBwcm9ncmVzc19yZXZpZXcmIzQ1OyZndDtkZXZlbG9wbWVudCAtLT4KPGcgaWQ9ImVkZ2U5IiBjbGFzcz0iZWRnZSI+Cjx0aXRsZT5wcm9ncmVzc19yZXZpZXcmIzQ1OyZndDtkZXZlbG9wbWVudDwvdGl0bGU+CjxwYXRoIGZpbGw9Im5vbmUiIHN0cm9rZT0iYmxhY2siIGQ9Ik0zOTIsLTEwOC40MkMzOTIsLTExNy4yOCAzOTIsLTEyNiAzOTIsLTEyNiAzOTIsLTEyNiAyMzksLTEyNiAyMzksLTEyNiAyMzksLTEyNiAyMzksLTExOC40MiAyMzksLTExOC40MiIvPgo8cG9seWdvbiBmaWxsPSJibGFjayIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIyNDIuNSwtMTE4LjQyIDIzOSwtMTA4LjQyIDIzNS41LC0xMTguNDIgMjQyLjUsLTExOC40MiIvPgo8L2c+CjwhLS0gcmVsZWFzZV9yZXZpZXcgLS0+CjxnIGlkPSJub2RlMTAiIGNsYXNzPSJub2RlIj4KPHRpdGxlPnJlbGVhc2VfcmV2aWV3PC90aXRsZT4KPHBvbHlnb24gZmlsbD0id2hpdGUiIHN0cm9rZT0iYmxhY2siIHBvaW50cz0iMzI2LjUsLTM2IDI2My41LC0zNiAyNjMuNSwwIDMyNi41LDAgMzI2LjUsLTM2Ii8+Cjx0ZXh0IHRleHQtYW5jaG9yPSJtaWRkbGUiIHg9IjI5NSIgeT0iLTIxLjQiIGZvbnQtZmFtaWx5PSJUaW1lcyxzZXJpZiIgZm9udC1zaXplPSIxMi4wMCI+UmVsZWFzZTwvdGV4dD4KPHRleHQgdGV4dC1hbmNob3I9Im1pZGRsZSIgeD0iMjk1IiB5PSItOC40IiBmb250LWZhbWlseT0iVGltZXMsc2VyaWYiIGZvbnQtc2l6ZT0iMTIuMDAiPlJldmlldzwvdGV4dD4KPC9nPgo8IS0tIHJjJiM0NTsmZ3Q7cmVsZWFzZV9yZXZpZXcgLS0+CjxnIGlkPSJlZGdlMTEiIGNsYXNzPSJlZGdlIj4KPHRpdGxlPnJjJiM0NTsmZ3Q7cmVsZWFzZV9yZXZpZXc8L3RpdGxlPgo8cGF0aCBmaWxsPSJub25lIiBzdHJva2U9ImJsYWNrIiBkPSJNMjQ1LjY1LC0xOEMyNDUuNjUsLTE4IDI1My40NCwtMTggMjUzLjQ0LC0xOCIvPgo8cG9seWdvbiBmaWxsPSJibGFjayIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIyNTMuNDQsLTIxLjUgMjYzLjQ0LC0xOCAyNTMuNDQsLTE0LjUgMjUzLjQ0LC0yMS41Ii8+CjwvZz4KPCEtLSBmaW5hbCAtLT4KPGcgaWQ9Im5vZGUxMSIgY2xhc3M9Im5vZGUiPgo8dGl0bGU+ZmluYWw8L3RpdGxlPgo8cGF0aCBmaWxsPSJ3aGl0ZSIgc3Ryb2tlPSJibGFjayIgZD0iTTQzMSwtMzZDNDMxLC0zNiAzNTcsLTM2IDM1NywtMzYgMzUxLC0zNiAzNDUsLTMwIDM0NSwtMjQgMzQ1LC0yNCAzNDUsLTEyIDM0NSwtMTIgMzQ1LC02IDM1MSwwIDM1NywwIDM1NywwIDQzMSwwIDQzMSwwIDQzNywwIDQ0MywtNiA0NDMsLTEyIDQ0MywtMTIgNDQzLC0yNCA0NDMsLTI0IDQ0MywtMzAgNDM3LC0zNiA0MzEsLTM2Ii8+Cjx0ZXh0IHRleHQtYW5jaG9yPSJtaWRkbGUiIHg9IjM5NCIgeT0iLTIxLjQiIGZvbnQtZmFtaWx5PSJUaW1lcyxzZXJpZiIgZm9udC1zaXplPSIxMi4wMCI+UmF0aWZpZWQgRmluYWw8L3RleHQ+Cjx0ZXh0IHRleHQtYW5jaG9yPSJtaWRkbGUiIHg9IjM5NCIgeT0iLTguNCIgZm9udC1mYW1pbHk9IlRpbWVzLHNlcmlmIiBmb250LXNpemU9IjEyLjAwIj5TcGVjaWZpY2F0aW9uPC90ZXh0Pgo8L2c+CjwhLS0gcmVsZWFzZV9yZXZpZXcmIzQ1OyZndDtmaW5hbCAtLT4KPGcgaWQ9ImVkZ2UxMiIgY2xhc3M9ImVkZ2UiPgo8dGl0bGU+cmVsZWFzZV9yZXZpZXcmIzQ1OyZndDtmaW5hbDwvdGl0bGU+CjxwYXRoIGZpbGw9Im5vbmUiIHN0cm9rZT0iYmxhY2siIGQ9Ik0zMjYuNiwtMThDMzI2LjYsLTE4IDMzNC42NiwtMTggMzM0LjY2LC0xOCIvPgo8cG9seWdvbiBmaWxsPSJibGFjayIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIzMzQuNjYsLTIxLjUgMzQ0LjY2LC0xOCAzMzQuNjYsLTE0LjUgMzM0LjY2LC0yMS41Ii8+CjwvZz4KPCEtLSBmaW5hbCYjNDU7Jmd0O3BsYW4gLS0+CjxnIGlkPSJlZGdlMTMiIGNsYXNzPSJlZGdlIj4KPHRpdGxlPmZpbmFsJiM0NTsmZ3Q7cGxhbjwvdGl0bGU+CjxwYXRoIGZpbGw9Im5vbmUiIHN0cm9rZT0iYmxhY2siIGQ9Ik0zNTAuNzUsLTM2LjQyQzM1MC43NSwtNDUuMjggMzUwLjc1LC01NCAzNTAuNzUsLTU0IDM1MC43NSwtNTQgMjcsLTU0IDI3LC01NCAyNywtNTQgMjcsLTYxLjU4IDI3LC02MS41OCIvPgo8cG9seWdvbiBmaWxsPSJibGFjayIgc3Ryb2tlPSJibGFjayIgcG9pbnRzPSIyMy41LC02MS41OCAyNywtNzEuNTggMzAuNSwtNjEuNTggMjMuNSwtNjEuNTgiLz4KPC9nPgo8L2c+Cjwvc3ZnPgo=" alt="A specification project produces all versions of a specification" width="599" height="250"/>
+</div>
+<div class="title">A specification project produces all versions of a specification</div>
+</div>
+<div class="paragraph">
+<p><strong>Specification <em>projects</em> engage in releases and reviews.</strong> This one is more subtle and only applies to specification projects that support the development of more than one specification. The EDP allows projects to engage in releases that contain some subset of their content, so the notion of engaging in, for example, a <a href="https://www.eclipse.org/projects/handbook#release">release</a> (and corresponding <a href="#efspo-review-release">release review</a>) for one single specification is fully supported. While, strictly speaking, this sort of hypothetical release would be a <em>project</em> release and be owned by the <em>project</em>, it would be a <em>specification</em> release in a practical sense. There are no requirements regarding how releases are named/numbered.</p>
+</div>
+<div class="paragraph">
+<p>Specification projects operating under the EFSP follow the same lifecycle as open source projects operating under the EDP with the additional requirements that they engage in a <a href="#efspo-reviews-plan">plan review</a> at the beginning of a development cycle, that they engage in a <a href="#efspo-reviews-release">release review</a> for all major and minor releases, and that all <a href="#efspo-reviews">reviews</a> be approved by super-majority ballot of the working group&#8217;s specification committee.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-wg"><a class="anchor" href="#efspo-wg"></a><a class="link" href="#efspo-wg">Working Groups and Specifications</a></h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Specifications are created and maintained by specification projects. Each specification <em>project</em> is aligned with exactly one Eclipse Foundation working group. Specification projects are said to work <em>under the purview</em> of a particular working group, or&#8212;&#8203;more specifically&#8212;&#8203;the <a href="#efspo-spec-committee">specification committee</a> of a working group.</p>
+</div>
+<div class="paragraph">
+<p><strong>Working groups provide governance for specification projects.</strong> A working group&#8217;s specification committee, must approve&#8212;&#8203;by super-majority ballot&#8212;&#8203;all <a href="#efspo-reviews">reviews</a>.</p>
+</div>
+<div class="paragraph">
+<p><strong>The specification committee ratifies specifications as <em>final</em>.</strong> Via ballot during a <a href="#efspo-reviews-release">release review</a> the working group&#8217;s specification committee must vote to a approve ratifying the release version of a specification as a <a href="https://www.eclipse.org/projects/efsp#efsp-ratification">final specification</a>. Approval by a super-majority of the specification committee is required.</p>
+</div>
+<div class="paragraph">
+<p><strong>Specification project committers write the specification.</strong> Committer and specification committee member are two distinct roles. Being granted one of these roles does not automatically grant the other. Specifically, holding the role of specification committee member does not grant any write privileges on specification project repositories.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="roles"><a class="anchor" href="#roles"></a><a class="link" href="#roles">Roles</a></h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="efspo-spec-committee"><a class="anchor" href="#efspo-spec-committee"></a><a class="link" href="#efspo-spec-committee">Specification Committee</a></h3>
+<div class="paragraph">
+<p>The specification committee is responsible for implementing the EFSP for all specification projects (as that term is defined by the EFSP) that operate under the purview of the a working group. A working group may, via their charter, assign specification committee responsibilities to another committee.</p>
+</div>
+<div class="paragraph">
+<p>The specification committee is ultimately responsible for ensuring that the final specifications produced by the working group’s specification projects make sense. The definition of “makes sense” varies by specification committee participant, but is generally understood to mean that the specification can be implemented and that those aspects of the <a href="http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse Intellectual Property Policy</a> with regard to <em>essential claims</em> are observed. In practical terms, specification committee participants wield power via the ballots that are required to approve key lifecycle events per the EFSP.</p>
+</div>
+<div class="paragraph">
+<p>The Specification Committee is responsible for producing, publishing, and maintaining operational guidance documentation for specification projects. This includes the minimum requirements and process for producing a <a href="https://www.eclipse.org/projects/efsp#efsp-ratification"><em>final specification</em></a>. It also includes operational guidance for running a specifications TCK for the purpose of testing for compatibility.</p>
+</div>
+<div class="paragraph">
+<p>The Specification Chair (or their delegate) is responsible for initiating ballots, tallying their results, disseminating them to the community, and (when appropriate; e.g., in the case a <a href="#efspo-reviews-release">release review</a> ballot) reporting them to the EMO.</p>
+</div>
+<div class="paragraph">
+<p>The Specification Committee is also responsible for defining and refining how they implement the EFSP for those Specification Projects under their purview.</p>
+</div>
+<div class="sect3">
+<h4 id="efspo-roles-pmc"><a class="anchor" href="#efspo-roles-pmc"></a><a class="link" href="#efspo-roles-pmc">Project Management Committee</a></h4>
+<div class="paragraph">
+<p>The primary role of the Project Management Committee (PMC) is to ensure that project teams are implementing the EDP. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner. The PMC reviews and approves (or vetos) committer elections, first validating that candidate committers have demonstrated sufficient merit.</p>
+</div>
+<div class="paragraph">
+<p>The PMC is further responsible for ensuring that project teams abide by the Eclipse IP Policy and implement the IP Due Diligence process. In practical terms, the PMC approves intellectual property contributions (CQs) and provides (limited) guidance to project teams regarding intellectual property (deferring to the Eclipse IP Team as necessary).</p>
+</div>
+<div class="paragraph">
+<p>The PMC is responsible for the structure of the top-level project and the organization of the open source (software and Specification) projects contained within.</p>
+</div>
+<div class="paragraph">
+<p>The PMC is a link in the project leadership chain. As such, the PMC has a role in the grievance handling process: they identify and document project dysfunction (with the responsibility to remove/replace/add disruptive committers).</p>
+</div>
+<div class="paragraph">
+<p>The PMC provides other oversight regarding the operation of open source projects. They review and approve release and progress review materials, and facilitate cross-project communication within the top-level project.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-roles-pl"><a class="anchor" href="#efspo-roles-pl"></a><a class="link" href="#efspo-roles-pl">Project Lead(s)</a></h3>
+<div class="paragraph">
+<p>A specification project has one or more project leads. Project leads are the main liaison between the project team and the Eclipse Management Organization (EMO), and are responsible for ensuring that team members are implementing their responsibilities under the EDP, EFSP, and the Eclipse Foundation&#8217;s IP Policy. The lead is responsible for initiating reviews as the project reaches the appropriate milestone.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-roles-rep"><a class="anchor" href="#efspo-roles-rep"></a><a class="link" href="#efspo-roles-rep">Participant Representative</a></h3>
+<div class="paragraph">
+<p>The EFSP states that a <em>member participant</em> may appoint a <em>participant representative</em> committer. A member participant is defined as a strategic member or contributing member of the Eclipse Foundation that is a participant in the working group (i.e., has signed the corresponding working group participation agreement). In the case of specifications, vendor-neutrality trumps meritocracy. A specification process must be accessible to all <strong>companies</strong> who wish to participate.</p>
+</div>
+<div class="paragraph">
+<p>Appointment of a participant representative:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Is the mechanism by which their patent portfolio is licensed to the resulting specifications;</p>
+</li>
+<li>
+<p>Ensures that the specification process is accessible to all companies that wish to participate; and</p>
+</li>
+<li>
+<p>Is consistent with how all other specification processes work.</p>
+</li>
+</ul>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-note" title="Note"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>The notion of a participant representative specifically excludes committer members; this makes sense as, to be a committer member participant (the EFSP refers to this an an <em>individual participant</em>) in a working group, one must already be a committer. This does mean, however, that an individual participant who is a committer on one specification project <em>cannot</em> appoint themselves as a participant representative on another.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>Appointing a participant representative this is a power that a member participant will use to ensure that they have at least one committer on a specification project. If the member participant already has an employee as a committer, then that member participant is considered to already have a participant representative and cannot appoint another.</p>
+</div>
+<div class="paragraph">
+<p>Additional committers can be added via <a href="https://www.eclipse.org/projects/handbook#elections-committer">committer election</a>.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-reviews"><a class="anchor" href="#efspo-reviews"></a><a class="link" href="#efspo-reviews">Reviews</a></h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Specification projects in active development must engage in a <a href="#efspo-reviews-release">progress</a> or <a href="#efspo-reviews-release">release</a> review at least once per year. In practical terms, this means that the clock starts ticking when the <a href="#efspo-reviews-plan">plan review</a> that occurs at the beginning of the development cycle concludes successfully, and is reset following a successful progress review.</p>
+</div>
+<div class="paragraph">
+<p>The entire process is halted when either the specification project engages in a successful release review (thereby concluding the development cycle), or the specification team decides to abandon the cycle.</p>
+</div>
+<div class="paragraph">
+<p>The PMC approval and the specification committee ballot are different activities with different intention and purpose.</p>
+</div>
+<div class="paragraph">
+<p>The primary role of the <strong>PMC</strong> is to ensure that project teams are implementing the EDP. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner. Any specification project committer or project lead can solicit approval for a release from their PMC by posting on the PMC&#8217;s mailing list.</p>
+</div>
+<div class="admonitionblock tip">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-tip" title="Tip"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>The <em>Committer Tools</em> block on the right side of the <a href="https://www.eclipse.org/projects/handbook#pmi-project-page">project page</a> contains links subscribe to the PMC&#8217;s mailing list ("PMC Mailing List") and to send a note ("Send Email to the PMC").</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>The <strong>specification committee</strong> is ultimately responsible for ensuring that the ratified final specifications produced by the working group’s specification projects match the working group’s purpose and goals, that they can be implemented, and that those aspects of the Eclipse Intellectual Property Policy with regard to essential claims are observed. The specification committee exercises their responsibility via <a href="#efspo-ballots">ballot</a>.</p>
+</div>
+<div class="sect2">
+<h3 id="efspo-reviews-creation"><a class="anchor" href="#efspo-reviews-creation"></a><a class="link" href="#efspo-reviews-creation">Creation Reviews</a></h3>
+<div class="paragraph">
+<p>A creation review is required before a new specification project is created. In the case where an existing open source project is converted into a specification project, or a specification moves from working under the supervision of one working group to another, the creation review will be combined with a restructuring review.</p>
+</div>
+<div class="paragraph">
+<p>Creation reviews are tracked and managed by the EMO. A creation review requires a <a href="#efspo-ballot">ballot</a> of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.</p>
+</div>
+<div class="paragraph">
+<p>In considering their vote in the ballot, the question that specification committee members must consider is whether or not they would vote to approve the eventual release, ratification, and creation of a Final Specification when the project returns for a release review. If the answer is yes, then the specification committee member should vote in the affirmative <code>+1</code>; they should either vote in the negative <code>-1</code> or abstain <code>+0</code> otherwise.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-reviews-plan"><a class="anchor" href="#efspo-reviews-plan"></a><a class="link" href="#efspo-reviews-plan">Plan Reviews</a></h3>
+<div class="paragraph">
+<p>Plan reviews occur at the start of a development cycle. A creation review serves as the plan review for a specification project&#8217;s first release.</p>
+</div>
+<div class="paragraph">
+<p>Plan reviews are <em>not</em> formally tracked or managed by the EMO, but rather are initiated and managed directly by a member of specification committee; the EMO can provide assistance if required. In practice, a plan review requires no more formal ceremony than a successful <a href="#efspo-ballot">ballot</a> of the specification committee.</p>
+</div>
+<div class="paragraph">
+<p>When reviewing a plan, the question that specification committee members must consider is whether or not they would vote to approve the eventual completion of the plan when the project returns for a release review. If the answer is yes, then the specification committee member should vote in the affirmative <code>+1</code>; they should either vote in the negative <code>-1</code> or abstain <code>+0</code> otherwise.</p>
+</div>
+<div class="paragraph">
+<p>Ideally, when casting their vote, specification committee members should focus less on the mechanics of implementing the plan and more on the broader implications of the themes and changes suggested in the plan to implementors, adopters, and the ecosystem.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-reviews-release"><a class="anchor" href="#efspo-reviews-release"></a><a class="link" href="#efspo-reviews-release">Release Reviews</a></h3>
+<div class="paragraph">
+<p>A release review is required for all major and minor releases from a specification project. The review may be skipped for service releases that do not implicate any new intellectual property (i.e., bug fixes only). A specification project must engage in a release review for the first release of all specifications (independent of whether or not it is a major, minor, or service release).</p>
+</div>
+<div class="paragraph">
+<p>Releases of specification projects operate under the EDP augmented by the EFSP. Release reviews are tracked and managed by the EMO. A release review requires a <a href="#efspo-ballot">ballot</a> of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.</p>
+</div>
+<div class="admonitionblock tip">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-tip" title="Tip"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>See <a href="https://www.eclipse.org/projects/handbook#release-review">release and progress reviews</a> for a more complete description of the release review process.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="paragraph">
+<p>It is up to the individual parties to determine the basis on which they will vote in the ballot. When determining how to vote in a release review ballot, the question that specification committee members must consider is whether or not they believe that the specification as written can be implemented, that the TCK is complete enough, and whether or not the project team has met their obligations under the EFSP. If the answer is yes, then the specification committee member should vote in the affirmative <code>+1</code>; they should either vote in the negative <code>-1</code> or abstain <code>+0</code> otherwise.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-reviews-progress"><a class="anchor" href="#efspo-reviews-progress"></a><a class="link" href="#efspo-reviews-progress">Progress Reviews</a></h3>
+<div class="paragraph">
+<p>A progress review is required by a specification project when the time elapsed between a plan review and a release review exceeds one year.</p>
+</div>
+<div class="paragraph">
+<p>Progress reviews are tracked and managed by the EMO. A progress review requires a <a href="#efsp-operations-ballot">ballot</a> of the specification committee. The ballot may be initiated directly by a member of the specification committee; the EMO can provide assistance if required.</p>
+</div>
+<div class="paragraph">
+<p>When determining how to vote in a release review ballot, the question that specification committee members must consider is whether or not they believe that the specification is progressing in a manner that will produce a specification that can later be ratified. If the answer is yes, then the specification committee member should vote in the affirmative <code>+1</code>; they should either vote in the negative <code>-1</code> or abstain <code>+0</code> otherwise.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-ballots"><a class="anchor" href="#efspo-ballots"></a><a class="link" href="#efspo-ballots">Ballots</a></h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Specification ballots are run in the specification committee&#8217;s public mailing list.</p>
+</div>
+<div class="paragraph">
+<p>A ballot is initiated by a member of the specification committee by sending an email to the specification committee&#8217;s public mailing list, inviting specification committee members to indicate their vote in the affirmative with a <code>+1</code>, the negative with <code>-1</code> or their decision to abstain with <code>+0</code>. Specification committee members express their vote by responding on the public mailing list.</p>
+</div>
+<div class="paragraph">
+<p>Specification committee members vote on behalf of their constituency (generally the company whose interests they represent on the committee, or&#8212;&#8203;in the case of an elected representative&#8212;&#8203;their electoral base). The basis upon which this decision is made is at the discretion of the individual specification committee member. The specification committee may decide to establish a set of guidelines or requirements to provide a basis for voting; though these may instead be regarded as a gate to even starting a ballot.</p>
+</div>
+<div class="paragraph">
+<p>The following templates can be modified accordingly and used to initiate a ballot.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<i class="fa icon-note" title="Note"></i>
+</td>
+<td class="content">
+<div class="paragraph">
+<p>The ballot initiation message does not need to follow these templates; they are provided here only as a convenience.</p>
+</div>
+</td>
+</tr>
+</table>
+</div>
+<div class="sect2">
+<h3 id="efspo-ballot-release"><a class="anchor" href="#efspo-ballot-release"></a><a class="link" href="#efspo-ballot-release">Release Review Ballot Template</a></h3>
+<div class="quoteblock">
+<blockquote>
+<div class="paragraph">
+<p>Title: BALLOT: Approval to Release the <code>&lt;specification&gt;</code> Specification Project</p>
+</div>
+<div class="paragraph">
+<p>Your vote is required to approve and ratify the release of <code>&lt;specification&gt;</code>.</p>
+</div>
+<div class="paragraph">
+<p>The Eclipse Foundation Specification Process (EFSP) requires a successful ballot of the specification committee in order to ratify the products of this release as a Final Specification (as that term is defined in the EFSP).</p>
+</div>
+<div class="paragraph">
+<p><code>&lt;details&gt;</code></p>
+</div>
+<div class="paragraph">
+<p>Per the process, this will be a <code>&lt;duration&gt;</code> day ballot, ending on <code>&lt;date&gt;</code> that requires a super-majority positive vote of the <code>&lt;working-group&gt;</code> specification committee members (note that there is no veto). Community input is welcome, but only votes cast by specification committee representatives will be counted.</p>
+</div>
+<div class="paragraph">
+<p>Specification committee representatives, your vote is hereby requested. Please respond with +1 (positive), +0 (abstain), or -1 (reject).  Any feedback that you can provide to support your vote will be appreciated.</p>
+</div>
+</blockquote>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-ballot-restructure"><a class="anchor" href="#efspo-ballot-restructure"></a><a class="link" href="#efspo-ballot-restructure">Restructuring Review Ballot Template</a></h3>
+<div class="paragraph">
+<p>Restructuring Reviews are used to change the structure of a project. A restructuring review would be used to, for example, move a specification from one project to another, move a specification project from one working group to another, or convert an existing open source <em>software</em> project into a specification project.</p>
+</div>
+<div class="quoteblock">
+<blockquote>
+<div class="paragraph">
+<p>Title: BALLOT: Approval to change the <code>&lt;project&gt;</code> into a Specification Project</p>
+</div>
+<div class="paragraph">
+<p>We need to restructure the existing <code>&lt;project&gt;</code> into a specification project as defined by the Eclipse Foundation Specification Process (EFSP). For this, the EMO has initiated a restructuring review.</p>
+</div>
+<div class="paragraph">
+<p>The purpose of a restructuring review is to change the nature of a project. While we are not strictly creating a new project, we are in a manner of thinking, creating a new specification project from an existing project. With this in mind, we are treating this as a creation review from the perspective of the specification committee approval requirement.</p>
+</div>
+<div class="paragraph">
+<p>Per the process, this will be a <code>&lt;duration&gt;</code> day ballot, ending on <code>&lt;date&gt;</code> that requires a super-majority positive vote of the <code>&lt;working-group&gt;</code> specification committee members (note that there is no veto). Community input is welcome, but only votes cast by specification committee representatives will be counted.</p>
+</div>
+<div class="paragraph">
+<p><code>&lt;details&gt;</code></p>
+</div>
+<div class="paragraph">
+<p>Specification committee representatives, your vote is hereby requested. Please respond with +1 (positive), +0 (abstain), or -1 (reject).  Any feedback that you can provide to support your vote will be appreciated.</p>
+</div>
+</blockquote>
+</div>
+</div>
+<div class="sect2">
+<h3 id="efspo-ballot-details"><a class="anchor" href="#efspo-ballot-details"></a><a class="link" href="#efspo-ballot-details">Details</a></h3>
+<div class="paragraph">
+<p>The <code>&lt;details&gt;</code> should concisely describe the changes that are proposed. This could be as simple as a statement stating that "The Eclipse Foo project will be converted into a specification project.", but other changes may be included.</p>
+</div>
+<div class="paragraph">
+<p>For example:</p>
+</div>
+<div class="quoteblock">
+<blockquote>
+<div class="paragraph">
+<p>We will rename "Eclipse Project for JTA" project to "Jakarta Transactions" and convert it into a specification project with this project/specification scope statement:</p>
+</div>
+<div class="paragraph">
+<p>Jakarta Transactions defines a standard that allows the demarcation of transactions and the transactional coordination of XA-aware resource managers as described in the X/Open XA-specification and mapped to the Java SE XAResource interface within Java applications.</p>
+</div>
+</blockquote>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-specializing"><a class="anchor" href="#efspo-specializing"></a><a class="link" href="#efspo-specializing">Specializing the EFSP</a></h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>A working group may, through their specification committee, choose to specialize the EFSP for their own implementation. The process document is a foundational document that defines underlying principles, fundamental rules, and other requirements with regard to implementing specifications. The process document does not generally prescribe the use of specific technology, or provide any detail with regard to implementation.</p>
+</div>
+<div class="paragraph">
+<p>This document starts by describing what must not be taken away from the specification process, and concludes with some suggestions of what might be considered for a working group&#8217;s specialization of the process.</p>
+</div>
+<div class="sect2">
+<h3 id="minimum-values"><a class="anchor" href="#minimum-values"></a><a class="link" href="#minimum-values">Minimum Values</a></h3>
+<div class="paragraph">
+<p>The most critical aspect of the EFSP is the management of essential claims as defined by the Eclipse IP Policy. In this regard, the requirement that all committers be covered by an Eclipse Foundation Membership Agreement and Working Group Participation Agreement cannot be relaxed. By extension, the restrictions placed on participants and participant representatives cannot be relaxed in any customization of the process, nor can the ability of a participant to appoint a participant representative be inhibited in any way.</p>
+</div>
+<div class="paragraph">
+<p>The requirements regarding scope must not be relaxed. Specifically, the requirements regarding approvals and the requirement that the development work of the project stay with the boundaries defined by the scope must not be curtailed.</p>
+</div>
+<div class="paragraph">
+<p>The underlying principles of open source (the so-called “Open Source Rules of Engagement”) may not be curtailed. Specifically, all specification projects must operate in an open and transparent manner, must follow meritocratic practices to promote individuals to positions of power and authority, and (although not strictly listed as a rule of engagement) operate in a vendor neutral manner.</p>
+</div>
+<div class="paragraph">
+<p>The powers granted to the project leadership chain by the EDP must not be restricted.</p>
+</div>
+<div class="paragraph">
+<p>In general, quantities included in the EFSP and EDP can be increased, but not decreased. For example, the period of time required to run a simple ballot (e.g. a committer election) must not be less than seven days (it is generally accepted at a week is a reasonable minimum period of time to run a ballot that meets a minimum standard of community inclusion).</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="specializing-the-process"><a class="anchor" href="#specializing-the-process"></a><a class="link" href="#specializing-the-process">Specializing the Process</a></h3>
+<div class="paragraph">
+<p>The EFSP defines a set of underlying principles and fundamental requirements. It intentionally does not define any sort of practical implementation, or prescribe any specific technologies. Specializations of the process should take a similar approach. The process might, for example, extend the amount of time required for a specification committee ballot; but any attempt to describe the specific mechanisms and technology by which a ballet is run in a practical sense is more of an operational detail that should be defined in an operations document.</p>
+</div>
+<div class="sect3">
+<h4 id="example-process-specializations"><a class="anchor" href="#example-process-specializations"></a><a class="link" href="#example-process-specializations">Example Process Specializations</a></h4>
+<div class="paragraph">
+<p>Providing a comprehensive list of every possible thing that can be customized is an impossible task. In place of a comprehensive list, we provide a list of examples of things that might be customized and/or tuned.</p>
+</div>
+<div class="paragraph">
+<p>A customization may extend the list of Open Source Licenses (but many not remove licenses from the master list).</p>
+</div>
+<div class="paragraph">
+<p>A customization may define requirements for evolving itself to create future versions of the working group-specific specification process.</p>
+</div>
+<div class="paragraph">
+<p>A customization may:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Require progress reviews at some interval;</p>
+</li>
+<li>
+<p>Specify a maximum and/or minimum period of time required for specification committee approval ballot;</p>
+</li>
+<li>
+<p>Specify the period of time that must pass between reviews; and</p>
+</li>
+<li>
+<p>Describe mitigation steps in the event that a review fails.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The process requires that a specification project engage in a release review. A customization may:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Specify a maximum and/or minimum period of time required for specification committee approval votes;</p>
+</li>
+<li>
+<p>Specify the period of time that must pass between the last progress review and the release review; and</p>
+</li>
+<li>
+<p>Describe mitigation steps in the event that the review fails.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>A customization may also define:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Technical namespaces;</p>
+</li>
+<li>
+<p>Criteria for designating a release as major, minor, or service; and</p>
+</li>
+<li>
+<p>Criteria, requirements, etc. for managing exceptions in a TCK.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>While generally considered best practices, a customization may prescribe:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>How a specification is bundled for dissemination;</p>
+</li>
+<li>
+<p>Specific file formats for documentation; and</p>
+</li>
+<li>
+<p>Document structure and style.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The EFSP provides no specific criteria for designating a specification as a profile, nor does it attempt to define “platform”. A specialization may choose to provide definitions or specify the criteria for designating a specification as a profile.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="operational-considerations"><a class="anchor" href="#operational-considerations"></a><a class="link" href="#operational-considerations">Operational Considerations</a></h4>
+<div class="paragraph">
+<p>Specification committees are encouraged to create an operations document that describes how the process is implemented. The evolution of an operations document tends to be organic, based on building consensus within the team instead of relying on a formal approvals process.</p>
+</div>
+<div class="paragraph">
+<p>Out of convenience, an operations document may repeat information that’s captured in the process; as such, an operations document must include a clear statement that in the event of conflict the process document must be taken as the authority.</p>
+</div>
+<div class="paragraph">
+<p>The practical implementation of aspects of the process are not defined by the EFSP, and so a working group specification process (specialization) may choose to formalize (for example):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>How to run specification committee ballot;</p>
+</li>
+<li>
+<p>How a participant appoints a participant representative;</p>
+</li>
+<li>
+<p>What to do when a ballot fails or approval is not otherwise granted;</p>
+</li>
+<li>
+<p>The mechanism by which a specification committee determines whether or not a minor correction made during a ballot changes semantic meaning;</p>
+</li>
+<li>
+<p>How a specification version becomes a final specification;</p>
+</li>
+<li>
+<p>Requirements/guidelines to pass a progress/release review, along with timing of the review itself; and</p>
+</li>
+<li>
+<p>A standard means of describing relationships between specifications.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="efspo-faq"><a class="anchor" href="#efspo-faq"></a><a class="link" href="#efspo-faq">Frequently Asked Questions</a></h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Is a specification project is a subtype of a Eclipse project, governed by the EDP? </dt>
+<dd>
+<p>In a mathematical sense, yes. A specification project as defined by the EFSP is a specialization or subtype of an Eclipse open source project as defined by the EDP.</p>
+</dd>
+<dt class="hdlist1">Does a specification need to list patents? </dt>
+<dd>
+<p>No. In fact, a specification <em>must not</em> specifically list patents.</p>
+</dd>
+<dt class="hdlist1">How do patent grants work? </dt>
+<dd>
+<p>We cannot provide legal advice. Connect with your lawyer for more information.</p>
+</dd>
+<dt class="hdlist1">Can a working group&#8217;s steering committee take on the responsibilities of the specification committee? </dt>
+<dd>
+<p>Yes. A working group&#8217;s charter can assign the responsibilities of the specification committee to any working group committee.</p>
+</dd>
+<dt class="hdlist1">The ability of a member participant (i.e., a participant representing a company) to appoint a <em>participant representative</em> committer isn&#8217;t very meritocratic; is meritocracy irrelevant? </dt>
+<dd>
+<p>Meritocracy is very relevant. However, the rules of engagement with specification projects is different in consideration of factors like patent grants and antitrust. In the case of specifications, vendor-neutrality trumps meritocracy: a specification process must be accessible to all <strong>companies</strong> who wish to participate.</p>
+</dd>
+<dt class="hdlist1">Can a member participant (i.e., a participant representing a company) appoint as many <em>participant representative</em> committers as they&#8217;d like? </dt>
+<dd>
+<p>No. A member participant (i.e., a company that is a participant in the working group) can appoint a single participant representative committer on a specification project, and only if they do not already have a committer representing their interests on that project. Additional committers representing the interests of a member participant may demonstrate merit through contribution and be elected to the project using the standard mechanism for <a href="https://www.eclipse.org/projects/handbook#elections-committer">electing committers</a>.</p>
+</dd>
+<dt class="hdlist1">Is a participant representative a special kind of committer? </dt>
+<dd>
+<p>A participant representative is indistinguishable from any other committer once appointed.</p>
+</dd>
+<dt class="hdlist1">Do participant representatives have any special powers or privileges? </dt>
+<dd>
+<p>No.</p>
+</dd>
+<dt class="hdlist1">Will a participant representative be retired from a specification project when they change employers? </dt>
+<dd>
+<p>No. A participant representative is indistinguishable from any other committer and so retains their committer status even after changing employers. After changing employers, a committer may require new committer agreements, but once those are in place, the committer retains all privileges. In the event that a committer changing employers leaves a member participant unrepresented, that member participant may appoint a new participant representative.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/efsp/operations.php b/efsp/operations.php
new file mode 100755
index 0000000..99e4d30
--- /dev/null
+++ b/efsp/operations.php
@@ -0,0 +1,41 @@
+<?php
+/*******************************************************************************
+ * Copyright (c) Eclipse Foundation and others.
+ *
+ * This program and the accompanying materials are made
+ * available under the terms of the Eclipse Public License 2.0
+ * which is available at https://www.eclipse.org/legal/epl-2.0/
+ *
+ * SPDX-License-Identifier: EPL-2.0
+ *******************************************************************************/
+require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");
+require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
+require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");
+$App = new App();
+$Nav = new Nav();
+$Menu = new Menu();
+include($App->getProjectCommon());
+
+$pageTitle = "Eclipse Foundation Specification Process Operations";
+$pageAuthor = "Wayne Beaton";
+$pageKeywords = "EFSP, Specifications";
+
+include($App->getProjectCommon());
+
+$fileName = dirname(__FILE__) . '/content/operations.html';
+
+ob_start();
+?>
+
+<link rel="stylesheet" href="/projects/handbook/resources/handbook.css"/>
+
+<div id="maincontent">
+	<h1><?php echo $pageTitle; ?></h1>
+	<?php include $fileName; ?>
+</div>
+
+<?php
+	$html = ob_get_contents();
+	ob_end_clean();
+	$App->generatePage(null, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
+?>