Eclipse Foundation Working Group Operations Guide
- Guiding Principles
- Code of Conduct
- Relationship with Open Source Projects
- Special Interest Groups
- Engagement with Eclipse Foundation Staff and Resources
- Grievance Handling
- Resources and Services
This document describes the lifecycle and operation of Eclipse Foundation Working Groups. In particular, this document describes how the Eclipse Foundation implements the Eclipse Foundation Working Group Process.
The following documents define the governance of the Eclipse Foundation in general, and working groups, open source projects, and open source specifications in particular.
- Eclipse Foundation Bylaws
- Eclipse Foundation Membership Agreement
- Eclipse Foundation Intellectual Property Policy
- Eclipse Foundation Antitrust Policy
- Eclipse Foundation Code of Conduct
- Eclipse Foundation Communication Channel Guidelines
- Eclipse Foundation Working Group Process
- Eclipse Foundation Development Process
- Eclipse Foundation Specification Process
- Eclipse Foundation Specification License
- Eclipse Foundation Technology Compatibility Kit License
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.
All Working Groups must operate in an open and transparent manner.
Open - Working Groups provide the same opportunity to all Members to participate in accordance with the Charter. Everyone participates with the same rules; there are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.
Transparent - Minutes, plans, and other artifacts are open and easily accessible to all.
Working groups, like all communities associated with the Eclipse Foundation, must operate in adherence to the Foundation's Code of Conduct.
All individuals involved in a working group, either representing themselves or their member organization, are obligated to conduct themselves in accordance with the Eclipse Foundation's Community Code of Conduct, and to generally work to contribute to the overall objectives identified for the working group.
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 ownership of projects. That is, working groups do not own or manage open source projects. Rather, working groups may express non-exclusive interest in some number of Eclipse open source projects. This set of projects of interest (or more simply, the working group's projects) 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 specification committee are automatically included in the working group's project set.
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).
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.
The union of the committers from a working group's projects comprise the working group committers.
The Working Groups Program Director 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 governance, processes and operations, and otherwise facilitate discussion and collaboration within the Working Groups Team.
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 Eclipse Foundation.
Directors, executives, and program managers engaged in the development of Eclipse Foundation working groups.
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.
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:
- Strategic Members 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). Strategic Members of the Working Group must be at least a Contributing Member of the Eclipse Foundation.
- 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. Participant Members of the Working Group must be at least a Contributing Member of the Eclipse Foundation.
- Committer Members 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 and either work for a member organization, or have chosen to complete the membership process independently. For further explanation and details, see the Eclipse Committer Membership page.
- Guest Members are organizations which are Associate members of the Eclipse Foundation. Typical guests include JUGs, R&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.
Supporting Members are: (a) organizations that want to participate in an open ecosystem related to the working group and wish to show their initial support for it, and (b) organizations that are at least Contributing members of the Eclipse Foundation. Organizations may be Supporting Members for a maximum period of 1 year only, after which time they are expected to change their membership to a different level. Supporting Members may be invited to participate in committee meetings at the invitation of the respective committee, but under no circumstances do Supporting Members have voting rights in any working group body. Supporting Members are required to execute the Working Group's Participation Agreement.
In different contexts, these levels may have different names, but the descriptions of the membership types must be fundamentally equivalent.
Strategic, Participant and Supporting working group membership classes must designate a minimum Eclipse Foundation membership level of Eclipse Contributing Member.
All working group members are required to sign the working group's Working Group Participation Agreement.
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.
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 Eclipse Foundation will establish a budget, as described below, each calendar year based on the expected revenue collected. Working Group fees must cover the full direct and indirect costs associated with its operation.
Specifications are created and maintained by Specification Projects. Each Specification Project is aligned with exactly one Working Group. Specification Projects are said to work under the purview of a particular Working Group, or—more specifically—the Specification Committee of a Working Group.
A working group that engages in specification development must implement the Eclipse Foundation Specification Process (EFSP). Prior to the Working Group engaging in any specification work, the Steering Committee must vote to adopt a particular version of the EFSP or derivative thereof. The Steering Committee must further vote to adopt a default Patent License (either Compatible Patent License or Implementation Patent License) as defined by the Eclipse Foundation Intellectual Property Policy.
A working group may engage in specification lifecycle events (e.g., creation and progress reviews) while in the incubation phase, but must be in the operational phase 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.
Eclipse Working Group Special Interest Groups (SIGs) provide a flexible collaborative structure allowing Eclipse member organizations to collaborate around a particular topic or domain within a broader working group. SIGs help bring like-minded working group members together to explore common interests within the scope of the working group. The goal of SIGs is to enable members to share expertise, discovery and best practices.
As an organizing model, and consistent with the working group process itself, SIGs cannot directly influence activities in open source projects. They can, however, align priorities of organizations that have committers on a project or projects.
At a high level, SIGs are formed within a Working Group to:
- Facilitate collaboration and cooperation between members of a working group around a specific scope
- Drive innovation within the ecosystem
- Accelerate technical advancements
- Strengthen and diversify the ecosystem by identifying and filling gaps in a specific project portfolio
Grow the community
- Attract complementary communities to the ecosystem
- Increase Working Group membership
- Promote and support a specific subset of open source projects and specifications under the purview of the working group
- Create a pathway to deeper participation and value of membership for all Working Group members at all levels
- All goals must be aligned with and be a focused subset of the overall working group's goals
The operating model is lightweight, meaning that it should take minimal intervention from Eclipse Foundation staff; rather, a SIG is operated self-sufficiently, and is managed by the SIG members themselves. Like working groups, it is incumbent that:
- The SIG must be proposed via the general mailing list of the Working Group for a minimum 14 day period. The proposal must include a description of the goals of the SIG, and how to participate
- The scope of the SIG must be consistent with the scope of the working group charter.
- The SIG must have at all times three or more member organizations participating
- The working group's Steering Committee must approve the formal creation of the SIG
- Once created, the SIG must name a Chair from within its membership
A SIG can be proposed by any member of the working group.The Steering committee must approve of creation of a SIG.
- The SIG must be proposed via the general mailing list of the Working Group for a minimum 14 day period. The proposal must include a description of the goals of the SIG, and how to participate.
- The scope of the SIG must be consistent with the scope of the working group charter.
- The SIG must have at all times three or more member organizations participating.
- The working group's Steering Committee must approve the formal creation of the SIG
- Once created, the SIG must name a Chair from within its membership
The primary functions of a Chair are administrative, including:
- Collecting and compiling topics for the meetings, and sharing the agenda beforehand
- Chairing meetings of the SIG
- Ensuring that meeting minutes are published to the Working Group's general mailing list
- Ensuring follow-up actions are tracked and resolved
- Liaise with the Working Group and ensure regular communications takes place
- Liaise with the Working Group Steering Committee and produce a succinct annual report of the SIG's activities
- SIGs operate as a non-governing body of the Working Group and inherit and adhere to the Working Group Charter
- Exceptions and disputes are handled by the Working Group Steering Committee with Eclipse Foundation Staff assistance
SIGs can function with the following collaboration and communication tools available to them.
- Mailing List (working group's general mailing list is to be utilized)
- Slack or Matrix channel located in the relevant Working Group's Workspace
- Gitlab project / repository (optional)
- Subfolder of the Working Group's Google drive
- Web page or section of a web page on related project(s) identifying the SIG mission and members
- The SIG must provide a quarterly verbal report to the Steering Committee on activities and participation of members
- The SIG must present a succinct written report to the Working Group once a year, outlining achievements and challenges
- The SIG can decide it wishes to be terminated, in which case it can make a request to the Steering Committee to do so. Regardless, a Steering Committee may terminate a SIG at any time.
- The SIG will be deemed retired if it is inactive for an extended period
- The SIG will be deemed retired if it has less than three participants
Exceptions to the above may be granted at the sole discretion of the Executive Director.
Sponsors are companies or individuals who provide money or services to the Working Group on an ad hoc basis to support the activities of the Working Group and its managed projects. Money or services provided by sponsors are used as set forth in the Working Group's annual budget. The Working Group is free to determine whether and how those contributions are recognized. Under no condition are sponsorship monies refunded.
Sponsors need not be members of the Eclipse Foundation or of the Working Group.
One of the benefits of creating a Working Group is to benefit from the engagement of the Eclipse Foundation professional staff, and to leverage the services offered by the Eclipse Foundation. As part of the operation of the working group, and in particular in the establishment of objectives, the execution of work items, and the Working Group's budget, the Working Group is expected to engage directly with the Eclipse Foundation in execution of the Working Group.
It is recommended that every Working Group allocate sufficient budget for a Program Manager, who works directly with the Steering Committee and the Working Group at large. The Program Manager serves as liaison between the various parties.
Regardless of whether a Program Manager is included in the budget, the budget must provide adequate funding and resources to achieve the stated objectives and related work items stemming from the Program Plan. This funding will, at a minimum, include funding to support the Eclipse Foundation staff involved, and for the Foundation to manage and oversee the Working Group appropriately. In turn, the Eclipse Foundation will, to the extent feasible within the budget constraints established, fulfill the work items as agreed to with the Working Group, and will in general engage in good faith to the betterment of the Working Group and its Participants.
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.
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 Eclipse Foundation Executive Director.
The initial (interim) chair for each committee is appointed by the Eclipse Foundation Executive Director or their designate. At the earliest opportunity, each committee must nominate and elect a new chair.
All working groups must conform to the Eclipse Foundation Antitrust Policy with respect to formal minutes and agendas of committee meetings. The secretary is the person who keeps and disseminates formal records of the working group'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).
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.
During committee meetings, committee members must put forward motions which must be seconded, before a vote can take place.
It'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.
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 Eclipse Foundation Working Group Process for more detailed responsibilities of the Steering Committee.
The specification committee, in addition to any other responsibilities given to it through the working group charter, is responsible for implementing the Eclipse Foundation Specification Process (EFSP) for all specification projects that operate under the working group's purview.
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.
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.
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 of a release review ballot) reporting them to the Eclipse Foundation.
The specification committee is also responsible for defining and refining how they implement the EFSP.
The specification committee is not 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.
A PMC is not directly aligned with any Working Group.
The composition and role of the Project Management Committee (PMC) is defined by the Eclipse Foundation Development Process (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.
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.
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.
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.
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.
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)
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.
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 Eclipse Foundation 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.
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).
If the working group does not establish such a committee, then the general responsibilities identified above fall to the steering committee
There exists no implicit hierarchical relationship between the committees.
It is the purview of the Steering Committee to set the strategy, establish the goals and objectives, and approve the budget. So from that perspective, the other committees are expected to execute in a manner that aligns with the agenda established by the Steering Committee within the funds allocated.
However, the Marketing Committee is independent in that the charter clearly states that it is responsible for "…marketing and communication activities for the working group". Thus the charter clearly states that responsibility for the marketing activities of the working group have been delegated to the marketing committee. Any oversight by the steering committee is to ensure that the marketing plans are consistent with goals and objectives established in the program plan. It is not to manage or direct the Marketing Committees activities, and the Steering Committee is not an escalation path for individual decisions or actions taken by the Marketing Committee.
This is entirely consistent with how Board committees work. Authority to specialize on a particular topic, to make decisions, and to take actions on behalf of the organization on matters within the stated scope, is why committees exist in governance bodies in the first place.
Each committee is a collegial body in its own right. Each makes decisions as a group. Hopefully consensus is reached, but if not then there are documented rules on what voting thresholds are required for different decisions.
The role of these committees is governance, not management. Ultimately this conversation resulted from a number of comments made by steering committee members in a recent meeting where they questioned decisions made by the marketing committee. From a governance perspective, the Steering Committee does not have the authority to do that.
It is also important to remember that no single member of any of the committees can state a position of the committee as a whole without a decision (vote) by the committee. Equally important, once a committee does take a decision, as a collegial body the members of the Committee must accept the decision and its implications.
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.
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 regular attendance at meetings.
Representatives may designate an alternate for committee representation. These alternates may be added to mailing lists and participate in meetings. Alternates can be assigned proxy for voting purposes.
We have created A Practical Guide to being a Working Group Representative which outlines in greater detail the roles and responsibilities of Committee Members including information on how meetings are to be held and decisions taken and so on.
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.
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's term of office.
Outgoing representatives remain in office until the newly-elected representatives take office. Once the results of the election are announced, the winners are officially elected and attend the first meeting of the next steering committee in the following month.
A working group's charter may define elected committee positions that represent the interests of all members of a particular class of working group membership (e.g., Participant members, Committer members). An election is required to select representatives for elected positions.
For membership classes other than Committer Members, all individuals who are employed by an organization that is a member of that class in the working group may stand for election. For Committer members, all Committer Members who are engaged in projects under the purview of the working group are eligible to stand for election.
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.
All positions may be self nominated.
The members of that constituency are likewise eligible to vote for their representative. For Committer Members, this means the Committer Members engaged in projects under the purview of the working group; for all other classes of membership, the working group representatives of each Member of that class may vote.
Elections pass through several phases:
- Working Group Election Announcement
- Nomination Phase (Call for Nominations/Extensions)
- Nomination Acceptance Phase - Confirmation, Bio's and Pictures Submissions
- Notice of Candidates Standing Phase
- Ballot Distribution Phase
- Count of Results Phase
- Election Results Announcement
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.
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.
A working group committee may opt to ask the Eclipse Foundation to run their ballot.
To request that a ballot be run by the Eclipse Foundation, a committee's chair can send the request to email@example.com. 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.
Nominations must be sent to firstname.lastname@example.org. Ballots are distributed to email addresses on file with the Eclipse Foundation.
Note that ballot distribution may be provided by the Eclipse Foundation via a third party election service.
The Eclipse Foundation utilizes the Single Transferable Vote (STV) to calculate election results.
Should a situation arise where a tie occurs, then a tie breaker will be performed virtually.
All working group committees will follow a prepared agenda and follow procedures set forth in the Eclipse Foundation By-laws. An agenda should be distributed prior to meetings. Committees must also produce and disseminate minutes of all committee meetings.
- Include attendees and company affiliations;
- Identify absent attendees and company affiliations;
- Record actions, decisions, and outstanding action items indicating responsibility;
- Minutes are to be distributed via the relevant committee mailing list eg. steering committee in a timely manner; and
- Minutes from meetings must be approved, typically at the next scheduled meeting.
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.
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. Mailing lists are created during the Proposal Phase (or as required in any phase thereafter).
See below for more detail on other communications channels.
For any meeting of a Body (e.g., a Steering Committee meeting), the Body will be deemed validly constituted and has the quorum to take decisions if at least a simple majority of the voting Body members are present, represented by a proxy, or participating remotely in the meeting. If the number of members constituting the Body is an even number, one-half (1/2) of the Body members present, represented or participating remotely in the meeting shall constitute a quorum.
Quorum is necessary in order to formally hold a meeting. Should quorum not be met, matters may be discussed but not decided.
For decisions requiring a simple majority, a simple majority is defined to be more than half the votes cast either in favor or against the motion. Note that if the number of votes cast is even, then the motion requires one half plus one for it to be approved. Also note that abstentions to a vote are permitted, and in such cases, the abstention does not count in the calculation of the majority, neither in the numerator nor in the denominator.
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.
The determination of who is eligible to vote is determined at the onset of any vote. At that time, Committee members must have appointed their representative to the relevant Committee in order to be eligible to have their ballot count, either to determine quorum or the outcome of the vote. As a reminder, all working groups members are eligible to appoint an individual to serve on the related Committees based on Committee compositions as per Working Group Charters; however, there is no obligation to do so. As a result, until such time as an individual is appointed, there is no consideration of that member's potential representation in the computation of quorum or being eligible to vote on any matter.
It's also worth noting that when a member changes its representative and does not provide a new representative, they no longer count towards quorum nor voting.
Appointed representatives on the Body may be replaced by the Member organization they are representing at any time by providing written notice to the Steering Committee. In the event a Body member is unavailable to attend or participate in a meeting of the Body, they may be represented by another Body member by providing written proxy to the Body's mailing list in advance. As per the Eclipse Foundation Bylaws, a representative shall be immediately removed from the Body upon the termination of the membership of such representative's Member organization. The way to utilize a proxy is to assign your proxy to another committee member. This can be done on list (preferably) or off-list, cc'ing the committee chair.
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.
Should an individual have a grievance and wish to escalate that grievance[a], a working group representative may (in this order):
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.
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.
When choosing a trademark:
- Avoid trademarks that are purely descriptive;
- Avoid using names and surnames in your trademark;
- Never incorporate someone else's trademark into your own trademark;
- Do not choose a generic name;
- Avoid using a place or origin for your trademark; and
- Avoid using a name that may be confused with a registered or a pending trademark.
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.
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 Eclipse Foundation Trademarks Inbox. 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.
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.
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 Trademark Usage Guidelines provides information on appropriate use of working group trademarks.
Working group budgets must include an allocation for name and logo trademark registration.
Trademark agencies make the following requirements for registering a design mark:
- Accepted file types: .tif, .jpg, .gif without motion, .png, .bmp. File size must not exceed 10.49MB.
- Maximum image size: 8cm x 8cm. Maximum resolution: 300dpi.
- If the applicant is claiming colour as a feature of the trademark (see below), the visual representation submitted must be in colour. In all other cases, the visual representation must be in black and white.
- Files with a transparent background are not accepted
Design marks must be submitted in black and white, with no grayscale.
The initial charter is assembled during the Opportunity Phase and is finalized before a working group exits the Incubation phase. The charter must be based on the template. 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.
Charters should be reviewed and updated as appropriate by the steering committee at least annually.
The charter must define:
- Vision and Scope including the Technical Scope;
- The Governance and Precedence of the various documents that guide the governance of the working group;
- The levels of membership and Eclipse Foundation membership levels;
- The various governing bodies (committees) that work on behalf of the working group and their common dispositions (voting, meeting management, terms and dates of elections, etc.); and
- The fees for participating in the working group.
A working group charter must define at least a Steering Committee with responsibility to define and manage the strategy of the working group. A working group that is engaged in specification development must define a Specification Committee 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 Marketing Committee with responsibility to provide input into working group marketing prioritization.
The powers, duties, and composition of each committee must be defined. In general:
- Each Strategic Member of the working group is entitled to a seat on every committee.
- 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.
- 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.
- 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.
- 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).
- Guest members that have been invited to the Steering Committee as observers. Guest members have no voting rights.
- The Executive Director may designate additional individuals as members
- The Committee elects a chair who reports to the Steering Committee. This chair is elected among the members of the Committee.
- The committee elects a secretary.
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.
The pitch deck is generally created after the working group has entered the Opportunity 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 Operation phases..
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.
Many working groups, once operational, create a membership prospectus that takes the place of a pitch deck.
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.
The pipeline document is shared with working group participants via the Shared Drive.
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.
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.
The general approach is to create a program plan which defines the strategy for implementing the vision and scope of the working group. It is used 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 marketing plan that aligns and complements the working group program plan.
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:
- Full time Marketing Manager;
- Full time Program Manager; and
- Full time Developer Advocate.
All Working Group activities must be:
- Consistent with the Eclipse Foundation values such as openness, transparency, meritocracy, and vendor neutrality;
- Fully compliant with the Eclipse Foundation policies such as privacy, antitrust, and intellectual property; and
- In accordance with the Eclipse Foundation accounting policies such as spending controls and revenue recognition.
The Eclipse Foundation is responsible for:
- Managing all contracting, disbursements, and vendor relationships;
- Delivering or managing the delivery of all work products such as website content, marketing collateral, legal documents, etc.;
- Hiring and managing any headcount dedicated to the working group, either directly or indirectly; and
- Providing financial reports showing execution versus budget.
The formal governance obligations lie with the Eclipse Board of Directors, the Eclipse Foundation's Executive Director, and Eclipse Foundation staff as defined within the Bylaws.
Each working group's budget rolls up into the Eclipse Foundation's overall budget, which is approved on an annual basis by the Board of Directors.
The Eclipse Foundation bears all fiduciary and operational responsibilities for the Working Group.
Working Group Program Plans and Budgets must be approved by the Executive Director.
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.
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.
Sample contents for the marketing plan include:
- Strategy and Goals: Working group goals and objectives (restated from the Program Plan); what actions we need others to take
- Environmental Analysis: Market context, key trends, opportunities, challenges, i.e., the market and industry conditions under which we are operating
- Audience and Segmentation: Who we must reach and convince, what are their motivations, goals, and values
- Messaging: Specific messages that will move our audience to action
- 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.
- Action Plan: Actions we will take in the plan period
- Resources: Resources required to deliver on the plan, e.g., budget, effort, member contributions
- 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.
A budget is then prepared by the Eclipse Foundation 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&A) fee for all working group spending; the rate for the G&A is established each year by the Foundation.
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.
Authority and responsibility for establishing and managing Working Group budgets lies with the Eclipse Foundation Executive Director (“Executive Director”) as defined in the Bylaws. Each Working Group's budget rolls up into the Foundation's overall budget, which is approved on an annual basis by the Eclipse Foundation's Board of Directors (“Board of Directors”).
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 email@example.com, and the Slack workspace is ecd-tools-wg.slack.com, etc.
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. Some working groups may have extraordinary infrastructure requirements that must be addressed as part of the working group infrastructure plan.
Allocated and administered by the Working Group Sponsor.
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.
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.
Allocated and administered by the Working Group Sponsor and Program Manager.
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.
The Program Manager and Sponsor (or their designate) manage access to the Shared Drive.
The working group's charter, infrastructure plan, budget, and all marketing materials are stored in the Shared Drive.
Allocated and administered by the Eclipse Webmaster, Program Manager, and/or the Working Group Programs Director.
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.
Mailing lists follow these patterns:
The public working group mailing list list is created as an open list with an archive that anybody can join.
Participation in the governing body committee lists is initially restricted to committee members, designated alternative representatives, and Eclipse Foundation staff. Committee lists do not have archives. This enables governing bodies to have open discussions prior to taking decisions.
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.
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.
In order to subscribe to mailing lists, a user must first create an Eclipse Foundation account. 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.
If required, a GitLab Group may be allocated and administered by the steering committee (or their designate).
A GitLab Group may be created for a working group at the beginning of the Incubation Phase or at any time thereafter. The group 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).
The Eclipse Webmaster, Working Group Sponsor, and Program Manager (when applicable) must all have administrative (owner) access. The group 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).
The steering committee must document a policy for managing the group 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 group. Only employees of working group members may be granted privileged access to working group resources.
If a need for technical support is anticipated, the working groups must negotiate a service agreement with the Eclipse Webmaster.
Allocated and administered by the Eclipse Webmaster.
Hugo-based website, owned and managed by the Eclipse Foundation, and hosted on GitLab (either in the Websites group or in a working group specific GitLab group). 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.
Allocated and administered by the Eclipse Webmaster.
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.
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.
Allocated and administered by the Working Group Sponsor and Program Manager.
Allocated and administered by the Working Group Sponsor and Program Manager.
The workspace name should take the form “<shortname>-wg.slack.com”.
Slack should only ever be used for ephemeral discussions.
Working Groups can request their own social media channels, which will be secured by the Eclipse Foundation marketing team. If the Working Group has previously created a social media account, they must transfer ownership to the Eclipse Foundation. The channels can be managed by Eclipse Foundation staff or social administrators from the community, per our Social Media Guidelines.
Working Groups are encouraged to host their videos on the Eclipse Foundation's YouTube account, rather than create their own. This will allow the Working Group to benefit from the reputation (20k subscriber) of the Eclipse Foundation channel, which improves SEO and visibility.
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.
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.
Working groups must engage in an annual audit of infrastructure. The audit includes a review of, for example, who has access to what resources.
A working group exits in the Opportunity phase when:
- Working Group Sponsor identified;
- Lead Organization identified;
- Initiation Agreement executed;
- Draft Working Group Charter complete;
- Participant Pipeline established; and
- Executive Director approval.
A working group is ready to move into the Proposal Phase when the following conditions have been met.
- Working Group name selected
- Working Group Sponsor identified
- Lead Organization identified
- Initiation Agreement executed by Lead Organization
- Internal Folder in the “Working Groups” Google Drive created
- Shared Drive created
- Lead organization representatives granted access
- Shared Documents created
- Participation Agreement created
- Pipeline document (spreadsheet) created
- Charter created
- Pitch Deck created
- Pipeline includes a minimum of five companies
- Executive Director approval
A working group exits in the Proposal phase when:
- Recruiting Materials created;
- Draft Marketing Plan completed;
- Services and required infrastructure identified;
- Initial Working Group Charter published;
- Minimum of three Participants committed; and
- 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.
A working group is ready to move into the Incubation Phase when the following conditions have been met.
- Tile added to the working groups landing page
- Charter posted to the website
- Interim committee chairs identified and appointed by Eclipse Foundation Executive Director
- Interim committee secretaries identified
- Working group announced to the Foundation's General Assembly (formerly the Foundation's Membership-At-Large)
- Primary “Working Group” (<shortname>-firstname.lastname@example.org) Mailing list created
- Infrastructure Plan (document) created
- Draft marketing plan created
- Recruitment materials created
- Name is selected
- Approved as a common law trademark by the Eclipse Trademarks Team
- Executed participation agreements from at least three different companies
- Executive Director approval
- Communication infrastructure established;
- Charter published;
- Working group committees (as defined by the charter) operational;
- (If applicable) Working Group Specification Process defined;
- Marketing plan and budget defined;
- Budget approved;
- Minimum of five participants committed; and
- Executive Director approval.
A working group that has made no progress towards moving to the operation phase for more than three months will be terminated.
A working group is ready to move into the Operational Phase when the following conditions have been met.
- Committee mailing lists created
- Zoom channel created
- Slack workspace created (<short-name>-wg.slack.com)
- Sponsor (or their designate) added as administrator
- Eclipse Webmaster added as administrator
- Lead organization representative added as administrator
- Charter complete; updated on website
- Name trademark (wordmark) registration initiated
- Logo finalized
- Approved as a common law trademark by the Eclipse Trademarks Team
- Added to working groups landing page title
- (optional) Trademark registration initiated
- Recruiting materials complete
- Budget defined and approved by the steering committee
- Marketing plan complete
- Infrastructure plan signed off by steering committee and Eclipse Foundation
- Committees established
- Initial representatives appointed
- Meetings scheduled
- Executed participation agreements from at least five different companies
- Executive Director approval
A working group that is in the Operational Phase is, well, operational. During this phase, the working group operations
- Website Launch/Press Release
- Implement Charter
- Open innovation
- Committee Meetings
- Specification Process (when applicable)
A working group that is no longer viable is terminated and archived.
The Eclipse Foundation Working Group Process does not formally define an Archived Phase, 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.
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.
What do we do with working group assets when a working group terminates?
- Public Termination Notice sent to working group communication channel
- Shared Drive and Internal Folder archived
- Contents from public Shared Drive moved into “Public” folder in Internal Folder
- (now empty) Shared Drive deleted
- Internal Folder moved to “Archived”
- Charter marked as “archived” on website
- Related Working Group Participation Agreements removed and archived
- Tile on the “Explore” page removed
- Bullet in the “Terminated Working Groups” added
- Website deactivated and archived, domains/URLs redirected to “Explore” page
- Zoom workspace retired
- Slack workspace deleted
- Participation Agreements expired in Foundation database
- Formal communication sent to affected members confirming termination and invalidation of related agreement.
Does every working group have a program manager?
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.
Does a working group need to be in the operational phase to engage in specification work?
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.
A working group must, however, be in the operational phase before its specification committee may approve and ratify a Final Specification for release.
Can a working group in the incubation phase release a specification?
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.
Can a working group combine committees?
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.