workinggroups/content/en_operations.html - www.eclipse.org/org - Git at Google

 <h1>Eclipse Foundation Working Group Operations Guide</h1>
 <div id="toc" class="toc">
 <div id="toctitle">Table of Contents</div>
 <ul class="sectlevel1">
 <li><a href="#roles">Roles</a>
 <ul class="sectlevel2">
 <li><a href="#working-groups-manager">Working Groups Manager</a></li>
 <li><a href="#working-group-sponsor">Working Group Sponsor</a></li>
 <li><a href="#working-groups-team">Working Groups Team</a></li>
 <li><a href="#program-manager">Program or Community Manager</a></li>
 </ul>
 </li>
 <li><a href="#membership">Membership</a>
 <ul class="sectlevel2">
 <li><a href="#annual-participation-fees">Annual Participation Fees</a></li>
 </ul>
 </li>
 <li><a href="#relationship-with-open-source-projects">Relationship with Open Source Projects</a></li>
 <li><a href="#committees">Committees</a>
 <ul class="sectlevel2">
 <li><a href="#steering-committee">Steering Committee</a></li>
 <li><a href="#specification-committee">Specification Committee</a></li>
 <li><a href="#project-management-committee-pmc">Project Management Committee (PMC)</a></li>
 <li><a href="#marketing-and-brand-committee">Marketing and Brand Committee</a></li>
 <li><a href="#committee-representatives">Committee Representatives</a></li>
 <li><a href="#elected-representatives">Elected Representatives</a></li>
 <li><a href="#committee-minutes">Committee Minutes</a></li>
 </ul>
 </li>
 <li><a href="#communication">Communication</a></li>
 <li><a href="#votes">Votes</a></li>
 <li><a href="#specification-process">Specification Process</a></li>
 <li><a href="#grievance-handling">Grievance Handling</a></li>
 <li><a href="#assets">Assets</a>
 <ul class="sectlevel2">
 <li><a href="#names-and-logos">Names and Logos</a></li>
 <li><a href="#charter">Charter</a></li>
 <li><a href="#pitch-deck">Pitch Deck</a></li>
 <li><a href="#pipeline">Pipeline</a></li>
 <li><a href="#initiation-agreement">Initiation Agreement</a></li>
 <li><a href="#participation-agreement">Participation Agreement</a></li>
 <li><a href="#program-plan-and-annual-budget">Program Plan and Annual Budget</a></li>
 <li><a href="#infrastructure-plan">Infrastructure Plan</a></li>
 <li><a href="#marketing-plan">Marketing Plan</a></li>
 <li><a href="#annual-budget">Annual Budget</a></li>
 </ul>
 </li>
 <li><a href="#resources-and-services">Resources and Services</a>
 <ul class="sectlevel2">
 <li><a href="#typical-infrastructure-and-services">Typical Infrastructure and Services</a></li>
 <li><a href="#other-resources-and-services">Other Resources and Services</a></li>
 <li><a href="#infrastructure-audits">Infrastructure Audits</a></li>
 </ul>
 </li>
 <li><a href="#lifecycle">Lifecycle</a>
 <ul class="sectlevel2">
 <li><a href="#opportunity-phase">Opportunity Phase</a></li>
 <li><a href="#proposal-phase">Proposal Phase</a></li>
 <li><a href="#incubation-phase">Incubation Phase</a></li>
 <li><a href="#operational-phase">Operational Phase</a></li>
 <li><a href="#termination-archived-phase">Termination/Archived Phase</a></li>
 </ul>
 </li>
 <li><a href="#faq">FAQ</a></li>
 </ul>
 </div>
 <div id="preamble">
 <div class="sectionbody">
 <div class="paragraph">
 <p>Version 1.0</p>
 </div>
 <div class="paragraph">
 <p>This document describes the lifecycle and operation of Eclipse Foundation Working Groups. In particular, this document describes how the Eclipse Foundation implements the <a href="https://www.eclipse.org/org/workinggroups/process.php">Eclipse Foundation Working Group Process</a>.</p>
 </div>
 <div class="paragraph">
 <p>The following documents define the governance of the Eclipse Foundation in general, and working groups, open source projects, and open source specifications in particular.</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/eclipse_foundation-bylaws.pdf">Eclipse Foundation Bylaws</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/eclipse_membership_agreement.pdf">Eclipse Foundation Membership Agreement</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse Foundation Intellectual Property Policy</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/Eclipse_Antitrust_Policy.pdf">Eclipse Foundation Antitrust Policy</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/workinggroups/industry_wg_process.php">Eclipse Foundation Working Group Process</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Foundation Development Process</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/projects/efsp/">Eclipse Foundation Specification Process</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/legal/efsl.php">Eclipse Foundation Specification License</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/legal/tck.php">Eclipse Foundation Technology Compatibility Kit License</a></p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>In the event of any conflict between the terms set forth in this operations guide and the terms of the documents listed above, the terms of those documents shall take precedence.</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="working-groups-manager"><a class="anchor" href="#working-groups-manager"></a><a class="link" href="#working-groups-manager">Working Groups Manager</a></h3>
 <div class="paragraph">
 <p>The Working Groups Manager has overall responsibility for the implementation of the Eclipse Foundation Working Group Process. They chair internal Working Group status meetings, provide expert advice regarding related processes and operations, and otherwise facilitate discussion and collaboration within the Working Groups Team.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="working-group-sponsor"><a class="anchor" href="#working-group-sponsor"></a><a class="link" href="#working-group-sponsor">Working Group Sponsor</a></h3>
 <div class="paragraph">
 <p>The Working Group Sponsor (“Sponsor”) is a representative from the Eclipse Foundation’s senior leadership team who ensures that this and related processes are understood and followed by all parties, and facilitates the early phases of individual working groups (e.g. host calls, provide input and guidance on development of program plans and budgets, etc.). The Sponsor acts as the primary liaison between the Working Group and the EMO.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="working-groups-team"><a class="anchor" href="#working-groups-team"></a><a class="link" href="#working-groups-team">Working Groups Team</a></h3>
 <div class="paragraph">
 <p>Directors, executives, and program managers engaged in the development of Eclipse Foundation working groups.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="program-manager"><a class="anchor" href="#program-manager"></a><a class="link" href="#program-manager">Program or Community Manager</a></h3>
 <div class="paragraph">
 <p>The Program Manager is an Eclipse Foundation staff member who collaborates with the Participant working group members to articulate the working group’s vision, technical strategy, marketing strategy, and objectives. The Program Manager is also responsible to evangelize the working group’s vision and projects to the relevant industry segments, and to assist in working group recruitment.</p>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="membership"><a class="anchor" href="#membership"></a><a class="link" href="#membership">Membership</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>Each working group chooses the levels of membership that best suit its objectives.  Generally, there are three to five fundamental levels of working group membership:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p><strong>Strategic Members</strong> are organizations that view technology as strategic to their organization and are investing significant resources to sustain and shape the activities of this working group. Strategic Members are generally required to commit to strategic membership for a three (3) year period (especially when the working group is directly funding Eclipse Foundation staff).</p>
 </li>
 <li>
 <p><strong>Gold</strong> or <strong>Enterprise Members</strong> are typically organizations that view enterprise technology as a critical part of their organization&#8217;s business operations.</p>
 </li>
 <li>
 <p><strong>Silver</strong> or <strong>Participant Members</strong> (AKA “Participant Members”) are typically organizations that deliver products or services based on technology. These organizations want to participate in the development of the ecosystem associated with the technology.</p>
 </li>
 <li>
 <p><strong>Committer Members</strong> are individuals who through a process of meritocracy defined by the Eclipse Foundation Development Process are able to contribute and commit code to the Eclipse Foundation projects included in the scope of the working group. Committers may be members by virtue of working for a member organization, or may choose to complete the membership process independently if they are not. For further explanation and details, see the Eclipse Committer Membership page.</p>
 </li>
 <li>
 <p><strong>Guest Members</strong> are organizations which are Associate members of the Eclipse Foundation who have been invited for one year, renewable, by the Steering Committee to participate in particular aspects of the activities of the Working Group. Typical guests include JUGs, R&amp;D partners, universities, academic research centers, etc. Guests may be invited to participate in committee meetings at the invitation of the respective committee, but under no circumstances do Guest members have voting rights.</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>In different contexts, these levels may have different names, but the descriptions of the membership types must be fundamentally equivalent.</p>
 </div>
 <div class="paragraph">
 <p>Strategic, Gold, and Silver working group membership classes must designate a minimum <a href="https://www.eclipse.org/membership/#tab-levels">Eclipse Foundation membership level</a> of Eclipse Solutions Member. Guest members are typically restricted to Associate Members of Eclipse Foundation.</p>
 </div>
 <div class="paragraph">
 <p>All working group members are required to sign the working group’s <a href="#participation-agreement">Working Group Participation Agreement</a>.</p>
 </div>
 <div class="sect2">
 <h3 id="annual-participation-fees"><a class="anchor" href="#annual-participation-fees"></a><a class="link" href="#annual-participation-fees">Annual Participation Fees</a></h3>
 <div class="paragraph">
 <p>Each working group establishes annual fees for each of its classes of participation.  Unless otherwise stipulated in the working group charter and agreed to by the Foundation, members agree to pay the established annual fee upon execution of their Participation Agreement, and each subsequent year on their anniversary.  Our standard practice is to have three year commitments from Strategic participants to support the long-term goals of the working group, and in particular to establish longer term financial support, including  funding for staff.</p>
 </div>
 <div class="paragraph">
 <p>Fee collection for working groups begins when the working group is established. Unless otherwise stated in the charter, fees are collected for a twelve month period.  The working group will establish a budget, as described below, each calendar year based on the expected fees collected.</p>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="relationship-with-open-source-projects"><a class="anchor" href="#relationship-with-open-source-projects"></a><a class="link" href="#relationship-with-open-source-projects">Relationship with Open Source Projects</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>The purpose of working groups is to complement the activities of Eclipse Foundation open source projects by undertaking activities that projects have historically found difficult to manage. As self-governing meritocracies, there is no notion of working group <em>ownership</em> of projects. That is, working groups do not own or manage open source projects. Rather, working groups may express non-exclusive <em>interest</em> in some number of Eclipse open source projects. This set of <em>projects of interest</em> (or more simply, the working group’s <em>projects</em>) is defined, either directly or indirectly in the working group’s charter or by resolution of its Steering Committee. Specification projects that operate under the purview of the working group’s <a href="#specification-committee">specification committee</a> are automatically included in the working group’s project set.</p>
 </div>
 <div class="paragraph">
 <p>With the exception of specification projects, which operate under the purview of a working group’s specification committee, a working group has no direct power to affect the operation of open source projects in which they express interest (a working group exerts influence over Eclipse projects by having working group participants engage in the open source process, particularly by making contributions).</p>
 </div>
 <div class="paragraph">
 <p>Working groups typically provide input and guidance on project roadmaps, and release schedules, on behalf of their projects. Working groups may take on responsibility for promotion, marketing, developer advocacy, and branding strategies for their projects.</p>
 </div>
 <div class="paragraph">
 <p>The union of the committers from a working group’s projects comprise the <em>working group committers</em>.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="committees"><a class="anchor" href="#committees"></a><a class="link" href="#committees">Committees</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>Every committee must have a chairperson (or “chair”), and a secretary. These roles may have alternates. These roles may be occupied by the same individuals, or may be rotated among committee members.</p>
 </div>
 <div class="paragraph">
 <p>The chair is responsible for making sure that each meeting is planned effectively, conducted according to the rules outlined in the working group charter, and that matters are dealt with in an orderly, efficient manner. Individual committees nominate and elect (by simple majority) their committee chair, who must then be approved and appointed by the EMO(ED).</p>
 </div>
 <div class="paragraph">
 <p>The initial (interim) chair for each committee is appointed by the EMO(ED) or their designate. At the earliest opportunity, each committee must nominate and elect a new chair.</p>
 </div>
 <div class="paragraph">
 <p>All working groups must adhere to the Eclipse Antitrust Policy with respect to formal minutes and agendas of committee meetings. As a result, every committee must nominate and elect a secretary. The secretary is the person who keeps and disseminates formal records of the working group&#8217;s process and decisions (i.e., the minutes of all formal meetings). Individual committees nominate and elect (by simple majority) their committee secretary (no further approval is required).</p>
 </div>
 <div class="paragraph">
 <p>Should a working group committee find itself with a vacant chair, the working group may continue to either operate without a chair or with an Eclipse Foundation staff member moderating meetings until the role is filled.</p>
 </div>
 <div class="paragraph">
 <p>During committee meetings, committee members must put forward motions which must be seconded, before a vote can take place.</p>
 </div>
 <div class="paragraph">
 <p>It&#8217;s important to note that Eclipse Foundation staff are not members of any committee but rather attend meetings in an ex officio manner, and cannot vote on committee matters even when acting as Chair.</p>
 </div>
 <div class="sect2">
 <h3 id="steering-committee"><a class="anchor" href="#steering-committee"></a><a class="link" href="#steering-committee">Steering Committee</a></h3>
 <div class="paragraph">
 <p>Each working group must establish a steering committee. The steering committee is responsible for defining and implementing the working group’s charter and generally providing oversight of the activities of the working group. The steering committee has the ultimate responsibility for establishing the purpose, goals, and roadmap for the working group. The steering committee is further responsible for establishing working group specific policies, processes, and practices; and for making decisions regarding working group matters not addressed by the working group charter, this guide, or other established practices and policies.  See the <a href="https://www.eclipse.org/org/workinggroups/process.php#wg-committees">Eclipse Foundation Working Group Process</a> for more detailed responsibilities of the Steering Committee.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="specification-committee"><a class="anchor" href="#specification-committee"></a><a class="link" href="#specification-committee">Specification Committee</a></h3>
 <div class="paragraph">
 <p>The specification committee, in addition to any other responsibilities given to it through the working group charter, is responsible for implementing the <a href="https://www.eclipse.org/projects/efsp">Eclipse Foundation Specification Process</a> (EFSP) for all specification projects that operate under the working group’s purview.</p>
 </div>
 <div class="paragraph">
 <p>The specification committee 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. 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 ratified final specification. 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 committee 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 release review 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.</p>
 </div>
 <div class="paragraph">
 <p>The specification committee is <strong>not</strong> responsible for the day-to-day operation of specification projects, and does not have any responsibility or authority regarding the structure or organization of specification projects and corresponding top level project.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="project-management-committee-pmc"><a class="anchor" href="#project-management-committee-pmc"></a><a class="link" href="#project-management-committee-pmc">Project Management Committee (PMC)</a></h3>
 <div class="paragraph">
 <p>The composition and role of the Project Management Committee (PMC) is defined by the <a href="https://www.eclipse.org/projects/dev_process">Eclipse Foundation Development Process</a> (EDP) and operates independently from the working group. Specifically, the PMC is not actually part of the working group; it is included here to ensure that individuals involved with the working group understand the PMC’s role.</p>
 </div>
 <div class="paragraph">
 <p>A PMC is responsible for the operation of exactly one Top Level Project as defined by the EDP. Per the EDP, top level projects sit at the top of the open source project hierarchy. Top level projects do not generally maintain open source code of their own, but rather provide oversight and guidance to those open source projects that fall under them in the project hierarchy. All projects that fall under a particular top level project must fit within the mission and scope defined by the top level project’s charter. In addition to mission and scope, the charter may further define other requirements or establish guidelines for practices by the project that fall under its purview.</p>
 </div>
 <div class="paragraph">
 <p>The primary role of the 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 implementing the Eclipse Intellectual Property (IP) Due Diligence process.</p>
 </div>
 <div class="paragraph">
 <p>The PMC is responsible for defining and managing 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 or replace 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 class="sect2">
 <h3 id="marketing-and-brand-committee"><a class="anchor" href="#marketing-and-brand-committee"></a><a class="link" href="#marketing-and-brand-committee">Marketing and Brand Committee</a></h3>
 <div class="paragraph">
 <p>Each working group may establish a marketing and brand committee. The marketing and brand committee is responsible for defining the strategic marketing priorities, goals, and objectives for the working group. The marketing and brand committee is further responsible for providing general oversight of the marketing activities of the working group, including providing feedback to the EMO on the marketing, brand, and communications plans and activities executed on behalf of the working group. The committee will define the working group trademark policy, if applicable, and refer to it for approval by the steering committee.</p>
 </div>
 <div class="paragraph">
 <p>Marketing and brand committee members are expected to be leaders in supporting the implementation of working group outreach programs and communicating key messaging on behalf of the working group via their respective channels (i.e., web, social media, others).</p>
 </div>
 <div class="paragraph">
 <p>If the working group does not establish such a committee, then the general responsibilities identified above fall to the steering committee</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="committee-representatives"><a class="anchor" href="#committee-representatives"></a><a class="link" href="#committee-representatives">Committee Representatives</a></h3>
 <div class="paragraph">
 <p>The Charter specifies the means by which committee members are appointed or elected to its committees to represent the interests of aspects of the group and/or related communities.  Members may be appointed, elected, or invited to participate.</p>
 </div>
 <div class="paragraph">
 <p>For committer member representative elections, those individuals who are working group committers and are also members of the working group are eligible to vote.  That is, not all working group committers are required to be members of the working group; committers may be considered members by virtue of either a) being employed by a working group corporate member, or b) an individual committer who executes the working group’s Participation Agreement.</p>
 </div>
 <div class="sect3">
 <h4 id="representative-obligations"><a class="anchor" href="#representative-obligations"></a><a class="link" href="#representative-obligations">Representative Obligations</a></h4>
 <div class="paragraph">
 <p>Once elected to represent the members of their constituency, Elected representatives, like every other member of the committee, have the responsibility and obligation of directly defining and implementing the working group’s charter. Working group committees require quorum and regularly vote on matters pertaining to the working group.  As a result, elected representatives are required to be in good standing (as defined by the charter) with regular attendance at meetings.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="terms-and-dates"><a class="anchor" href="#terms-and-dates"></a><a class="link" href="#terms-and-dates">Terms and Dates</a></h4>
 <div class="paragraph">
 <p>Elected representatives shall each serve one-year terms or until their respective successors are appointed or elected, or as otherwise provided for in the charter.</p>
 </div>
 <div class="paragraph">
 <p>It’s typical for the calendar year to run from April 1 to March 31 but that is not always the case.  There shall be no prohibition on re-election or re-designation of any representative following the completion of that representative&#8217;s term of office.</p>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="elected-representatives"><a class="anchor" href="#elected-representatives"></a><a class="link" href="#elected-representatives">Elected Representatives</a></h3>
 <div class="paragraph">
 <p>A working group’s charter may define elected committee positions that represent the interests of all members of a particular constituency (e.g., committers). An election is required to select representatives for elected positions.</p>
 </div>
 <div class="paragraph">
 <p>All individuals who are employed by an organization that has signed the respective working group participation agreement and/or have individually signed the respective working group participation agreement may nominate/self nominate for any elected position for which they are a constituent. The members of that constituency are likewise eligible to vote for their representative.</p>
 </div>
 <div class="paragraph">
 <p>Elections pass through several phases:</p>
 </div>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
 <p>Working Group Election Announcement</p>
 </li>
 <li>
 <p>Nomination Phase  (Call for Nominations/Extensions)</p>
 </li>
 <li>
 <p>Nomination Acceptance Phase - Confirmation, Bio’s and Pictures Submissions</p>
 </li>
 <li>
 <p>Notice of Candidates Standing Phase</p>
 </li>
 <li>
 <p>Ballot Distribution Phase</p>
 </li>
 <li>
 <p>Count of Results Phase</p>
 </li>
 <li>
 <p>Election Results Announcement</p>
 </li>
 </ol>
 </div>
 <div class="paragraph">
 <p>We typically allow ten business days for the Nomination Phase and Ballot Distribution Phase.  As a result, it can often take a full month to complete the entire process.  Additionally, extensions to these phases can be considered and will affect any arranged schedules.</p>
 </div>
 <div class="paragraph">
 <p>All communication must be conducted via email using the general working group mailing list. Services may be used for an election, provided their use does not represent an unreasonable or onerous barrier for participation. Voters can only vote once and voting choices remain anonymous.  Votes must be auditable, verifiable and independently observable.</p>
 </div>
 <div class="sect3">
 <h4 id="ballots-run-by-the-eclipse-foundation"><a class="anchor" href="#ballots-run-by-the-eclipse-foundation"></a><a class="link" href="#ballots-run-by-the-eclipse-foundation">Ballots Run by The Eclipse Foundation</a></h4>
 <div class="paragraph">
 <p>A working group committee may opt to ask the Eclipse Foundation to run their ballot.</p>
 </div>
 <div class="paragraph">
 <p>To request that a ballot be run by the Eclipse Foundation, a committee’s chair can send the request to <a href="mailto:elections@eclipse.org">elections@eclipse.org</a>. Unless instructed otherwise, the Eclipse Foundation will use the working group’s public mailing list to conduct the election (elections must always be run on a public mailing list). The Eclipse Foundation will work with the committee chair to set the schedule for the ballot, including nomination and voting periods.</p>
 </div>
 <div class="paragraph">
 <p>Nominations must be sent to <a href="mailto:elections@eclipse.org">elections@eclipse.org</a>. Ballots are distributed to email addresses on file with the Eclipse Foundation.</p>
 </div>
 <div class="paragraph">
 <p>Note that ballot distribution may be provided by the Eclipse Foundation via a third party election service.</p>
 </div>
 <div class="paragraph">
 <p>The Eclipse Foundation utilizes the <a href="https://en.wikipedia.org/wiki/Single_transferable_vote">Single Transferable Vote</a> (STV) to calculate election results.</p>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="committee-minutes"><a class="anchor" href="#committee-minutes"></a><a class="link" href="#committee-minutes">Committee Minutes</a></h3>
 <div class="paragraph">
 <p>All working group committees must produce and disseminate minutes of all committee meetings.</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Include attendees and company affiliations;</p>
 </li>
 <li>
 <p>Identify absent attendees and company affiliations;</p>
 </li>
 <li>
 <p>Record actions, decisions, and outstanding action items indicating responsibility;</p>
 </li>
 <li>
 <p>Minutes are to be distributed via the relevant committee mailing list eg. steering committee in a timely manner; and</p>
 </li>
 <li>
 <p>Minutes from meetings must be approved, typically at the next scheduled meeting.</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>Approved meeting minutes must be made publicly available to all working group members as early as practical, typically by either being posted to the working group’s dedicated website and/or distributed via the working group’s general mailing list.</p>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="communication"><a class="anchor" href="#communication"></a><a class="link" href="#communication">Communication</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>The primary communication channel for a working group must be a mailing list that is managed by the Eclipse Webmaster in the eclipse.org domain. The working group will initially be assigned a single public mailing list with archive. Additional public and private mailing lists may be created as required. <a href="#mailing-lists">Mailing lists</a> are created during the <a href="#proposal-phase">Proposal Phase</a> (or as required in any phase thereafter).</p>
 </div>
 <div class="paragraph">
 <p>See below for more detail on other communications channels.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="votes"><a class="anchor" href="#votes"></a><a class="link" href="#votes">Votes</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p><strong>Quorum</strong> - A simple majority of the committee members shall be necessary to constitute a quorum for the transaction of business, except that when the number of members shall be an even number, one-half of the members shall constitute a quorum.</p>
 </div>
 <div class="paragraph">
 <p><strong>Voting</strong> - A simple majority vote of the committee members where quorum is present, except that when the number of votes shall be an even number, one half plus one shall constitute a simple majority.</p>
 </div>
 <div class="paragraph">
 <p>All committees may hold electronic votes for any decisions that would otherwise be taken at a committee meeting.  With respect to quorum for electronic votes, quorum is based on  all eligible voters when holding a vote</p>
 </div>
 <div class="paragraph">
 <p>The Eclipse Bylaws include more information regarding voting and voting procedures; in areas where this Operations Guide is silent, or in the case of any discrepancy between this Operations Guide and the Eclipse Bylaws, the Bylaws take precedence.  Should any disputes arise relating to voting, the Executive Director of Eclipse Foundation shall have the final decision.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="specification-process"><a class="anchor" href="#specification-process"></a><a class="link" href="#specification-process">Specification Process</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>A working group that engages in specification development must implement the Eclipse Foundation Specification Process.</p>
 </div>
 <div class="paragraph">
 <p>A working group may engage in specification lifecycle events (e.g., creation and progress reviews) while in the <a href="#incubation-phase">incubation phase</a>, but must be in the <a href="#operational-phase">operational phase</a> before its specification committee can ratify a Final Specification. That is, a working group may only release a Final Specification after it has entered the operational phase.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="grievance-handling"><a class="anchor" href="#grievance-handling"></a><a class="link" href="#grievance-handling">Grievance Handling</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>All individuals involved in a working group, either representing themselves or their member organization, are expected to conduct themselves in accordance with the Eclipse Foundation’s <a href="https://www.eclipse.org/org/documents/Community_Code_of_Conduct.php">Community Code of Conduct</a>, and to generally work to contribute to the overall objectives identified for the working group.  Should an individual have a grievance and wish to escalate that grievance, a working group representative may (in this order):</p>
 </div>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
 <p>Raise their grievance via the established channel (i.e., “ping” the channel; e.g., add a comment to a Bugzilla issue, or send an email to the working group list);</p>
 </li>
 <li>
 <p>Connect with the working group’s program manager;</p>
 </li>
 <li>
 <p>Connect with the EMO.</p>
 </li>
 </ol>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="assets"><a class="anchor" href="#assets"></a><a class="link" href="#assets">Assets</a></h2>
 <div class="sectionbody">
 <div class="sect2">
 <h3 id="names-and-logos"><a class="anchor" href="#names-and-logos"></a><a class="link" href="#names-and-logos">Names and Logos</a></h3>
 <div class="paragraph">
 <p>A working group’s name is a brand. It is a significant asset around which a working group builds reputation and good will. As such, the name must be protected against potential infringement and unauthorized use. To protect this valuable asset, the Eclipse Foundation registers the name of all working groups as a trademark (referred to as a “wordmark”). Likewise, a working group may establish one or more logos (referred to as a “design mark”) which may, at the discretion of the working group and Eclipse Foundation, be registered as trademarks.</p>
 </div>
 <div class="paragraph">
 <p>In order to have a strong trademark that can be protected it is important to try and create a name that is new and unique. A strong and unique trademark name will offer more protection and is less likely to encounter future oppositions. Trademarks are important and valuable assets for both businesses and consumers. A distinctive mark allows a business to build public goodwill and brand reputation in the goods or services it sells. Some of the strongest and most unique trademarks are created from invented words. Invented words are a good choice as trademarks because they are not descriptive and tend to be distinct.</p>
 </div>
 <div class="paragraph">
 <p>When choosing a trademark:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Avoid trademarks that are purely descriptive;</p>
 </li>
 <li>
 <p>Avoid using names and surnames in your trademark;</p>
 </li>
 <li>
 <p>Never incorporate someone else’s trademark into your own trademark;</p>
 </li>
 <li>
 <p>Do not choose a generic name;</p>
 </li>
 <li>
 <p>Avoid using a place or origin for your trademark; and</p>
 </li>
 <li>
 <p>Avoid using a name that may be confused with a registered or a pending trademark.</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>Note that descriptive phrases cannot function as a trademark and therefore can never be registered or protected under common law. Generic trademarks are common terms used to name products or services, for example, a brand of shoes called "shoes". Generic trademarks describe a product, so no one can register them as trademarks. These marks do not qualify for any type of trademark or common law protection.</p>
 </div>
 <div class="paragraph">
 <p>To initiate the review of a working group name or logo trademark, the working group sponsor must initiate a trademark with the Eclipse Trademarks Team via the <a href="mailto:trademarks@eclipse-foundation.org">Eclipse Foundation Trademarks Inbox</a>. If a logo will be utilized, please provide a clear copy of the image and attach it to the email. The logo copyright information must also be provided.</p>
 </div>
 <div class="paragraph">
 <p>The review process for all working group names and logos ensures that the Eclipse Foundation tracks and maintains records of the dates of usage and jurisdiction of use for all its intellectual property. This information is crucial when the Eclipse Foundation pursues formal registration or needs to enforce Common Law trademark rights for any of the Eclipse Foundation intellectual property.</p>
 </div>
 <div class="paragraph">
 <p>Working group participants must take reasonable steps to correctly use (and in doing so, protect) the working group’s word and design marks. The Eclipse Foundation <a href="https://www.eclipse.org/legal/logo_guidelines.php">Trademark Usage Guidelines</a> provides information on appropriate use of working group trademarks.</p>
 </div>
 <div class="paragraph">
 <p>Working group budgets must include an allocation for name and logo trademark registration.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="charter"><a class="anchor" href="#charter"></a><a class="link" href="#charter">Charter</a></h3>
 <div class="paragraph">
 <p>The initial charter is assembled during the Opportunity Phase and is finalized before a working group exits the Incubation phase. The charter <strong>must</strong> be based on the <a href="https://www.google.com/url?q=https://docs.google.com/document/d/1M7YKjR99xbZjZGW8Twv4Loc1EuOWw5eZoufy1owlgms/edit%23&amp;sa=D&amp;ust=1598292987033000&amp;usg=AFQjCNEGMhNtWBmWYCnPKEhexKBdLlfikg">template</a>. Write access to the charter document is initially granted to designated representatives from the Lead Organization to collaborate on its creation, but then extended to all representatives as the working group moves through the Incubation and Operational phases.</p>
 </div>
 <div class="paragraph">
 <p>Charters should be reviewed and updated as appropriate by the steering committee at least annually.</p>
 </div>
 <div class="paragraph">
 <p>The charter must define:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Vision and Scope including the Technical Scope;</p>
 </li>
 <li>
 <p>The <em>Governance and Precedence</em> of the various documents that guide the governance of the working group;</p>
 </li>
 <li>
 <p>The levels of <em>membership</em> and Eclipse Foundation membership levels;</p>
 </li>
 <li>
 <p>The various governing bodies (committees) that work on behalf of the working group and their common dispositions (good standing, voting, meeting management, etc.);
 and</p>
 </li>
 <li>
 <p>The fees for participating in the working group.</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>A working group charter must define at least a <em>Steering Committee</em> with responsibility to define and manage the strategy of the working group. A working group that is engaged in specification development must define a <em>Specification Committee</em> with responsibility to implement the Eclipse Foundation Specification Process for the projects in the purview of the working group. A working group that is engaged in marketing activities may define a <em>Marketing Committee</em> with responsibility to provide input into working group marketing prioritization.</p>
 </div>
 <div class="paragraph">
 <p>The powers, duties, and composition of each committee must be defined. In general:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Each Strategic Member of the working group is entitled to a seat on every committee.</p>
 </li>
 <li>
 <p>At least two seats are allocated to Gold Members. Gold Member seats are allocated following the Eclipse "Single Transferable Vote", as defined in the Eclipse Bylaws.</p>
 </li>
 <li>
 <p>At least one seat is allocated to Silver Members. Silver Member seats are allocated following the Eclipse "Single Transferable Vote", as defined in the Eclipse Bylaws.</p>
 </li>
 <li>
 <p>At least one seat is allocated to Committer Members. Committer Member seats are allocated following the Eclipse "Single Transferable Vote", as defined in the Eclipse Bylaws.</p>
 </li>
 <li>
 <p>In the case where a working group has strong alignment with one or more Top Level Projects, one or more seats may be allocated to representatives of the associated Project Management Committees (PMCs).</p>
 </li>
 <li>
 <p>Guest members that have been invited to the Steering Committee as observers. Guest members have no voting rights.</p>
 </li>
 <li>
 <p>The Executive Director may designate additional individuals as members</p>
 </li>
 <li>
 <p>The Committee elects a chair who reports to the Steering Committee. This chair is elected among the members of the Committee.</p>
 </li>
 <li>
 <p>The committee elects a secretary.</p>
 </li>
 </ul>
 </div>
 <div class="sect3">
 <h4 id="applicable-governance-documents"><a class="anchor" href="#applicable-governance-documents"></a><a class="link" href="#applicable-governance-documents">Applicable Governance Documents</a></h4>
 <div class="paragraph">
 <p>The following documents define the governance of the Eclipse Foundation in general, and working groups, open source projects, and open source specifications in particular. Terms outlined in a working group charter must be consistent with these governance documents.</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/eclipse_foundation-bylaws.pdf">Eclipse Foundation Bylaws</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/eclipse_membership_agreement.pdf">Eclipse Foundation Membership Agreement</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Eclipse Foundation Intellectual Property Policy</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/documents/Eclipse_Antitrust_Policy.pdf">Eclipse Foundation Antitrust Policy</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/org/workinggroups/industry_wg_process.php">Eclipse Foundation Working Group Process</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/projects/dev_process/development_process.php">Eclipse Foundation Development Process</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/projects/efsp/">Eclipse Foundation Specification Process</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/legal/efsl.php">Eclipse Foundation Specification License</a></p>
 </li>
 <li>
 <p><a href="https://www.eclipse.org/legal/tck.php">Eclipse Foundation Technology Compatibility Kit License</a></p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="pitch-deck"><a class="anchor" href="#pitch-deck"></a><a class="link" href="#pitch-deck">Pitch Deck</a></h3>
 <div class="paragraph">
 <p>All working groups have the responsibility to ensure the value proposition for new members to join, and to make clear the criteria by which those new members may join. To facilitate this obligation, each working group typically creates a pitch deck.</p>
 </div>
 <div class="paragraph">
 <p>The pitch deck is generally created after the working group has entered the <em>Opportunity</em> phase. Write access to the pitch deck is initially granted to designated representatives from the Lead Organization to collaborate on its creation, but then extended to all representatives as the working group moves through the Incubation and <em>Operation</em> phases..</p>
 </div>
 <div class="paragraph">
 <p>A pitch deck may be based on an existing template or example, and may use custom branding. The pitch deck must be available for use by all members.</p>
 </div>
 <div class="paragraph">
 <p>Many working groups, once operational, create a membership prospectus that takes the place of a pitch deck.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="pipeline"><a class="anchor" href="#pipeline"></a><a class="link" href="#pipeline">Pipeline</a></h3>
 <div class="paragraph">
 <p>As working groups are being established, and through to the operational phase, it is in the interest of all parties to recruit members to the working group.  As such, a pipeline document, generally a spreadsheet, is a working document used to manage the pipeline of membership opportunities associated with the working group.</p>
 </div>
 <div class="paragraph">
 <p>The pipeline document is shared with working group participants via the Shared Drive.</p>
 </div>
 <div class="paragraph">
 <p>Once operational, each steering committee may decide whether to maintain an ongoing pipeline document.  If so, the document must be available to all members of the steering committee. Separate from the pipeline document, potential new members often engage directly with the Eclipse Foundation to explore whether to join a particular working group; these discussions may not always be shared with the steering committee, and the decision whether to do so lies with the Foundation.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="initiation-agreement"><a class="anchor" href="#initiation-agreement"></a><a class="link" href="#initiation-agreement">Initiation Agreement</a></h3>
 <div class="paragraph">
 <p>A Working Group Initiation Agreement is a bilateral agreement between the Eclipse Foundation and the Lead Organization(s). This agreement details the goals, scope, measures of success, responsibilities, and milestones to create a Working Group. At a minimum, it specifically describes work related to trademarks, logos, web properties, target member participation (i.e., pipeline), success criteria, etc.</p>
 </div>
 <div class="paragraph">
 <p>As a member or members of the Foundation come forward expressing an interest in forming a working group (the founding members), they will work together with the Foundation membership team to identify the details listed above, and to negotiate the terms of the agreement and the associated fees and payment schedule.  As stipulated in the Eclipse Foundation Working Group Process, it is the responsibility of the founding members to cover the costs of the Foundation through the initial phases of establishing a working group.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="participation-agreement"><a class="anchor" href="#participation-agreement"></a><a class="link" href="#participation-agreement">Participation Agreement</a></h3>
 <div class="paragraph">
 <p>A Working Group Participation Agreement (“Participation Agreement”) is a bilateral agreement between the Eclipse Foundation and each Participant in the Working Group that defines the responsibilities of each party in the Working Group. The Participation Agreement defines, among other terms, a commitment by each Participant to adhere to the Working Group Charter.</p>
 </div>
 <div class="paragraph">
 <p>The Eclipse Foundation has the responsibility to define the Participation Agreement.  Specifically, the Foundation’s Working Group Sponsor must work with the Working Groups Manager to produce a Working Group Participation Agreement (WGPA), or more simply the <em>participation agreement</em>, based on a template. Arbitrary modification of the terms laid out in the participation agreement is not supported. The Working Groups Manager retains the source form for all participation agreements; producing a PDF of the agreement for general dissemination. All members are required to execute the participation agreement.</p>
 </div>
 <div class="paragraph">
 <p>The participation agreement is initially shared via <a href="#shared-drive">shared drive</a>, but is published to the Eclipse Foundation’s Working Groups website when the working group enters the <em>Incubation</em> phase.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="program-plan-and-annual-budget"><a class="anchor" href="#program-plan-and-annual-budget"></a><a class="link" href="#program-plan-and-annual-budget">Program Plan and Annual Budget</a></h3>
 <div class="paragraph">
 <p>Following charter ratification, and subsequently on an annual basis, steering committees must look ahead to establish a program plan and budget for the upcoming fiscal year and ensure a fee schedule is in place to support the objectives and goals of the working group.  The Foundation’s fiscal year ends December 31.</p>
 </div>
 <div class="paragraph">
 <p>The general approach is to create a program plan to identify priorities to be accomplished during the next year.  The program plan must demonstrate a commitment to the vision and scope defined in the charter. Specifically, it should establish goals for the year along with specific actions planned to achieve those goals. Note that the marketing committee is expected to create a <a href="#marketing-plan">marketing plan</a> that aligns and complements the working group program plan.</p>
 </div>
 <div class="paragraph">
 <p>The program plan must identify whether dedicated resources, including full time Foundation staff, are required in order to fulfill the plan. Typically, full time, working group dedicated staff includes:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Full time Marketing Manager;</p>
 </li>
 <li>
 <p>Full time Program Manager; and</p>
 </li>
 <li>
 <p>Full time Developer Advocate.</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="sect2">
 <h3 id="infrastructure-plan"><a class="anchor" href="#infrastructure-plan"></a><a class="link" href="#infrastructure-plan">Infrastructure Plan</a></h3>
 <div class="paragraph">
 <p>All working groups must create and maintain an infrastructure plan that describes the infrastructure needs of the working group in concise terms. The infrastructure plan must be a living document that is updated with information about the services as they are allocated. In effect, the infrastructure plan becomes a “one stop” source of information about the resources allocated to and managed by and on behalf of the working group.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="marketing-plan"><a class="anchor" href="#marketing-plan"></a><a class="link" href="#marketing-plan">Marketing Plan</a></h3>
 <div class="paragraph">
 <p>A marketing plan describes the marketing programs and activities to support the goals and objectives of the working group as articulated by the Program Plan. The marketing plan captures the marketing and communications strategies, tactics, and resources required to grow the awareness of and participation in the working group, including driving the discoverability and commercial adoption of the Eclipse projects operating under the purview of the working group. Additionally, the marketing plan will typically outline the positioning, messaging, value proposition, and content required to drive audience, membership, and community growth.</p>
 </div>
 <div class="paragraph">
 <p>Sample contents for the marketing plan include:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Strategy and Goals: Working group goals and objectives (restated from the Program Plan); what actions we need others to take</p>
 </li>
 <li>
 <p>Environmental Analysis: Market context, key trends, opportunities, challenges, i.e., the market and industry conditions under which we are operating</p>
 </li>
 <li>
 <p>Audience and Segmentation: Who we must reach and convince, what are their motivations, goals, and values</p>
 </li>
 <li>
 <p>Messaging: Specific messages that will move our audience to action</p>
 </li>
 <li>
 <p>Marketing Tactics: How we will deliver our messages, e.g., content (white papers, case studies, videos, other collateral assets), advertising, public relations and analyst relations, community events, etc.</p>
 </li>
 <li>
 <p>Action Plan: Actions we will take in the plan period</p>
 </li>
 <li>
 <p>Resources: Resources required to deliver on the plan, e.g., budget, effort, member contributions</p>
 </li>
 <li>
 <p>Metrics: How we will measure progress and achievement of goals
 “No plan” is a valid plan, in that the working group may elect not to develop a marketing plan.</p>
 </li>
 </ul>
 </div>
 </div>
 <div class="sect2">
 <h3 id="annual-budget"><a class="anchor" href="#annual-budget"></a><a class="link" href="#annual-budget">Annual Budget</a></h3>
 <div class="paragraph">
 <p>A budget is then prepared to support the program plan.   The budget’s revenue projections are based on the anticipated revenues for the following year, typically based on current membership and associated fees. The budget should identify targeted spending to match the program plan.  The budget should account for covering the costs of support by the Eclipse Foundation, including both staff directly engaged with the working group such as the Program Manager, Marketing Manager, or Developer Advocate based on a loaded labor rate provided by the Foundation, as well as the ancillary support of other Foundation staff in areas such as infrastructure and web development, IP and legal support, etc. In addition, the budget should identify expected spend on infrastructure requirements, marketing activities such as content development, developer outreach, event sponsorship, etc.  The Foundation also imposes a General and Administrative (G&amp;A) fee for all working group spending; the rate for the G&amp;A is established each year by the Foundation.</p>
 </div>
 <div class="paragraph">
 <p>Working group fee structures are generally in place by October for the next fiscal year which commences in January. The charter and participation agreement must be updated to reflect any changes in the fee structure.</p>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="resources-and-services"><a class="anchor" href="#resources-and-services"></a><a class="link" href="#resources-and-services">Resources and Services</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>All working groups must be assigned a short name. As with Eclipse open source projects, the short name is used in technical namespaces (e.g., mailing lists, Slack workspace). The short name is all lowercase with no whitespace, containing only alphanumeric and dash characters. e.g., “ECD Tools” Working group has the short name “ecd-tools”; the mailing list is <strong>ecd-tools-wg@eclipse.org</strong>, and the Slack workspace is <strong>ecd-tools-wg.slack.com</strong>, etc.</p>
 </div>
 <div class="sect2">
 <h3 id="typical-infrastructure-and-services"><a class="anchor" href="#typical-infrastructure-and-services"></a><a class="link" href="#typical-infrastructure-and-services">Typical Infrastructure and Services</a></h3>
 <div class="paragraph">
 <p>The following services may be made available to a working group. Note that real costs are associated with many of these services, and that those costs must be factored into the working group budget.</p>
 </div>
 <div class="sect3">
 <h4 id="internal-folder"><a class="anchor" href="#internal-folder"></a><a class="link" href="#internal-folder">Internal Folder</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Working Group Sponsor.</p>
 </div>
 <div class="paragraph">
 <p>The Internal Folder is a folder/directory under the “Working Groups” Google Drive. Access to the Internal Folder, and all of the resources contained within, is limited to Eclipse Foundation Staff.</p>
 </div>
 <div class="paragraph">
 <p>Due to the nature of permission handling in Google Drive, access is controlled at the “Working Group” Shared Drive level, so all Eclipse Foundation staff engaged in Working Group activity have, by default, homogeneous access to content in these directories. Additional access may be granted at the discretion of the sponsor.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="shared-drive"><a class="anchor" href="#shared-drive"></a><a class="link" href="#shared-drive">Shared Drive</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Working Group Sponsor and Program Manager.</p>
 </div>
 <div class="paragraph">
 <p>The Shared Drive is a Shared Drive in the Eclipse Foundation’s Google Drive. All participants of the working group’s committees (and their designated alternates) have read/write access. Access to the Shared Drive is limited to the working group participants and Eclipse Foundation staff.</p>
 </div>
 <div class="paragraph">
 <p>The Program Manager and Sponsor (or their designate) manage access to the Shared Drive.</p>
 </div>
 <div class="paragraph">
 <p>The working group’s charter, infrastructure plan, budget, and all marketing materials are stored in the Shared Drive.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="mailing-lists"><a class="anchor" href="#mailing-lists"></a><a class="link" href="#mailing-lists">Mailing Lists</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Eclipse Webmaster, Program Manager, and/or the Working Groups Manager.</p>
 </div>
 <div class="paragraph">
 <p>The Eclipse Webmaster will create one or more mailing lists, generally one “-wg” list for the working group as a whole and one for each committee, as requested.</p>
 </div>
 <div class="paragraph">
 <p>Mailing lists follow these patterns:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>&lt;shortname&gt;-<a href="mailto:wg@eclipse.org">wg@eclipse.org</a></p>
 </li>
 <li>
 <p>&lt;shortname&gt;-<a href="mailto:wg-steering-committee@eclipse.org">wg-steering-committee@eclipse.org</a></p>
 </li>
 <li>
 <p>&lt;shortname&gt;-<a href="mailto:wg-marketing-committee@eclipse.org">wg-marketing-committee@eclipse.org</a></p>
 </li>
 <li>
 <p>&lt;shortname&gt;-<a href="mailto:wg-specification-committee@eclipse.org">wg-specification-committee@eclipse.org</a></p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>The first list is created as an open list that anybody can join. Participation in the committee lists is initially restricted to committee members, designated alternative representatives, and Eclipse Foundation staff; and do not have archives. Participation restrictions for these lists may be changed at the discretion of the committees. The general working group list is open with publicly accessible archives.</p>
 </div>
 <div class="paragraph">
 <p>Other mailing lists may be created by request of the working group’s steering committee; these lists may be public with archive or private without archive. Other configurations are not supported. Additional mailing lists may include a community list, an adopters list, a specifications’ discussion list, etc.</p>
 </div>
 <div class="paragraph">
 <p>In order to subscribe to mailing lists, a user must first create an <a href="https://www.eclipse.org/projects/handbook/#contributing-account">Eclipse Foundation account</a>.  In cases where the mailing list is restricted to committee members, requests to add or remove mailing list participants must be directed to the Program Manager or Sponsor. Email addresses without an eclipse.org account should not be subscribed to a mailing list.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="github-organization"><a class="anchor" href="#github-organization"></a><a class="link" href="#github-organization">GitHub Organization</a></h4>
 <div class="paragraph">
 <p>If required, a GitHub organization may be allocated and administered by the steering committee (or their designate).</p>
 </div>
 <div class="paragraph">
 <p>A GitHub organization may be created for a working group at the beginning of the <em>Incubation Phase</em> or at any time thereafter. The organization must be used only for the development of working group specific resources (e.g. white papers or test beds); and must not include any project-specific content (e.g. project documentation).</p>
 </div>
 <div class="paragraph">
 <p>The Eclipse Webmaster, Working Group Sponsor, and Program Manager (when applicable) must all have administrative (owner) access. The organization must respect the trademark usage guidelines of both the Eclipse Foundation and the working group (including pointers, when available, to the official Working Group website).</p>
 </div>
 <div class="paragraph">
 <p>The steering committee must document a policy for managing the organization in a vendor neutral manner, and must appoint administrators tasked with implementing that policy. Specifically, member company employees must manage the day-to-day operations of this organization. Only employees of working group members may be granted privileged access to working group resources.</p>
 </div>
 <div class="paragraph">
 <p>If a need for technical support is anticipated, the working groups must negotiate a service agreement with the Eclipse Webmaster.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="website"><a class="anchor" href="#website"></a><a class="link" href="#website">Website</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Eclipse Webmaster.</p>
 </div>
 <div class="paragraph">
 <p>Hugo-based website, owned and managed by the Eclipse Foundation, and hosted on GitHub (either in the <a href="https://github.com/EclipseFdn">EclipseFdn</a> organization or in a working group specific GitHub organization). Design and creation of the website starts when the proposal enters the Incubation Phase; and deployed in advance of the Working Group entering the Operational Phase. The steering committee must document a policy for determining who has privileged access to this resource.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="zoom"><a class="anchor" href="#zoom"></a><a class="link" href="#zoom">Zoom</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Eclipse Webmaster.</p>
 </div>
 <div class="paragraph">
 <p>A Zoom channel may be allocated for working group committee calls. We generally allocate a single channel to be shared by all working group committees.</p>
 </div>
 <div class="paragraph">
 <p>Note that Zoom calls may be recorded, but that reasonable effort must be undertaken in advance to ensure that all attendees are aware of the intention to record and that there is no objection.</p>
 </div>
 <div class="paragraph">
 <p>Note that using Zoom requires that users agree to the Zoom terms of use; some individuals and organizations may not be able (or may not desire to) agree to these terms. That is, participation via Zoom may be a barrier for entry. Other accommodations are possible, provided that all members are granted access to such calls.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="google-calendar"><a class="anchor" href="#google-calendar"></a><a class="link" href="#google-calendar">Google Calendar</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Working Group Sponsor and Program Manager.</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="slack"><a class="anchor" href="#slack"></a><a class="link" href="#slack">Slack</a></h4>
 <div class="paragraph">
 <p>Allocated and administered by the Working Group Sponsor and Program Manager.</p>
 </div>
 <div class="paragraph">
 <p>The workspace name should take the form “&lt;shortname&gt;-wg.slack.com”.</p>
 </div>
 <div class="paragraph">
 <p>Note that using Slack requires that users agree to the Slack terms of use; some individuals and organizations may not be able (or may not desire to) agree to these terms. That is, participation via Slack may be a barrier for entry.</p>
 </div>
 <div class="paragraph">
 <p>Slack should only ever be used for ephemeral discussions.</p>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="other-resources-and-services"><a class="anchor" href="#other-resources-and-services"></a><a class="link" href="#other-resources-and-services">Other Resources and Services</a></h3>
 <div class="paragraph">
 <p>The working group can leverage other services. But access to those services needs to be open equally to all working group members. So, a working group could, for example, allocate their own Trello workspace, so long as all working group participants can access it and the working group defines clear rules for getting increased privileges on the resource.</p>
 </div>
 <div class="paragraph">
 <p>Note that the Eclipse team cannot generally help with administrative tasks related to nonstandard resources and services. The working group must decide (and document) a means of managing access, and the keys (i.e., administrative access) must be shared. Webmaster must be granted administrative rights to any shared resource.</p>
 </div>
 <div class="paragraph">
 <p>Bear in mind that many services require that users agree to terms of use that some may not or can not agree to. That is, the terms of use may be a barrier for entry that excludes some participants  (FWIW, we have some community members who cannot agree to the terms of use to use a Slack workspace).</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="infrastructure-audits"><a class="anchor" href="#infrastructure-audits"></a><a class="link" href="#infrastructure-audits">Infrastructure Audits</a></h3>
 <div class="paragraph">
 <p>Working groups must engage in an annual audit of infrastructure. The audit includes a review of, for example, who has access to what resources.</p>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="lifecycle"><a class="anchor" href="#lifecycle"></a><a class="link" href="#lifecycle">Lifecycle</a></h2>
 <div class="sectionbody">
 <div class="sect2">
 <h3 id="opportunity-phase"><a class="anchor" href="#opportunity-phase"></a><a class="link" href="#opportunity-phase">Opportunity Phase</a></h3>
 <div class="paragraph">
 <p>A working group exits in the <em>Opportunity</em> phase when:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Working Group Sponsor identified;</p>
 </li>
 <li>
 <p>Lead Organization identified;</p>
 </li>
 <li>
 <p>Initiation Agreement executed;</p>
 </li>
 <li>
 <p>Draft Working Group Charter complete;</p>
 </li>
 <li>
 <p>Participant Pipeline established; and</p>
 </li>
 <li>
 <p>Executive Director approval.</p>
 </li>
 </ul>
 </div>
 <div class="sect3">
 <h4 id="check-list"><a class="anchor" href="#check-list"></a><a class="link" href="#check-list">Check list</a></h4>
 <div class="paragraph">
 <p>A working group is ready to move into the Proposal Phase when the following conditions have been met.</p>
 </div>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Working Group name selected</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Working Group Sponsor identified</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Lead Organization identified</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Initiation Agreement executed by Lead Organization</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Internal Folder in the “Working Groups” Google Drive created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Shared Drive created</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Lead organization representatives granted access</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Shared Documents created</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Participation Agreement created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Pipeline document (spreadsheet) created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Charter created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Pitch Deck created</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Pipeline includes a minimum of five companies</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Executive Director approval</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="proposal-phase"><a class="anchor" href="#proposal-phase"></a><a class="link" href="#proposal-phase">Proposal Phase</a></h3>
 <div class="paragraph">
 <p>A working group exits in the <em>Proposal</em> phase when:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Recruiting Materials created;</p>
 </li>
 <li>
 <p>Draft Marketing Plan completed;</p>
 </li>
 <li>
 <p>Services and required infrastructure identified;</p>
 </li>
 <li>
 <p>Initial Working Group Charter published;</p>
 </li>
 <li>
 <p>Minimum of three Participants committed; and</p>
 </li>
 <li>
 <p>Executive Director approval.
 A working group that has made no progress towards moving into the incubation phase for more than three months will be terminated.</p>
 </li>
 </ul>
 </div>
 <div class="sect3">
 <h4 id="check-list-2"><a class="anchor" href="#check-list-2"></a><a class="link" href="#check-list-2">Check list</a></h4>
 <div class="paragraph">
 <p>A working group is ready to move into the Incubation Phase when the following conditions have been met.</p>
 </div>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Tile added to the working groups landing page</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Charter posted to the website</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Interim committee chairs identified and appointed by EMO(ED)</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Interim committee secretaries identified</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Working group announced to the Foundation’s General Assembly (formerly the Foundation’s Membership-At-Large)</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Primary “Working Group” (&lt;shortname&gt;-<a href="mailto:wg@eclipse.org">wg@eclipse.org</a>) Mailing list created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Infrastructure Plan (document) created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Draft marketing plan created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Recruitment materials created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Name is selected</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Approved as a common law trademark by the Eclipse Trademarks Team</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Executed participation agreements from at least three different companies</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Executive Director approval</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="incubation-phase"><a class="anchor" href="#incubation-phase"></a><a class="link" href="#incubation-phase">Incubation Phase</a></h3>
 <div class="ulist">
 <ul>
 <li>
 <p>Communication infrastructure established;</p>
 </li>
 <li>
 <p>Charter published;</p>
 </li>
 <li>
 <p>Working group committees (as defined by the charter) operational;</p>
 </li>
 <li>
 <p>(If applicable) Working Group Specification Process defined;</p>
 </li>
 <li>
 <p>Marketing plan and budget defined;</p>
 </li>
 <li>
 <p>Budget approved;</p>
 </li>
 <li>
 <p>Minimum of five participants committed; and</p>
 </li>
 <li>
 <p>Executive Director approval.</p>
 </li>
 </ul>
 </div>
 <div class="paragraph">
 <p>A working group that has made no progress towards moving to the operation phase for more than three months will be terminated.</p>
 </div>
 <div class="sect3">
 <h4 id="check-list-3"><a class="anchor" href="#check-list-3"></a><a class="link" href="#check-list-3">Check list</a></h4>
 <div class="paragraph">
 <p>A working group is ready to move into the Operational Phase when the following conditions have been met.</p>
 </div>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Committee mailing lists created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Zoom channel created</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Slack workspace created (&lt;short-name&gt;-wg.slack.com)</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Sponsor (or their designate) added as administrator</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Eclipse Webmaster added as administrator</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Lead organization representative added as administrator</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Charter complete; updated on website</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Name trademark (wordmark) registration initiated</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Logo finalized</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Approved as a common law trademark by the Eclipse Trademarks Team</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Added to working groups landing page title</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> (optional) Trademark registration initiated</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Recruiting materials complete</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Budget defined and approved by the steering committee</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Marketing plan complete</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Infrastructure plan signed off by steering committee and Eclipse Foundation</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Committees established</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Initial representatives appointed</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Meetings scheduled</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Executed participation agreements from at least five different companies</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Executive Director approval</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="operational-phase"><a class="anchor" href="#operational-phase"></a><a class="link" href="#operational-phase">Operational Phase</a></h3>
 <div class="paragraph">
 <p>A working group that is in the Operational Phase is, well, operational. During this phase, the working group operations</p>
 </div>
 <div class="sect3">
 <h4 id="check-list-4"><a class="anchor" href="#check-list-4"></a><a class="link" href="#check-list-4">Check List</a></h4>
 <div class="ulist">
 <ul>
 <li>
 <p>Website Launch/Press Release</p>
 </li>
 <li>
 <p>Implement Charter</p>
 </li>
 <li>
 <p>Open innovation</p>
 </li>
 <li>
 <p>Committee Meetings</p>
 </li>
 <li>
 <p>Promotion/Marketing</p>
 </li>
 <li>
 <p>Specification Process (when applicable)</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect2">
 <h3 id="termination-archived-phase"><a class="anchor" href="#termination-archived-phase"></a><a class="link" href="#termination-archived-phase">Termination/Archived Phase</a></h3>
 <div class="paragraph">
 <p>A working group that is no longer viable is terminated and archived.</p>
 </div>
 <div class="paragraph">
 <p>The Eclipse Foundation Working Group Process does not formally define an <em>Archived Phase</em>, only that working groups may be terminated (“archived” is less a phase than it is an acknowledgement that the working group is not currently active). At least in theory, a working group may be unarchived back into one of the formal phases.</p>
 </div>
 <div class="paragraph">
 <p>Some assets will remain on the website indefinitely. Charters, for example, will persist, but be labeled as “Archived”. Working group participation agreements, however, are completely removed from all public sites.</p>
 </div>
 <div class="paragraph">
 <p>What do we do with working group assets when a working group terminates?</p>
 </div>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Public Termination Notice sent to working group communication channel</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Shared Drive and Internal Folder archived</p>
 <div class="ulist checklist">
 <ul class="checklist">
 <li>
 <p><i class="fa fa-square-o"></i> Contents from public Shared Drive moved into “Public” folder in Internal Folder</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> (now empty) Shared Drive deleted</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Internal Folder moved to “Archived”</p>
 </li>
 </ul>
 </div>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Charter marked as “archived” on website</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Related Working Group Participation Agreements removed and archived</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Tile on the <a href="https://www.eclipse.org/org/workinggroups/explore.php">“Explore” page</a> removed</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Bullet in the “Terminated Working Groups” added</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Website deactivated and archived, domains/URLs redirected to “Explore” page</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Zoom workspace retired</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Slack workspace deleted</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Participation Agreements expired in Foundation database</p>
 </li>
 <li>
 <p><i class="fa fa-square-o"></i> Formal communication sent to affected members confirming termination and invalidation of related agreement.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="faq"><a class="anchor" href="#faq"></a><a class="link" href="#faq">FAQ</a></h2>
 <div class="sectionbody">
 <div class="qlist qanda">
 <ol>
 <li>
 <p><em>Does every working group have a program manager? </em></p>
 <p>No. The program manager role must be funded, and so only those working groups that include funding for a program manager in their budget have one.</p>
 </li>
 <li>
 <p><em>Does a working group need to be in the operational phase to engage in specification work? </em></p>
 <p>No. A working group may initiate ballots for many specification project lifecycle events while in the incubation phase. A working group’s specification committee may, for example, engage in a ballot to create a new specification project (or convert an existing Eclipse open source project into a specification project while still in incubation.</p>
 <div class="paragraph">
 <p>A working group must, however, be in the operational phase before its specification committee may approve and ratify a Final Specification for release.</p>
 </div>
 </li>
 <li>
 <p><em>Can a working group in the incubation phase release a specification? </em></p>
 <p>No. Specification projects operating under the purview of a working group in the incubation phase may engage in all lifecycle events except the ratification and release of a Final Specification.</p>
 </li>
 <li>
 <p><em>Can a working group combine committees? </em></p>
 <p>Yes. A working group may combine committees. It may be desirable to, for example, to assign specification committee responsibilities to a working group’s steering committee. In this case, the specification committee would play the role of the specification committee in all matters related to the specification process (the steering committee would, in effect, be the specification committee). The nature and make up of committees is defined in a working group’s charter.</p>
 </li>
 </ol>
 </div>
 </div>
 </div>