Skip to main content

Eclipse Foundation Project Handbook

Table of Contents

Current as of 2023-10-31.

Notices

Copyright © Eclipse Foundation, Inc. and others.

Made available under the Eclipse Public License v 2.0.

This document includes content originally authored on the Eclipsepedia wiki by Wayne Beaton, Fabian Steeg, Denis Roy, Dave Carver, Ed Merks, Bjorn Freeman-Benson, Anne Jacko, Ian Skerrett, Mike Milinkovich, and John Arthorne.

Overview

This document provides you with the information that you need to create a new Eclipse open source project or become a committer on an existing one.

While this document is focused on Eclipse, it makes several "Eclipse" references, including the Eclipse Foundation, Eclipse Foundation Development Process, and Eclipse Management Organisation. The Eclipse Foundation is the legal entity that manages the operations of the Eclipse working group, software development forge, and community.Many of the provided services and contacts are so-named on that basis.

The Eclipse Foundation Development Process (EDP) is the foundational document for Eclipse projects and committers. It describes the manner in which we do open source software. The EDP does not prescribe any particular development methodology; it is more concerned with the larger-scale aspects of open source project life cycle, including such things as reviews, processes for running votes and elections, bringing new committers onto a project, etc. This document elaborates on some key points of the EDP.

Principles

Four basic principles lie at the heart of the EDP:

  • Transparency;

  • Openness;

  • Meritocracy; and

  • Vendor-neutrality

We refer to the first three as the "open source rules of engagement".

To operate with transparency, a project’s discussions, minutes, deliberations, project plans, plans for new features, and other artifacts are open, public, and easily accessible.

Openness at Eclipse means quite a lot more than "open book" (which is really a synonym for transparent). The project is open to all; Eclipse provides the same opportunity to all. Everyone participates with the same rules; there are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.

Eclipse is a meritocracy. The more that somebody contributes, the more responsibility they will earn. A pattern of quality contribution to a project may lead to an invitation to join the project as a committer. Leadership roles in Eclipse are also merit-based and earned by peer acclaim. Merit must be demonstrated in publicly-accessible forums. Committers and project leads are added to a project via election.

Note

Employment status has no bearing at whether or not somebody can participate in an open source project at Eclipse. Employment does not guarantee committer status; committer status must be earned by everybody.

Vendor-neutrality is similar to openness in that it’s concerned with maintaining a level playing field. No vendor is permitted to dominate a project, and nobody can be excluded from participating in a project based on their employment status. While project resources will contain copyright statements that assert ownership of various assets by individual vendors, the project itself must remain vendor-neutral.

Quality and intellectual property cleanliness are also important principles.

Quality means extensible frameworks and exemplary tools developed in an open, inclusive, and predictable process involving the entire community. From the consumption perspective, Eclipse quality means good for users (exemplary tools are cool/compelling to use, indicative of what is possible) and ready for use by adopters. From the creation perspective, Eclipse quality means working with a transparent and open process, open and welcoming to participation from technical leaders, regardless of affiliation.

Intellectual property (IP) is any artifact that is made available from a Eclipse server (this includes source code management systems, the website, and the downloads server). Artifacts include (but are not limited to) such things as source code, images, XML and configuration files, documentation, and more. Strict rules govern the way that we manage IP and your responsibilities as a committer.

Code produced by an Eclipse project is used by organisations to build products. These adopters of Eclipse technology need to have some assurance that the IP they’re basing their products on is clean: the organisation or individuals who claim copyright of the code are the legitimate copyright holders, and the copyright holders legitimately agree to make the code available under the license(s) that the project works under. As a committer, you must be careful that you do not copy code and inadvertently claim it as your own.

Starting an Open Source Project at the Eclipse Foundation

Before getting started, it’s important to know what is required of an Eclipse project. The Eclipse Foundation will take ownership of many aspects of the project to ensure that the project and its assets are managed in an open and vendor-neutral manner. This takes the form, for example, of the Eclipse Foundation retaining ownership of the project’s trademarks on behalf of the community, and carefully managing who has write access on project resources such as source code repositories and distribution channels. Eclipse projects are obligated to use certain resources assigned to the project by the Eclipse Foundation and conform to logo and trademark guidelines. New project sponsors must engage in the process of transitioning an existing project with the intent to continue development of the project code and growth of the community and ecosystem around the project.

It’s also important to know what new projects don’t give up. The project team retains control of the project’s direction by virtue of regular contribution to the project. The contributors to the project retain ownership of their contributions (those contributions are used under license by the project). Project leads are required to ensure that other individuals who present themselves to the project are given uniform opportunity to participate, but the project team gets to establish the rules for participation (within certain parameters). The project team is responsible for determining development methodology, establishing plans, etc. Existing owners of the project code retain their ownership.

Project Proposal

Eclipse open source projects start with a proposal that is made available to the community for review. At the end of the community review period, we engage in a creation review, and then provision the project resources.

starting overview
An overview of the Project Creation Process

Use the web form to create a new project proposal. Instructions are provided on the form. All new proposals are created in draft mode, and are accessible only by the original author and anybody designated as a project lead or committer in the proposal. Only those individuals designated as a project lead may edit the proposal.

Note

Keep track of the URL of the proposal. The website does not provide public links to the document until after the proposal is opened for community review. If you do lose track of the URL, ask EMO for assistance.

A proposal must minimally include a description of the project, a declaration of scope, and a list of prospective members (project leads and committers) before we make it accessible to the public for community review.

When you feel that the proposal is ready, send a note to the Eclipse Management Organisation (EMO) requesting that the proposal be made available to the public for review. The EMO will review the proposal and may provide feedback before initiating the community review period.

At the beginning of the community review period, the EMO will announce the proposal on several channels (the Project Activity News page, Twitter, blog post, and an email note to the Eclipse Foundation members and committers). The EMO will also open a record in the Eclipse Foundation’s issue tracker — an instance of GitLab — to track the progress of the proposal; the proposal’s author, and project leads will be copied on that record.

A proposal will be open for community review for a minimum of two weeks.

The Eclipse Foundation holds the trademark for all Eclipse projects. Trademark assignment is undertaken prior to the creation of any new project. If you already have a trademark on your project name, that trademark must be assigned to the Eclipse Foundation. Be advised that trademark assignment can be a time-consuming process (it can take hours, days, or weeks depending on the circumstances surrounding the name). If you currently hold the trademark, you will be asked to complete a Trademark Transfer Agreement.

Creation Review

When the project name trademark has been secured and the proposal contents are finalised, the EMO will schedule a creation review. Reviews — which run for a minimum of one week — are scheduled twice a month, generally concluding on the first and third Wednesday of each month. The creation review may overlap with the community review period.

Note

Creation reviews tend to always be successful. They should be considered low stress as the hard work has already been done in advance of the start of the review.

Provisioning

Following a successful creation review, the EMO will initiate the provisioning process.

Provisioning starts with an email message being sent to each of the committers listed on the project proposal with instructions on how to engage in the committer paperwork process. The exact nature of that paperwork depends on several factors, including the employment status of the individual and the Eclipse Foundation membership status of their employer.

Note

The provisioning process will not start until after the committer agreement for at least one project committer is received and processed by the EMO Records Team. If you can be ready with the paperwork in time for the completion of the creation review, then we can move quickly through the provisioning process.

When we initiate provisioning, committers will be sent an email with instructions; please don’t send any paperwork in until after you receive those instructions.

When the paperwork is received and processed for one committer, the Eclipse IT Team will begin the resources provisioning process. When that process is complete, the IT Team will provide information regarding the nature and coordinates of the various resources and services available to the project.

After Provisioning

Before pushing any code into an official Eclipse project repository, the project team must submit the project’s initial contribution of project code and wait for the Eclipse Intellectual Property (IP) Team to grant checkin of that contribution.

third party content that is required by the project code must also be reviewed by the Eclipse IP Team.

post creation
Post creation activities

After the project code is pushed into the project repository, the project team can create and distribute milestone builds for the first release. However, all intellectual property must be approved by the Eclipse IP Team before the project team can issue any official releases.

Project Phases

Eclipse projects move through various phases. Projects in active phases (incubation or mature) engage in all the normal sorts of development activities: project committers write code, run builds, release software, court contribution, and seek to convert contributors into committers. All new projects start in the incubation phase. Projects tend to stay in the incubation phase for a few months (varies depending on the nature and composition of the project) and then move into the mature phase.

phases
An overview of the Project life cycle Phases

Key project life cycle events are gated by reviews; moving from the incubation phase to the mature phase must be, for example, preceded by a graduation review.

Incubation Phase

A project in the incubation phase is said to be incubating.

The classification of a project in the incubation phase is not a statement about the quality of the project’s code; rather, the incubation phase is more about the project team’s progress in practising the open and transparent processes described by the Eclipse Foundation Development Process to establish the three communities (developers, adopters, and users) around the project.

Incubating projects are encouraged to produce milestone builds, make releases, and grow their community.

When the project code is ready (e.g. stable APIs) and the project team has learned to operate as an open source project according to the Eclipse Foundation Development Process, the project may opt to graduate (via graduation review) into the mature phase.

Incubation branding
incubating

In order to alert potential consumers of the incubating nature, projects in the incubation phase must include incubation branding.

The project team must:

  • Display the incubation logo on their project web page (if they have one);

  • Display the incubation logo on their project’s primary download page;

  • Include the word "incubation" in the filename of all downloadable files (when technically feasible) for builds and milestones; and

  • When technically feasible, include the word "incubation" in features (e.g. about dialogs, feature lists, and installers).

There are no incubation branding requirements for general user interface elements.

Note

For projects that produce OSGi artifacts, include the word "incubation" in the Bundle-Name, feature names, and p2 repositories. The word "incubation" should not be included in technical namespaces (especially when it may result in confusion when the project leaves incubation). e.g. an OSGi bundle’s Bundle-SymbolicName, or a Java package name.

Mature Phase

Most of the lifetime of an Eclipse project is spent in the mature phase. A mature project is one that:

  • Is a good open source citizen with open, transparent, and meritocratic behaviour;

  • Regularly and predictably releases IP clean extensible frameworks and exemplary tools; and

  • Actively nurtures the three communities: developers, adopters, and users.

Archived

When a project has reached its logical conclusion, its resources are archived. Transition in the Archived (phase) is preceded by a termination review.

Frequently Asked Questions

  1. Do I have to create an entirely new project? Can I extend an existing project?

    If new functionality falls within the scope of an existing project, then it may make sense to instead create a component within the project. Components are an informal concept for Eclipse open source projects; the notion of a component generally manifests as a separate Git repository with access to that repository managed via social convention.

    All project committers have uniform write access to all project resources, which means that when a new component is added to a project everybody who already has push access to the Git repositories already in that project can also push to the new component’s Git repository.

    Different components within a project can be built separately, but they generally release on a shared schedule with shared release reviews (although there is some precedent for projects releasing different components separately).

    A component may be the right choice if the new functionality:

    • Is within the scope of the project;

    • Shares the same licensing of the project;

    • Can reasonably share the development schedule of the project; and/or

    • Will be delivered alongside other project functionality.

    You might instead choose to create a new project if the new functionality:

    • Does not reasonably fall within the scope of an existing project (and an existing scope cannot be reasonably changed to accommodate);

    • Absolutely must be delivered on a separate schedule;

    • Must be delivered independently (i.e. a completely separate downloads area is required);

    • Has different licensing requirements; and/or

    • Would benefit from separate branding.

  2. Why are some committer (but not all) names rendered as links on project proposal pages?

    When the list of committers provided for a new project proposal are rendered, a link to more information for each individual committer will be included when possible. The link will render, for example, when an individual already has a role on another existing Eclipse open source project (e.g. is a committer, project lead, Project Management Committee (PMC) member, etc.). No link indicates that no existing project relationships exist for that individual.

  3. What license(s) can I use for my project?

    Eclipse top level projects define the standard licensing for their projects. When a project has nonstandard licensing requirements, they may need to make an appeal to the Eclipse board of directors to request their approval. Connect with EMO for assistance.

  4. Can I change the proposal after it is posted?

    Yes. The proposal can be changed any time before the start of the creation review.

  5. When do I submit my code for review by the IP team?

    Submit your code (initial contribution) for review after the project has been provisioned. The EMO will let you know when provisioning is complete.

  6. Does the new project have to use Git?

    Yes. Git is the only source code management system that is currently permitted for new projects.

  7. Can I host my project code on GitHub?

    Eclipse projects can make use of GitHub. Official project repositories must be hosted under an Eclipse Foundation-managed organisation at GitHub. Official repositories are subject to the same intellectual property due diligence rules and processes that all Eclipse project repositories must follow.

  8. How long should I let my project incubate?

    It depends. Community expectations are one factor. Team experience with open source is another. If your team is new to open source, it may make sense to stay in incubation a little longer than a seasoned team with a mature code base might. As a general rule, though, projects should plan to leave incubation within a year.

  9. Does the mature project code that I’m bring to Eclipse need to incubate?

    Yes. All new projects start in the incubation phase. Remember that incubation is as much about the project team learning about how to operate as an open source project as it is about the project code. Project teams that "get it" can opt to exit incubation quickly (e.g. with their first release) if that makes sense for the team and the community.

  10. What do all these terms (e.g. EMO) mean?

    Please see the glossary.

Project Roles

The Eclipse Foundation Development Process defines multiple formal open source project roles. Primary among the roles are those of Committer, Project Lead, and Project Management Committee.

Committers

For Eclipse projects (and the open source world in general), committers are the ones who hold the keys. Committers are either appointed at the time of project creation, or elected by the existing project team.

Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the Eclipse Foundation Development Process, puts meritocracy on equal footing with transparency and openness: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit.

Committers:

  • Operate in an open, transparent, and meritocratic manner;

  • Write code (and other project content) and push it directly into the project’s source code repository;

  • Review contributions (merge and pull requests) from contributors;

  • Engage in the Intellectual Property Due Diligence Process;

  • Vote in committer and project lead elections;

  • Engage in the project planning process; and

  • Otherwise represent the interests of the open source project.

Project Lead

Eclipse projects must have at least one project lead, and may have more than one. The project leads are the primary liaison between the project team and the Eclipse Management Organisation(EMO). As the first link in the project leadership chain, project leads have responsibility to ensure that the project team is able to successfully implement the goals of the project in accordance with the Eclipse Foundation Development Process and Eclipse Foundation Intellectual Property Policy.

The EMO considers it a good practice to have more than one person in that role to ensure that there is continuity. There is no artificial maximum number of project leads for an Eclipse project: the main thing that the EMO is concerned with is that project leads are elected in a vendor neutral manner following public demonstrations of leadership (documented as comments on issues, contributions to mailing list discussions, etc.) that are cited in the nomination statement. The EMO specifically watches elections to ensure that vendor neutrality is observed.

Project leads are either appointed at the time of project creation or elected by their committer peers (an individual is generally expected to have served as a committer before being nominated for the project lead role). Project leads must also be committers, but the two roles are distinct.

Project leads are responsible for ensuring that project committers are following the rules. At the most basic level, the rules are the open source rules of engagement defined in the Eclipse Foundation Development Process (openness, transparency, and meritocracy), and we depend on them to make sure that team members understand their obligations under the IP Policy and are correctly implementing the Intellectual Property Due Diligence Process.

Tip

Project leads should seek help/advice from the Project Management Committee and Eclipse Management Organisation when they need assistance.

Project leads have the ability to retire committers: this is a power that must be used responsibly. A project lead needs to be able to support their decision to retire a committer. As a best practice, the project lead should give committers reasonable opportunity to retrain their status, and — should the decision be made to retire — committer retirements should be announced on the project’s primary communication channels including the dev-list.

When committers are disruptive or otherwise behaving in a manner that is detrimental to the project, the project lead should work with the PMC and the EMO to resolve the issue.

Tip

The six months of inactivity is more of a suggested period of time for considering retirement of committers; we defer to the judgement of the project lead to determine when and if somebody who is inactive should be retired.

Project leads have some extra privileges on GitLab and GitHub.

The project lead is not the technical lead. So it’s not strictly their responsibility to develop things like coding standards, project policies, and such. They are responsible, however, for making sure that those sorts of things get created and for making sure that the project team is working to complete shared goals.

Note

A project lead is not necessary a technical lead. We have no formal designation of technical lead; this tends to occur organically.

Any committer can initiate a review with the EMO, but the EMO will always copy the project lead(s) in related communication to ensure that they are aware that the committer is acting as their delegate.

Project leads can also request the EMO to initiate a restructuring review in case a project needs to change the meaning of the scope or make any other significant changes to one or more Projects.

Project Management Committee

A project management committee (PMC) is responsible for the operation of exactly one top-level project as defined by the Eclipse Foundation Development Process. Per the EDP, top-level projects sit at the top of the open source project hierarchy.

The PMC’s role is, fundamentally, to maintain the overall vision and operation of the top level project and all of the projects that fall within their purview. Very often (though it really depends on the nature of the top level project), the PMC will take a very active role in determining how their projects fit together, and how they communicate and interoperate. In pragmatic terms, the PMC ensures that projects are following the rules, set the standards over and above the basic requirements for releases and corresponding documentation, approves intellectual property contributions, and approves committer and project lead elections.

Top-level projects do not generally maintain open source content 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 and operating within the terms outlined by the top-level project’s charter. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner.

The PMC is responsible for defining and managing the structure of the top level project and the organisation of the open source (software and specification) projects contained within.

The PMC provides other oversight regarding the operation of open source projects. They review and approve progress reviews, and facilitate cross-project communication within the top level project.

Composition

A PMC has one or more PMC leads and zero or more PMC Members.

The PMC Lead is appointed by the Eclipse Foundation’s Board of Directors. When an existing PMC Lead retires, the EMO will work with the PMC to identify a replacement and then with the EMO(ED) to have that individual ratified by the board of directors.

PMC Members are appointed by the EMO(ED). The criteria by which PMC members are identified varies by PMC, but is generally by nomination and election within the existing PMC. Some PMCs are designed to be composed of representatives from some subset of the projects that operate under their purview. In such a case, the means of identifying members should be documented in the corresponding top-level project charter.

In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by the unanimous vote of the remaining PMC members, subject to approval by the EMO. Removal of a PMC Lead requires approval of the Board.

PMC Role in the Intellectual Property Due Diligence Process

The Eclipse IP Team has limited technical knowledge and so relies on the PMC to use their relationship with the open source projects operating under their purview, their knowledge and experience with the community and related technology to provide technical insight. Specifically, the IP Team depends on the PMC to use their knowledge and experience with their community and technology to flag any potential issues that may not be obvious.

The PMC might, for example, know that the license for some content had been, at some point in the past, changed; or that some particular piece of content links in some non-obvious manner to other intellectual property that should also be vetted.

Tip

The PMC should not perform any detailed intellectual property analysis of content. The IP Team will engage in detailed analysis, identify license compatibility issues, and determine whether or not license headers have been appropriately applied, for example.

The IP Team will connect with the PMC when their assistance is required.

PMC Role in Elections

The PMC reviews and approves (or vetoes) committer and project lead elections. The role of the PMC is validate that the election was run according to the open source rules of engagement and election process described in the Eclipse Foundation Development Process, and consistent with the Top-Level Project Charter.

In practical terms, the EMO depends on the PMC to validate that elections provide (either via the nomination statement, or by statements made by committers during the voting period) a transparent record of relevant contribution by the nominee and maintain vendor/employer neutrality.

From the EMO’s perspective, any single PMC member can review the election and — if they feel that the election was correctly run — approve it. Any single member can do this on behalf of the PMC. PMCs tend to do this opportunistically: the first PMC member who receives notice of the completed election does a quick review and approves (or not). In the general case, a PMC member will independently review and approve an election; in specific individual cases, the PMC member may decide that further investigation is required and engage with the rest of the PMC for guidance.

Note

The PMC may, at its discretion, add requirements for elections involving projects that operate under its purview. The PMC must capture additional requirements (ideally in the Top-Level Project Charter or in a companion document) and apply them consistently.

The PMC list is notified when elections require the PMC’s attention. Alternatively, PMC members can review elections that require their attention on the Notifications page.

Tip

Click the drop-down next to "Welcome, <name>" to access the Notifications page.

notifications

PMC Role in Reviews

As part of the project leadership chain, the PMC is tasked with approving progress, release, and graduation reviews.

The criteria by which the PMC determines whether or not to approve a review, and the process that they follow to grant approval varies by PMC. In general, with this request for approval, the EMO seeks the advice of the PMC regarding whether or not projects under its purview are operating according to the open source rules of engagement. That is, the EMO expects that the PMC has some insight into the operation of the projects operating under their purview, and know whether or not project teams have what they need to be successful.

A project lead or committer must request PMC approval via email to the PMC’s mailing list. Any member of the PMC may approve the review by responding directly to the request with a +1 (that is, the EMO will interpret any single PMC member’s +1 as the PMC’s affirmative response).

Note

The EMO monitors all PMC mailing lists and so will likely observe the PMC’s approval response. The EMO will acknowledge the approval via the issue being used to track the review.

Since any single member of the PMC may approve a review on behalf of the entire PMC, the EMO purposely delays recording the approval in order to give other PMC members an opportunity to challenge their colleague.

PMC Role in Grievance Handling

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 is an important link in the project leadership chain, which is composed of the project’s project lead(s), the leadership of the parent project (if any), the PMC leads and PMC members, the EMO, and the Executive Director of the Eclipse Foundation. In exceptional situations—such as projects with zero active committers, disruptive committers, or no effective project leads—the project leadership chain has the authority to make changes (add, remove) to the set of committers and/or project leads of that project, and otherwise act on behalf of the project lead.

PMC Representation

Every PMC is entitled to appoint one representative to the Eclipse Architecture Council.

Eclipse Architecture Council

The Eclipse Architecture Council serves the community by identifying and tackling any issues that hinder Eclipse’s continued technological success and innovation, widespread adoption, and future growth. This involves technical architecture as well as open source processes and social aspects. Comprising the finest technical leaders from all community stake holders, it is the council’s goal to keep the projects successful and healthy, the processes simple and smooth, and the communities vibrant and cohesive.

More concretely, the Eclipse Architecture Council serves four basic purposes:

Every PMC may appoint a representative to the Architecture Council to represent the interests of the PMC and corresponding Top-level Project. Every Strategic Member of the Eclipse Foundation may also appoint a representative. Other Architecture Council Members are nominated and voted on by the Architecture Council itself, and appointed by the council by the Eclipse Foundation’s Executive Director. Appointed members serve a two year renewable term.

Tip

In practice, the two year renewable term for appointed members of the Architecture Council are automatically renewed with no formal ceremony.

The Architecture Council interacts primarily via their mailing list. List participation is limited only to Architecture Council members and subscription to the list is automatic. Additionally, the Architecture Council meets (remotely) every month for a one-hour closed discussion (with public minutes).

Committers and Project Leads should connect with the Architecture Council via their PMC.

Eclipse Management Organisation (EMO)

The Eclipse Management Organisation (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council. The EMO is responsible for providing services to the projects, facilitating project reviews, resolving issues, and more. The EMO is the maintainer of the Eclipse Foundation Development Process. The best method of contact with the EMO is by email (emo@eclipse-foundation.org). If you have a question that cannot be answered by project lead, or PMC, ask the EMO.

Frequently Asked Questions

  1. Is the Project Lead a super-committer?

    A project lead is not a super committer. In fact, the project lead role does not automatically grant the individual committer privileges. The roles are different and an individual must be elected into both of them separately (though it is common that an individual is elected into the project lead role after demonstrating merit while working in the committer role).

Committer Badges

The Committer Badge

The role of a committer is one of great responsibility within open source communities. Committers are individuals who have demonstrated their expertise, commitment, and contribution to a project or community and have earned the trust of the existing committers or project maintainers.

Committers have write access to the source code repositories. They have the authority to directly contribute changes to the codebase and have their contributions integrated into the project. This role often involves reviewing and merging code submissions from other contributors, ensuring that the code meets the project’s standards and maintaining the stability and quality of the codebase.

Being a committer requires technical skills, knowledge of the project’s codebase and development practices, and a strong understanding of the project’s goals and objectives. Committers are responsible for making important decisions related to the project’s direction, resolving conflicts, and ensuring that the project evolves according to its roadmap.

The role of a committer comes with a set of obligations and responsibilities, such as actively participating in discussions, providing guidance and support to other contributors, and upholding the project’s values and standards. Committers play a crucial role in shaping the project, maintaining its integrity, and fostering a collaborative and inclusive community.

Becoming an Eclipse committer is a significant accomplishment, reflecting the continuous dedication, contribution, and earned trust of the community.

The Eclipse Foundation awards this badge to certify developers who have attained committer status within the Eclipse Foundation’s Community.

Who is Entitled to Receive the Badge?

Everybody who has committer status on one or more Eclipse Projects is eligible to receive the badge.

How Do I Get the Badge?

Roll out starts after EclipseCon 2023 (November 2023). From that point forward, we will offer the badge to all new committers when we have their fully executed committer agreement.

Tip

If you work for a member company, then we most likely already have a Member Committer and Contributor Agreement on file for you; we might otherwise require that you complete an Individual Committer Agreement. The EMO Records Team will help you sort this out.

Roll out to existing committers will occur in stages with anticipated completion in early 2024.

Former committers can request the badge by sending a note to EMO Records Team.

Frequently Asked Questions

  1. Do I have to accept the Committer badge?

    No.

  2. Do I have to be an Eclipse Committer to receive the badge?

    Yes.

  3. How do I become an Eclipse Committer?

    The most common way for somebody to join an Eclipse Foundation open source project as a committer is to be elected to an active project. All Eclipse open source projects operate in an open, transparent, and meritocratic manner, so the path to becoming a committer starts with participation: clone the repository, make some changes, and contribute those changes as a merge/pull request. Then do it again.

    After you have demonstrated, through a pattern of high quality contributions, that you understand how the open source project works, and that you understand the Eclipse Foundation Development Process and are prepared to implement the Eclipse IP Policy, an existing committer will invite you to join the team and initiate an election. Committer elections start with a nomination by an existing committer that includes a statement of merit that usually takes the form of a list of the various contributions that the individual has made to the project.

    What constitutes a sufficient demonstration of merit varies by project team.

    For more information, please see Committers.

  4. Do I have to make a specific number of contributions to receive the badge?

    No. The role of Eclipse committer is awarded to individuals who have already demonstrated to the project team and community that they understand the responsibilities inherent in the role. If the contributions that you’ve made are sufficient enough for the project team to elect you into the role, then you’re eligible to receive the badge.

  5. How do I request the Committer badge?

    Current and former committers can send a note to EMO Records Team to request the badge.

  6. I’m a committer on multiple Eclipse open source projects, do I get multiple badges?

    No. You get one. Don’t be greedy.

  7. I was an Eclipse committer in the past, but no longer have committer status; am I entitled to the badge?

    Yes. Send a note to EMO Records Team to request the badge.

  8. What can I do with the badge?

    You can add the badge to your professional profiles, such as LinkedIn, to highlight your expertise and stand out to potential employers or clients. By sharing your badge on social media platforms, you can increase your visibility and attract the attention of potential employers, colleagues, or collaborators. It serves as a powerful endorsement of your skills and can lead to networking opportunities.

    Show it to your mom.

  9. What is Credly?

    Credly is a digital credentialing platform that allows individuals and organisations to create, issue, and manage digital badges.

  10. Do I need an account with Credly to accept the badge?

    Yes. You have the option to create an account or you can sign into Credly using your existing Google or Apple account.

    Note

    You will have to agree to Credly’s privacy policy and terms of use in order to access the badge.

Project Resources and Services

Open source projects at the Eclipse Foundation are required to make use of certain Eclipse Foundation services:

The Eclipse Foundation provides the following services (high level) for Eclipse open source projects:

Identifiers

Project resources make use of two sorts of IDs:

Short name

The short name is used in various parts of Eclipse Foundation infrastructure (e.g. the name of the project’s directory on the downloads and Git servers, and the URL for the project website). The short name may contain lowercase alphanumeric characters, dashes, and underlines; but does not contain periods.

Qualified identifier

The project’s short name is joined with the short name of the parent project(s) to form a qualified identifier (project id) for the project that is used as a key on services generated and/or maintained for the project by the Eclipse Foundation.

For example the "Eclipse Woolsey" project has a short name of "woolsey"; its qualified identifier is "technology.dash.woolsey", indicating that it is a subproject of the an Eclipse Dash Project which is itself a subproject of the Eclipse Technology Top Level Project.

Source Code Management

Tip

We tend to incorrectly refer to all project content as source code. As a general rule, when we refer to source code, we mean all content (including documentation, configuration, image files, etc.) that is maintained in a source code repository (e.g., Git).

Eclipse projects must maintain project content (source code, documentation, configuration, etc.) in the repositories assigned to the project by the Eclipse Foundation. These official repositories must be the exclusive source of all content delivered via the project’s distribution channels (e.g. the download server).

Note

In order for the project to operate in an open manner, it must be possible for potential contributors to have access to the code base in its most current form, so all ongoing development must be regularly pushed to these canonical repositories.

Git Commit Records

Git commit records are required to take a specific form. The credentials of the actual author must be used to populate the Author field. The author credentials must specify the author’s actual (legal) name and email address. The email address used must match the email address that the Eclipse Foundation has on file for the author (case-sensitive).

The commit message is divided into three sections:

  1. One line (max 72 characters) summary;

  2. Description; and

  3. Footer.

Example Git Commit Record
commit d6cf52411377a039fc2906378711091a26e932cb
Author: Some Body <somebody@somewhere.com> 1
Date:   Wed May 29 16:17:36 2013 +0200

    Bug 350686 - Hide unwanted action bar items 2

    This change hides unwanted 'Link with Editor' and
    'Customize View...' items from the local toolbar
    and the view menu.

    Change-Id: Ia2bd5091303d1b0a738157effc24e4dac5a7d0c7 3
    Also-by: Some Bodyelse <somebodyelse@nowhere.com> 4
1 The email address of the author must match the email address on the Eclipse Foundation Account, the name "Some Body" must be replaced by the real name of the person.
2 Best practice: include the bug id in the commit message summary.
3 Gerrit Change-Id (only when pushing to Gerrit for review).
4 Additional authors can be added using Also-by or Co-authored-by entries, by replacing the name "Some Bodyelse" by the real name of the person (use one entry per person).
Important

The name used in the Author field (and, when required, in the Also-by/Co-authored-by entries) must be the legal name of the contributor; the email address must be valid and real.

The summary line is used in many places where Git commits are listed, ensure that this line is sensible by itself. The description area should be used to provide more detail about the commit. The footer area is used for extra fields and values.

If the bug id is included in the summary line (using the form "Bug 12345 - xxx" or "[12345] xxx") Gerrit Code Review will automatically add a link in the corresponding Bugzilla record back to the Gerrit record (this, of course, only applies to commits pushed to Gerrit).

The Change-Id is used by Gerrit Code Review to associate new versions of a change back to its original review. This field need only be specified if the repository is managed by Gerrit.

An Also-by (or Co-authored-by) entry can be added for each additional author of a commit (one committer per entry). This might apply, for example, if a commit has been authored via pair-programming, or the commit is the result of collapsing multiple commits authored by multiple developers. To be considered valid the entry must take the form Also-by: Name <email>.

Authors who are not committers on the project receiving the commit must have an Eclipse Foundation Account and must have a signed Eclipse Contributor Agreement (ECA) on file.

GitLab

The Eclipse Foundation maintains an instance of GitLab for use by Eclipse open source projects. Project teams may opt to host some or all of their canonical source code repositories on our GitLab instance.

Tip

Some of the terms used by GitLab — project in particular — have different meanings from those in the Eclipse Foundation Development Process (EDP). In order to make our meaning as clear as possible, we refer to GitLab projects as repositories and to Eclipse projects as Eclipse open source projects or (in the case where we mean a top-level project) Eclipse top-level projects.

Tip

Any committer can create a Help Desk issue to request that the Eclipse IT Team create a new repository on, or move an existing repository to, the GitLab instance for their project. Note that the IT Team will verify the request with the project leads.

On GitLab, the root group for all Eclipse open source project repositories is eclipse. Under that root, two nesting options are available: an Eclipse open source project’s group can be nested directly under the root, or can be nested in a group corresponding to the Eclipse top-level project. In both nesting options, repositories may be arbitrarily nested in subgroups created under the projects' group to organise the repositories. The custom subgroups are cosmetic only, as the same permissions are applied to the nested groups and do not provide any extra functionality.

Project Group

A group can be configured as the immediate descendant of the root group, using the Eclipse open source project’s short name.

Project short name as the root
eclipse
 ├── <short name A>
 │   ├── <repository 1>
 │   ├── <repository 2>
 │   └── ...
 ├── <short name B>
 │   ├── <repository 1>
 │   ├── <repository 2>
 │   ├── <custom group 1>
 │   │   ├── <repository 3>
 │   └── ...
 └── ...

For example, the Eclipse Dash project (short name: dash) has a group of eclipse/dash that might have repositories with the following URLs (note that these URLs are provided as examples and may not actually be real):

  • https://gitlab.eclipse.org/eclipse/dash/handbook

  • https://gitlab.eclipse.org/eclipse/dash/license-tool

Top-level Project Group

A group can be configured as a descendant of the Eclipse open source project’s corresponding Eclipse top-level project’s group, which itself is an immediate descendant of the root group, using the short names. Configuring the Eclipse open source project’s GitLab group in this manner enables aggregation features such as the ability to list and search issues across related Eclipse open source project groups and repositories.

Tip

Configuring GitLab in this manner requires approval from the corresponding Eclipse top-level project’s Project Management Committee (PMC).

Top-level project short name as the root
eclipse
 ├── <top-level project short name>
 |   ├── <short name A>
 |   │   ├── <repository 1>
 |   │   ├── <repository 2>
 |   │   └── ...
 |   ├── <short name B>
 |   │   ├── <repository 1>
 |   │   ├── <repository 2>
 │   │   ├── <custom group 1>
 │   │   │   ├── <repository 3>
 |   │   └── ...
 │   └── ...
 └── ...

For example, the Eclipse Dash project which is an Eclipse Technology (short name: technology) subproject could have a group of eclipse/technology/dash that might have repositories with the following URLs (note that these URLs are provided as examples and may not actually be real):

  • https://gitlab.eclipse.org/eclipse/technology/dash/handbook

  • https://gitlab.eclipse.org/eclipse/technology/dash/license-tool

Access to GitLab Repositories

Project leads, committers, and contributors for each project are granted access to their project group according to their role within the project.

Tip

For information regarding the privileges available to each of the Maintainer, Developer, and Reporter roles indicated below, consult the GitLab Documentation.

Project Leads

All project leads are automatically granted the Maintainer role on their project resources hosted on GitLab. When an individual is elected into the role of project lead, they are automatically granted these permissions within the group. When a project lead is retired, they are automatically removed from the group.

Warning

With the Maintainer role, project leads have significant privileges on GitLab repositories. Project leads must not manipulate the configuration of GitLab groups and repositories in a manner that would violate the Eclipse Foundation Development Process or the Eclipse Foundation Intellectual Property Policy.

For example, project leads must not manipulate privileges and must specifically not add or remove developers directly. See Committer Elections for information on how to add developers to a project, and Committers Retirement for information on how to remove developers from a project.

Committers

All committers are automatically granted the Developer role on their Eclipse open source project resources hosted on GitLab. When an individual is elected into the role of committer, they are automatically added to the as a Developer to the Eclipse open source project’s group. When a project lead is retired, they are automatically removed from the group.

Contributors

All contributors are automatically granted Reporter level access to Eclipse open source project resources hosted on GitLab. When an individual is added to the contributors list, they are automatically added as a Reporter in the Eclipse open source project’s group. When they are removed from the contributors list, they are automatically removed from the group.

The Eclipse Contributor Agreement (ECA) hook inspects incoming merge requests to ensure that the contributor has a valid ECA on file, and flags those that do not. Eclipse open source project committers should only accept merge requests that pass this validation.

Bot Users

To assist with CI/CD operations, bots with CI/CD access can be requested by making a request within the help desk by either a project lead, or a committer with approval from a project lead. These bots may be added directly to repositories or to groups depending on the requirements.

Excluded Subgroups

Excluded Subgroups have been added to Project Management Infrastructure (PMI) project page to better support cases where third-party non-project code needs to exist within a project group for stability, such as forks and mirrors. Once configured, these subgroups within the project groups to exclude from automated tooling such as the ECA checks. The excluded subgroups follow the standard access permissions and Project Leads can request updates to this field through the help desk.

GitHub

Project teams may opt to host some or all of their canonical source code repositories to an organization on GitHub that is maintained by the Eclipse Foundation. Both GitHub Issues and Wiki may also be used.

Any committer can open a Help Desk issue to request that the Eclipse IT Team create a new repository for their project on, or move an existing repository to, GitHub. A project may have more than one repository on GitHub. When making the request, the committer should describe—​specifically and concisely—​what they want to make happen. Note that the IT Team will verify the request with the project leads.

Repositories can be hosted in the default eclipse GitHub organization, or a dedicated organization can be created. Dedicated organizations use as their name, the conjunction of eclipse with the project short name (e.g., eclipse-woolsey).

The Eclipse IT Team installs some hooks onto all Eclipse project repositories on GitHub.

The Committers hook grants designated project committers write access to the GitHub-hosted project repositories. Project committers must add their GitHub id to their Eclipse Foundation account, and must use the email address they provide to the Eclipse Foundation as the email address in the author credentials of all commits.

The Eclipse Contributor Agreement (ECA) hook will inspect incoming GitHub pull requests to ensure that the contributor has a valid ECA on file. Project committers should only merge green pull requests:

Github cla success
Notification that the commit is properly structured and permissions are in place.

Since the GitHub API does not provide a way for a Committers hook to absolutely deny a merge by itself, the hook warns committers when the contributors have not signed an ECA.

Github cla failure
Notification that there is something wrong with the commit.

Click on the Details link for more information. Committers must not merge commits unless they are certain that the contributor does have a valid ECA on file.

It is however possible to set up a Branch Protection Rule for branches to prevent that pull requests which fail the ECA validation are getting merged into them:

Github branch protection rule
Setup of a Branch Protection Rule with require ECA validation status checks.

Access to GitHub Repositories

Eclipse Foundation scripts build and maintain a collection of GitHub Teams, each with permissions appropriate to the corresponding Eclipse project roles (project lead, committer, and contributor).

Tip

The scripts require knowledge of the GitHub Id in order to add any individual to any of the teams. Be sure to include your GitHub Id in your Eclipse Foundation Account.

GitHub’s Repository roles for an organization document describes the permissions granted for each of the roles (Maintain, Write, and Triage) described below.

Project Leads Team

All project leads are automatically added to the project leads team. All members of the project leads team are granted the Maintain role on their project’s GitHub repositories. When an individual is elected into the role of project lead, they are automatically added to the project leads team. When a project lead is retired, they are automatically removed from the team.

A project lead may request temporary Admin level access to their project’s repositories by creating a Help Desk issue with their request. The issue must describe what will be done using this new level of access and how long it will be needed.

Warning

With the Maintain role, project leads have significant privileges on GitHub repositories. Project leads must not manipulate the configuration of GitHub organizations and repositories in a manner that would violate the Eclipse Foundation Development Process or the Eclipse Foundation Intellectual Property Policy.

For example, project leads must not manipulate teams or privileges and must specifically not add or remove developers directly. See Committer Elections for information on how to add developers to a project, and Committers Retirement for information on how to remove developers from a project.

Project leads must provide their GitHub Id in their Eclipse Foundation Account.

Committers Team

All committers are automatically added to the committers team. All members of the committers team are granted the Write role on their project resources hosted on GitHub. When an individual is elected into the role of committer, they are automatically added to the committers team. When a project lead is retired, they are automatically removed from the team.

Committers must provide their GitHub Id in their Eclipse Foundation Account.

Contributors Team

All contributors are automatically added to the contributors team. All members of the contributors team are granted Triage level access to project resources hosted on GitHub. When an individual is added to the project’s Contributors list, they are automatically added to the contributors team. When they are removed from the Contributors list, they are automatically removed from the team.

Contributors must provide their GitHub Id in their Eclipse Foundation Account.

The Eclipse Contributor Agreement (ECA) hook inspects incoming pull requests to ensure that the contributor has a valid ECA on file, and flags those that do not. Project committers should only merge pull requests that pass this validation.

Self-Service of GitHub Resources

The Eclipse Foundation offers self-service of GitHub resources via a tool named Otterdog.

Upon opting-in, a new repository .eclipsefdn will be created that hosts the GitHub configuration as code.

Example Otterdog configuration
orgs.newOrg('adoptium') {
    settings+: {
      blog: "https://adoptium.net",
      default_repository_permission: "none",
      default_workflow_permissions: "write",
      description: "The Adoptium Working Group promotes and supports high-quality runtimes and associated technology for use across the Java ecosystem",
      members_can_change_project_visibility: true,
      members_can_change_repo_visibility: true,
      members_can_delete_repositories: true,
      name: "Eclipse Adoptium",
      readers_can_create_discussions: true,
      security_managers+: [
        "adoptium-project-leads",
      ],
      twitter_username: "adoptium",
      web_commit_signoff_required: false,
    },
   ...
}

The following resource configurations are available:

  • Organization Settings

  • Organization Webhooks

  • Repositories and their settings

  • Branch Protection Rules

Committers can create pull requests for this repository with suggested changes. A workflow will automatically run, validate and highlight the changes:

Github self service pull request comment
Validation of suggested configuration changes.

The pull request needs to be approved by an Eclipse Foundation staff member and once its merged, the changes will get applied to GitHub.

The baseline configuration used by the Eclipse Foundation can be accessed here.

Gerrit Code Review

Gerrit provides web based code review and repository management for the Git version control system. Many projects use Gerrit to reduce barriers and encourage contribution to the project. As Gerrit is deprecated, we encourage projects to use GitLab or GitHub for code hosting.

Issue Trackers

Eclipse projects must use an Eclipse Foundation-provided issue tracker. Project teams may opt to use either the Eclipse Foundation GitLab instance or — for projects that use GitHub — GitHub Issues instances associated with Eclipse Foundation-managed GitHub project repositories.

Mailing Lists

Eclipse projects have one or more mailing lists.

Mailing lists take the following form: <shortname>-<extension>@eclipse.org, where <shortname> is the project’s short name and <extension> signifies the nature of the list (e.g., woolsey-users@eclipse.org or woolsey-ci@eclipse.org).

Tip

To create additional mailing lists for a project, a project leads should make the request by opening a Help Desk request.

With the exception of channels created to discuss security issues while they are in quarantine, there are no private channels for project work. This means that we do not provide private mailing lists for any project activity and that all mailing lists use for project activity are configured to have a public archive.

Mailing list subscriptions are managed via your Eclipse Foundation Account.

Project Dev Lists

All projects are assigned a development list or dev-list that takes the form <shortname>-dev@eclipse.org (e.g., woolsey-dev@eclipse.org).

All project committers must subscribe to the list. The dev-list should be the primary means of communication between project committers and is the means through which the EMO and the Eclipse Foundation’s automated systems communicate with the project team.

PMC Lists

Every Project Management Committee (PMC) is assigned a PMC list that takes the form <shortname>-pmc@eclipse.org where <shortname> is the short name of the corresponding top-level project (e.g., technology-pmc@eclipse.org).

All PMC members must subscribe to this list. Project leads and committers from open source projects operating under the purview of the PMC may also subscribe to the list to monitor the activities of the PMC and interact as necessary (it’s common that project teams will designate one or more representatives to the PMC who will subscribe to the PMC list).

The PMC list should be the primary means of communication between PMC members and is the means through which the EMO and the Eclipse Foundation’s automated systems communicate with the PMC.

Committers Mailing List

All committers are automatically subscribed to the eclipse.org-committers@eclipse.org mailing list. This list is used primarily as a means for the EMO and the Eclipse Foundation IT Team to communicate important information to all committers. We use this list sparingly.

Tip

Subscription to the committers mailing list is an obligation that comes with having committer status on an Eclipse open source project. The only way to remove yourself from this list is to retire yourself as a committer.

Forums and Outbound Communication

All projects are assigned a user forum as a point of contact between the user and adopter communities, and the project developers.

The EMO strongly encourages the use of alternative communication channels for connecting with the community: project teams know their community and how to best connect with them.

Project Websites

Project websites are an excellent way to connect an open source project with the community. Many projects opt to use the Project Management Infrastructure (PMI) project page as their website. PMI-based website URLs take the form of https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo).

Many project teams opt to create a custom main project website: if so-desired, a project may host a website on Eclipse Foundation-hosted servers. Project website URLs generally take the form https://www.eclipse.org/<shortname> (e.g. https://www.eclipse.org/foo). Custom project website content is maintained in Git repositories hosted on Eclipse Foundation infrastructure. A background job moves content from the Git repository to the website; content pushed to the repository will appear on the live website within five minutes.

Note

If a project website has not already been created for your project, open a Help Desk issue to request that the Eclipse IT Team create one.

Project websites must implement the branding guidelines for project websites.

The Project Management Infrastructure (PMI) provides the main project website. Website URLs take the form of https://projects.eclipse.org/projects/<projectid> (e.g. https://projects.eclipse.org/projects/technology.foo).

Websites not hosted by the Eclipse Foundation are considered community portals and are subject to the Eclipse Foundation Trademark Usage Guidelines (the Eclipse Foundation asserts ownership of all project name trademarks). Furthermore, projects may be required to comply to specific security guidelines and requirements outlined by the Eclipse Foundation’s Security team.

Analytics and Data Collection

If your project website or any other property maintained by or on behalf the project team uses Google Analytics or otherwise collects information, there may be privacy and data protection concerns that you’ll need to address. The Data Protection Impact Assessment Guidelines and Eclipse Foundation Hosted Services Privacy and Acceptable Usage Policy describe the Eclipse Foundation’s policy and your obligations.

Vendor-Specific Links

Organizations who are investing in an open source project may want to provide links on the project website (or in other content related to a project: a README file, for example) to related professional services that they offer.

Including links to vendor-specific services related to an Eclipse open source project is completely consistent with the Eclipse Foundation Development Process.

Vendor-neutrality must be observed. Care needs to be taken to make sure that there is no confusion that the project itself is an Eclipse open source project, and not a Vendor X open source project. In that context, including references and links to vendors who provide services for an open source project is fine, so long as others can participate via the same set of rules.

Note

It is inappropriate to provide vendor-specific references and links for services in technical documentation.

The rules for inclusion of vendor-specific references need to be captured (even if only informally). A project team might, for example, decide that links to related vendor services are permitted only in cases where the vendor has an active committer on the project.

Vendor-specific links should be a statement of fact without qualification or anything that looks like an advertisement or endorsement (that is, "Vendor X provides services related to this project" is acceptable, but "Vendor X is the preferred services provider for this project" is not). It must be very obvious to users browsing the project content that the links to vendor-specific services lead to content that is separate from the open source project (for example, links to vendor-specific content on a project website must lead to web pages with a distinctive appearance to avoid misleading the user into thinking that the services provider page is part of the open source project’s website).

Links to vendor-specific services must be directly related to the project.

Builds

Use of Eclipse Foundation-provided and hosted build services, the so-called Common Build Infrastructure (CBI) is strongly recommended, but not strictly required.

Whether or not a project chooses to make use of provided build resources, it must be possible for members of the community to build project artifacts from source code with reasonable effort.

Signed Artifacts

Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate.

Downloads

The project is allocated space on the Eclipse download and archive servers.

Project artifacts (e.g. downloads) can be distributed via third-party services (e.g. Maven Central), but — where technically sensible — the Eclipse Foundation-provided infrastructure must be considered the primary source of project downloads.

Project committers can upload project artifacts to the project’s directory on the download server. The short name is used to denote the area available to the project (e.g. https://downloads.eclipse.org/dash for the technology.dash project) via SFTP or SCP, or from a Eclipse Foundation hosted build infrastructure.

External Resources

Project teams may use services that are not hosted by the Eclipse Foundation (e.g. GitHub or DockerHub).

The following rules apply:

  • The Eclipse Foundation’s branding rules must be observed;

  • External services must not add legal terms or conditions that invalidate the project licenses or copyrights;

  • One or more project committers must have ownership rights; and

  • The usual level playing field must be observed.

Even when using services not hosted by the Eclipse Foundation, project teams are required to operate in an open, transparent, meritocratic, and vendor-neutral manner. Use of the service must not add an unreasonable access barrier for contributors, and no single individual or company can exert exclusive control of the service. Administrative level control of the service must be shared by as diverse a subset of the project committers as possible, and a documented policy must be established for managing that control.

All services require that users conform to some sort of terms of use that likely dictate copyright and licensing terms. Project leads must take care to ensure that those terms of use are not at odds with the project license or impact the copyright ownership of project contributions.

Warning

Source code, documentation, issues/tickets/bug reports must all be maintained using resources that are provided and managed by the Eclipse Foundation.

External resources can be used for:

  • User forum discussions (e.g, Slack);

  • Builds and alternative sources for downloads;

  • Container image management (e.g., DockerHub); and

  • Examples, presentations, blogs, social media handles.

This list is not exhaustive. Project leads should work with their Project Management Committee (PMC) and the EMO to determine the terms and conditions for an external resource are compatible with the project license(s), the Eclipse IP Policy, and Eclipse Foundation Development Process.

External resources must, where possible, include links to:

These links can be provided in a field, a README, or on directly accessible (i.e., linked) web page.

DockerHub

The Eclipse Foundation owns several organizations on DockerHub, including eclipse, locationtech, and polarsys, but does not formally support or strictly manage the use of these organizations.

For more information, please see CBI/DockerHub in the Eclipse wiki.

Note

Content distributed via official Eclipse Foundation channels must be complete enough that a consumer can (with reasonable effort) use it without needing the DockerHub distribution. That is, the DockerHub distribution needs to be considered a convenient way to leverage the content, not the only way. Please make sure that you treat any links or related discussion that you have on an Eclipse Foundation property about images distributed via DockerHub as an unofficial channel.

Subject to the rules for the use of external resources, a project team can create and maintain their own organization on DockerHub. The organization name must follow the pattern eclipse-<shortname> (e.g. eclipse-woolsey) or some variation (e.g. eclipsewoolsey). As indicated in the rules, ownership of the organization must be shared by a subset of project committers and the project must have a documented policy regarding how access to that organization is managed.

Additionally, a PMC may decide to create and manage an organization for the Top-Level Project. The PMC may have their own policy regarding the use of DockerHub. Project teams should consult with their PMC to determine which approach is best suited for the project.

Maven Central

The Eclipse Foundation has no formal relationship with Maven Central or staging providers like OSSRH. Eclipse project teams are, however, welcome to use these services as a distribution channel.

By convention, the groupid should be of the form org.eclipse.<shortname> (e.g. org.eclipse.dash for the technology.dash project). Project teams should work with their PMC if some exception to this convention is required (and take care to avoid infringing on the namespaces of other projects). The form of the artifactid should be determined by the project team. The version number should follow the standard Semantic Versioning pattern. All pre-release builds must be appropriately labelled (e.g. 1.0M3 for pre-release builds of version 1.0).

Project teams must engage in the Project Releases and Reviews process before labelling any software as a release version.

The Eclipse Release Engineering Team has provided some help regarding the use of Maven Central in the Eclipsepedia Wiki.

Frequently Asked Questions

  1. How do I get write access to a particular GitLab/GitHub project?

    Only committers have the ability to write to GitLab/GitHub projects that are managed by the Eclipse Foundation on behalf of Eclipse open source project repositories.

    In order to get write access, you must be elected as a committer on the corresponding Eclipse by an existing committer. In order to get access to a GitHub project, you must also provide your GitHub Id in your Eclipse Foundation Account.

  2. Can we connect service X to an Eclipse project’s GitHub Repositories?

    Our primary concern is that all decision making and planning (and related discussion) for the Eclipse open source project must be done in a manner consistent with the Open Source Rules of Engagement (open, transparent, and meritocratic) defined in the Eclipse Foundation Development Process.

    Growing a community and diversifying the project committers is a goal of every Eclipse open source project. Nothing quite kills a community’s enthusiasm like pointers to related issues that they don’t have access to, hints that there is a higher level of planning that they do not have access to, or otherwise suggest that the project is not being run in an entirely vendor-neutral manner.

    Care must be taken to ensure that all decisions regarding the direction taken by the project are being driven the committers.

    If you believe that the Eclipse project can be run as independent vendor neutral open source with the service attached, that is transparent and open to all comers and that there is a level playing field with a path that community members can follow to demonstrate merit and earn equal access to all project planning (that is, become committers), then you can request that the service be attached by creating a Help Desk issue.

  3. Can a project use the gh-pages support from GitHub to host at <project>.github.io?

    Yes.

  4. Can we use a GitHub repository for our project website source?

    Yes. Create a Help Desk issue to request support.

  5. Do we have to use the Eclipse Foundation-provided download server?

    If you provide content to your community via any form of click-to-download notion, then the Eclipse Foundation-provided download server must be the primary source of that content. If, however, the concept of a download doesn’t make sense for the sort of content that your project provides (e.g. your community consumes your context exclusively through Maven Central, or if source code is the only content delivered by the project), then you aren’t required to provide that content via the download server.

  6. Can we host pre-release software (e.g. milestone builds) on Maven Central?

    Reasonable steps must be taken to ensure that the consumer understands the pre-release nature of software. At a minimum, pre-release software must be labelled as such. A milestone build for version 1.0, for example, must be labelled as "1.0M1" (or similar). Pre-release software can be pushed to Maven Central, but due to the permanent nature of content that is pushed there, it will persist there indefinitely. Whether or not this is desirable is a decision that the project team should make with help from their PMC.

  7. Can we use external services like OSSRH to stage pre-release builds?

    Yes.

  8. Can an an Eclipse project accept anonymous code contributions?

    No. All contributions must be associated with their author using their legal name and a real email address. In pragmatic terms, the contributor must provide their legal name and email address in the Git commit’s Author field; the contributor must also have electronically signed the ECA using those same credentials.

Managing and Reporting Vulnerabilities

The Eclipse Foundation Vulnerability Reporting Policy contains information regarding obligations and specific practices regarding the reporting and disclosure of vulnerabilities.

Eclipse Foundation Security Team

The Eclipse Foundation Security Team provides help and advice to Eclipse projects on security issues and is the first point of contact for handling security vulnerabilities. Members of the Security Team are selected from committers on Eclipse Projects, members of the Eclipse Architecture Council, and Eclipse Foundation staff.

You can contact the Eclipse Foundation Security Team by sending email to security@eclipse-foundation.org or by open an issue in the general vulnerability issue tracker.

Project Setup for Vulnerability Reporting

The default project setup is to use general Eclipse Foundation reporting (see below). The strong recommendation is to list reporting methods clearly inside a SECURITY.md file in the main repository (also in other repositories if it makes sense) to help security researchers to communicate with the project in a secure way. Similar information should be available in the project’s documentation.

If the project decides to activate reporting via confidential issues (GitLab) or private security advisories (GitHub), please make a request via the Help Desk. The Eclipse Foundation Security team can train the project in using those means. When new reporting methods are set up, update your SECURITY.md accordingly.

In order to be able to set up, monitor, and also help projects dealing with security settings, new project are set up with members of the Eclipse Foundation Security team. Also, in GitHub repositories, if self-management is enabled, the project will include .eclipsefdn repository. Please refer to the documentation for more information.

Reporting

Vulnerabilities can be reported via a project-specific security tracker, or via general Eclipse Foundation means: an email to security@eclipse-foundation.org or and issue in the general vulnerability issue tracker.

The general security team email address can be used to report vulnerabilities in any Eclipse Foundation project. Members of the Eclipse Foundation Security Team will receive messages sent to this address. This address should be used only for reporting undisclosed vulnerabilities; regular issue reports and questions unrelated to vulnerabilities in Eclipse Foundation project software will be ignored. Note that this email address is not encrypted.

The community is encouraged to report vulnerabilities using the standard project-specific issue tracker. The appropriate link should be available in the project’s SECURITY.md file. In case of a doubt, use the general vulnerability issue tracker.

Note

Security vulnerabilities should be reported as confidential issues (on GitLab), private security advisories (GitHub) or other confidential means. If unsure, use the general vulnerability issue tracker with the default template.

Disclosure

Disclosure is initially limited to the reporter, the project team and the Eclipse Foundation Security Team, but is expanded to include other individuals, and the general public. The timing and manner of disclosure is governed by the Eclipse Foundation Vulnerability Reporting Policy.

Publicly disclosed issues are listed on the Known Eclipse Security Vulnerabilities page.

Common Vulnerabilities and Exposure (CVE)

The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority.

A unique vulnerability number like a CVE allows developers, distributions and security researchers to talk about the same issue using a common name. It also helps the project documentation.

The project team can ask for a number when they learn about the vulnerability: by receiving a report or simply by discovering it. They can request the number before the fix is ready, as the request will be confidential until the project tells the Eclipse Foundation Security Team to publish it.

Tip

If you’re not sure whether or not a CVE is required, err on the side of caution and request one.

A CVE number related to a bugfix release gives users a clear sign that an update is strongly recommended.

Think of a first CVE for your open source project as a rite of passage. Alerting your adopters of a vulnerability is a signal of maturity and responsibility to the open source community.

Project can request CVE numbers in different ways depending on the project setup.

General case

For most projects the process looks as follows:

  • Request the number: When you know that there is a security issue (the fix is not yet needed at this point), go to the CVE Request form and fill it. Make sure to keep the issue confidential for now. If you want to make the issue visible to multiple project members, add them as assignees when creating the ticket (it will be hard later on).

  • Receive the number: The Eclipse Foundation Security Team will come back to you with the assigned number. You can start using it internally when preparing documentation of the release containing the fix.

  • Prepare the fix (with backports to all supported branches) and the release: The common practice is to avoid using the CVE number in the fix commit message or the fix itself. Use generic terms instead. The goal is to allow time for all users to upgrade without giving potential attackers too much information. See also the next step (you can do them in parallel).

  • Ask for publication of the issue: When you have the fix ready and published, update the ticket. Make sure that you specify the version (or versions) where the bug is fixed, including all stable branches. Fill in the description of the issue. You may also consider removing some of the comments (for example containing sensitive or incorrect information). At this stage you may decide to publish only partial information (for example without the link to the commit with the fix). Then ask the security team to make the CVE and the discussion of the CVE assignment public. Ideally your release and the publication happen at the same time. You can ask for a publication at your specific date, for example at your planned release date.

  • See it publicly: The ticket becomes public and the Eclipse Foundation Security Team publishes the CVE entry.

  • (Optional, a few days later) Update the entry with all additional information that might be helpful. That includes, for example, the link to the fix commit.

Note

Project committers should make it clear if their request is a reservation of a CVE number, or a publication.

Tip

When working with GitLab confidential issues, be careful. Only the author of the ticket, all committers in the project containing the issue tracker, and assigned people will see the issue and receive notifications.

Adding new assignees who are not members of the project has no effect when the issue is already confidential. When in doubt, verify with the concerned person if they receive notifications by other communication means.

The Tracking section of the request issue includes some checkboxes for the project team and for the Security Team. The Security Team will assign the CVE upon receipt of the request, but will not escalate (that is, they will not report the assignment of the CVE to the central authority) until after a project committer clearly indicates that they are ready to disclose the vulnerability.

…​

This section will completed by the project team.

  • ❏ Reserve an entry only

  • ❏ We’re ready for this issue to be reported to the central authority (i.e., make this public now)

  • ❏ (when applicable) The GitHub Security Advisory is ready to be published now

…​

Check the second checkbox when you’re ready for the Eclipse Foundation Security Team to submit the request to the central authority (that is, when you’re ready for the issue to be disclosed publicly).

If the project is using a GitHub Security Advisory to track mitigation of the vulnerability, the Security Team intervention will likely be required to submit the advisory. Click the second checkbox to indicate that you’re ready for the Security Team to submit the advisory on the project team’s behalf.

Projects Using Exclusively GitHub Security Advisories

If the project receives reports exclusively by private reporting with GitHub Security Advisories, the procedure is as follows:

  • Prepare the initial data: The project receives initial data in the report and assesses that it is a real vulnerability.

  • Request the number: When you know that there is a security issue (the fix is not yet needed at this point), contact the Eclipse Foundation Security Team to request the number.

  • Receive the number: The Eclipse Foundation Security Team will request a number and GitHub will assign one (or ask for more information in the report). You can start using it internally when preparing documentation of the release containing the fix.

  • Prepare the fix (with backports to all supported branches) and the release: The common practice is to avoid using the CVE number in the fix commit message or the fix itself. Use generic terms instead. The goal is to allow time for all users to upgrade without giving potential attackers too much information. See also the next step (you can do them in parallel).

  • Ask for publication of the issue: When you have the fix ready and published, as the Eclipse Foundation Security team to publish the advisory. Make sure that you specify the version (or versions) where the bug is fixed, including all stable branches. Fill in the description of the issue. You may also consider removing some of the comments (for example containing sensitive or incorrect information). At this stage you may decide to publish only partial information (for example without the link to the commit with the fix). Ideally your release happens earlier or at the same time as the publication. You can ask for a publication at your specific date, for example at your planned release date.

  • See it publicly: The advisory becomes public, so is the CVE entry.

  • (Optional, a few days later) Update the entry with all additional information that might be helpful. That includes, for example, the link to the fix commit.

Required Information

For all types of request, the project needs to prepare information about the vulnerability.

The request for a publication must provide:

  • The name of the impacted project and product;

  • A description of the versions impacted (which may include ranges);

  • A Common Weakness Enumeration (CWE) code;

  • A one or two sentence summary of the issue which clearly identifies the Eclipse project/product and impacted versions; and

  • A pointer (URL) to the issue used to track mitigation of the vulnerability.

The request may optionally include additional information, such as a Common Vulnerability Scoring System (CVSS) code, a link to the commit fixing the issue etc.

Example CVE Report data
Project name: Eclipse Vert.x

Project id: rt.vertx

Versions affected: [3.0, 3.5.1]

Common Weakness Enumeration:

- CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

Summary:

In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response
headers and HttpClient request headers do not filter carriage return and
line feed characters from the header value. This allow unfiltered values
to inject a new header in the client request or server response.

Links:

- https://gitlab.eclipse.org/eclipse/myproject/-/issues/12345

If unsure on how to fill the form, ask the Eclipse Foundation Security Team for assistance.

Frequently Asked Questions

  1. In what form should a disclosure be published? Is publishing the bug on the Known Vulnerabilities page enough?

    Publishing on the Known Vulnerabilities page will happen automatically. This is minimal disclosure. Whether or not you should do more is a project team decision. If you need help with that decision, connect with your Project Management Committee (PMC) or the Security Team.

    If the vulnerability real and is in release software (i.e., it’s likely to have been adopted), you should request a CVE.

    You should let your community know about the vulnerability though your usual communication channels.

  2. Can I already commit the fixes to our repository and provide a service release, or shall I wait for some part of the disclosure process first?

    In general, you should fix the issue first and prepare a bugfix release.

    Whether or not we disclose in advance of making the fix available is a judgement call. Many projects notify of a date of an imminent security bugfix release in advance, without releasing the details. Users can then plan their update. When there is a real risk that somebody may exploit the vulnerability, you generally want to inform your adopters as quickly and discretely as possible so that they can prepare themselves.

    If the issue is particularly sensitive and you need to make that fix in a private repository and coordinate disclosure, connect with Security Team and we’ll help. Very few projects actually need to go to this extreme.

  3. Is there something specific I should add (or something I should avoid mentioning) in the commit message?

    That depends. In general, you should avoid adding anything that calls particular attention to the vulnerability. Just state what the commit contains. Especially avoid expressions like vulnerability or using a reserved CVE number.

  4. Do we need a CVE?

    It’s up to the project team. We need the project team to engage with the process of gathering the information required to report the vulnerability to the central authority; the first step in that process is deciding whether or not a CVE is desired/required.

    The general rule is that a CVE is required when a vulnerability impacts release software. The Eclipse Foundation Security Team has given this advice (paraphrased):

    If someone can download compiled (e.g., JAR) files and use them without any sort of compilation process then we are inclined to say that there exists a tangible risk to consumers and so a CVE should be requested. That is, unless that version string specifically says alpha or beta, or the content has otherwise clear warnings to not use it in a production context, then we should — as good citizens — create a CVE. Merely being versioned 0.x instead of 1.x doesn’t absolve the situation.

    If you’re not sure, check with your PMC or the Security Team.

    It’s a bit of a rite of passage for an open source project to disclose their first vulnerability. If in doubt, ask the Eclipse Foundation Security Team for guidance.

  5. Do we need a CVE for versions of software that we released before moving our project to the Eclipse Foundation?

    The answer to this is not obvious, but as a general rule…​ no. The answer is not obvious because the continuity of the source of affected products may not be obvious (or relevant) to consumers, and it is not strictly wrong for a CVE Numbering Authority to create a CVE for a version of a product not immediately in their purview.

    Ultimately, whether or not we should create a CVE is the project team’s call.

  6. I think that my project hasn’t received all notifications about security issues?

    In this case, please contact the Security Team. Please note that the Eclipse Foundation Security Team notifies project leads by default.

  7. I can’t see a confidential issue in the Eclipse Foundation GitLab instance

    If you have received a notification of a confidential issue by email, make sure to log in to the Eclipse Foundation instance of GitLab first, before following the link. Otherwise you will get a 404 error page.

    If you are following a link, verify with the person managing the issue (for example the reporter) if you have been added to the issue. Currently, in the general issue tracker, each person needs to be added manually. In case of difficulties, ask the Eclipse Foundation Security team for assistance.

    Also please note that we need an activated GitLab account to add a user to a confidential issue. In practice, the user needs to log in into the Eclipse Foundation GitLab instance at least once.

  8. Confidential issues are not visible to all committers

    Currently, in the general issue tracker, each person needs to be added manually. In case of difficulties, ask the Eclipse Foundation Security team for assistance.

  9. I can see .eclipsefdn repository in my project. What is this?

    This repository is used to keep project management data. See the related documentation or ask the Eclipse Foundation staff for help.

Contributing to an Eclipse Project

Contributors

Anybody can be a contributor. To be a contributor, you just need to contribute. Contributions typically take the form of code or documentation submitted to the project’s source code repository, but may also take the form of answering questions in project and community forums, and more.

For contributions that contain intellectual property (e.g., source code or documentation), some formal documentation is required to ensure that the rights associated with the intellectual property are properly managed and licensed.

To contribute to an Eclipse open source project, a contributor must:

  1. Create an Eclipse Foundation Account;

  2. Sign the Eclipse Contributor Agreement;

  3. Read the project’s contribution guide to learn about coding style and other guidelines for contributions (contribution guidelines are typically found a CONTRIBUTING or README file in the root of every source code repository);

  4. Create a commit:

    • Ensure that the author credentials on the commit record match the email address associated with their Eclipse Foundation Account

  5. Create a pull request (GitHub), merge request (GitLab), or submit a review (Gerrit); and

  6. Work with the project team to merge the contribution.

Contributors retain ownership of their contributions; the ECA, for example, states in part:

This ECA, and the license(s) associated with the particular Eclipse Foundation projects You are contributing to, provides a license to Your Contributions to the Eclipse Foundation and downstream consumers, but You still own Your Contributions, and except for the licenses provided for in this ECA, You reserve all right, title and interest in Your Contributions.

That is, the contributor owns their contributions, but grants a license to the Eclipse Foundation and downstream consumers to use them under the terms of the project license.

contributor contributors
Becoming a contributor
Note

Eclipse committers must engage with the EMO Intellectual Property Team to review your project code contributions, or third-party content that your contributions leverage. The committers will take are of this, but may need your help as part of the process.

After establishing a pattern of contributing high quality contributions a contributor may be invited to join the project as a committer; an existing project committer will nominate a contributor to be a committer via committer election.

Note

In order to grant the ability to assign issues and merge/pull requests to a non-committer contributor on repositories that are hosted either on GitLab or GitHub, a committer must designate the individual as a contributor by providing their email address in the Contributors field in the project’s metadata (PMI).

Committers

For Eclipse projects (and the open source world in general), committers are the ones who hold the keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so the Open Source Rules of Engagement described by the Eclipse Foundation Development Process, puts meritocracy on equal footing with transparency and openness: becoming a committer isn’t necessarily hard, but it does require a demonstration of merit.

In practical terms, there are two ways to become an Eclipse Committer.

The first way is to be listed as an initial committer on a new project proposal. When projects come to the Eclipse Foundation we need them to actually start with committers, and so we include this as part of the bootstrapping. As part of the process of community vetting a new project proposal, the committers listed are themselves vetted by the community. In effect, the project proposal process also acts as a committer election that’s open to the entire community.

The second way to become a committer is to get voted in via committer election. After an individual has made a small number of high quality contributions that demonstrate that they understand how the project works, understand the Eclipse Foundation Development Process and are prepared to implement the Eclipse Foundation Intellectual Property Due Diligence Process, a committer will invite them to join the team and initiate the election. Committer elections start with a nomination by an existing committer that includes a statement of merit that usually takes the form of a list various contributions that the individual has made to the project. What constitutes a sufficient demonstration of merit varies by project team.

Note

Committer status is assigned on a project-by-project basis. That is, individuals have committer rights only on those projects for which they hold committer status. For all other projects, they are contributors.

When a contributor becomes a committer, they must be covered by a committer agreement (either a Member Committer and Contributor Agreement (MCCA) or an Individual Committer Agreement (ICA). Committers on specification projects must be covered by additional agreements. As the last step in the committer election process, the Eclipse Foundation systems will determine which agreement applies and engage a committer paperwork workflow with the new committer to ensure that everything is in place.

Eclipse Foundation Account

Eclipse Foundation project resources are accessible without an account. That is, members of the community may browse code, documentation, issues, help, etc. without creating an Eclipse Foundation Account.

Those members of the community that wish to contribute code patches, open issues, add content to wikis, etc. must create an Eclipse Foundation Account.

For contributors and committers, their Eclipse Foundation account is their primary portal into their relationship with the Eclipse Foundation. From their account page, individuals can sign the Eclipse Contributor Agreement, manage their mailing list subscriptions, access build resources, and more.

Tip

If you’re working with projects that use GitHub, be sure to add your GitHub Id to your Eclipse Foundation Account so that our scripts can add you to the GitHub Teams that we use to manage access to Eclipse Foundation repositories hosted on GitHub. When you become a committer on an Eclipse project that hosts their source code repositories on GitHub, you will be sent an invitation to join the GitHub Team associated with that project.

Employed by a Member Company

If you are employed by an Eclipse Foundation Member Company when you create your Eclipse Foundation Account, you must align your account with your employer.

In the field where it asks "What is your employment status?":

  • Highlight "Work for an Eclipse Member Organisation"; and

  • Pick your employer from the list.

organization selection
Specify that you work for a member organisation.
Tip

Specifying your employer information in this manner will ensure that your contributions can be traced back to your employer and we can, for example, correctly display company logos based on your contributions. This will also ensure that you are automatically covered by the ECA in the case where your employer has already signed the agreement on behalf of their employees.

If your employer is not listed and you believe that this is an error, contact EMO for assistance.

If you change employers, contact the EMO Records Team to request that they update your employment status information.

Eclipse Contributor Agreement

The purpose of the Eclipse Contributor Agreement (ECA) is to provide a written record that contributors have agreed to provide their contributions of code and documentation under the licenses used by the Eclipse project(s) they’re contributing to. It also makes it clear that contributors are promising that what they are contributing to Eclipse is code that they wrote, and that they have the necessary rights to contribute it to Eclipse projects. And finally, it documents a commitment from the contributor that their open source contributions will be permanently on the public record.

All contributors, who are not committers on the Eclipse project, must sign the Eclipse Contributor Agreements (ECA) to ensure that the necessary intellectual property (IP) rights to the contribution are granted.

Contributors who are already covered by a committer agreement (either an MCCA or ICA) are not required to also sign the ECA.

Tip

You can determine your ECA status from your Eclipse Foundation Account page. Your ECA status is shown in the top-right corner.

Committers do not require an ECA to contribute to a project on which they have committer status.

Frequently Asked Questions

  1. Is there any requirement on what is necessary for committers/project leads to consider when dealing with contributions from someone from the same company?

    No requirement. Getting reviews/approvals from any committer on your project is sufficient, whether they are from the same company or different.

    Project teams may establish their own rules regarding how contributions are accepted. These rules range from allowing any committer to approve a contribution, to requiring that contributions from a committer be approved by another committer, to requiring that all contributions be approved by a project lead. Whatever the case, it should be documented (typically captured in a CONTRIBUTING file).

    It is generally considered good practice (or a nice-to-have) to request a review from an "outsider", especially if the proposed change might be considered complex or controversial. It’s always good to get outside viewpoints. But the specific rules are left for the project team to decide.

  2. Do I need to sign the Eclipse Contributor Agreement (ECA)?

    If you are not a committer on a particular Eclipse open source project, to contribute (e.g., make pull requests) to that project, you need to be covered by an ECA. If you are already a committer on any Eclipse open source project, then you are already covered by an ECA through your committer agreement and do not need to sign the ECA separately. If your employer has signed the Member Committer and Contributor Agreement, then you are already covered by an ECA and you do not need to sign the ECA separately.

    If you are a committer on a project you do not need an ECA to contribute to that project.

    Assuming that you are empowered to do so, you can individually sign the ECA even if you are already covered by another agreement.

  3. How do I know if I’m covered by an Eclipse Contributor Agreement?

    Visit your Eclipse Account page. Your Eclipse Contributor Agreement (ECA) status is shown in the top-right corner.

    For example, this contributor is covered by the ECA (and is a committer on one or more Eclipse Foundation open source projects).

    accounts status
  4. How do I know if somebody else is covered by an Eclipse Contributor Agreement (ECA)?

    Visit your Eclipse Foundation Account page and click on "Eclipse Contributor Agreement" in the Status block. Use the ECA Validation Tool on My Eclipse Contributor Agreement page to verify the ECA status of an individual using their email address.

    eca validation tool
  5. How do I know if my employer is a member of the Eclipse Foundation?

    If your employer is a member of the Eclipse Foundation, they will be listed on the Explore Our Members page.

  6. How do I know if my employer has signed the Member Committer and Contributor Agreement (MCCA)?

    Check with your manager. If your manager doesn’t know, you can contact the EMO Records Team for assistance.

  7. I know that my employer has signed the Member Committer and Contributor Agreement (MCCA), but my account page shows that I am not covered by the ECA. What should I do?

    It’s likely that you haven’t provided us with employer information. In order for our systems to know that you are affiliated with a particular organization, you must specify your employer in your Eclipse Foundation Account.

  8. I am a committer on a project, but I cannot push to that project’s GitHub repositories. What should I do?

    It’s likely that you haven’t provided us with your GitHub Id. Our systems manage the composition of the GitHub teams that have the necessary privileges on project repositories. For that, we need your GitHub Id, which you must provide us with in your Eclipse Foundation Account.

Elections

Roles in a project are assigned based on merit demonstrated in a publicly-accessible forum, in the form of an election. Elections start with a nomination that contains a statement of merit. The nature of a statement of merit varies widely, but is generally expected to to concisely state the impact that the nominee has had on the project.

Note

Employment status has no bearing at whether or not somebody can participate in an open source project at Eclipse. Employment does not, for example, guarantee committer status; committer status must be earned by everybody.

Committer Elections

Contributors who have the trust of the project’s committers can, through election, be promoted to committer status for that project. The breadth of a committer’s influence corresponds to the breadth of their contribution. A development team’s contributors and committers may (and should) come from a diverse set of organisations. A committer gains voting rights allowing them to affect the future of the project. Becoming a committer is a privilege that is earned by contributing and showing discipline and good judgement. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse Foundation member company or any company employing existing committers.

Being a Eclipse committer is more than just having write-access to the project resources: there are specific IP due diligence and record keeping activities that committers must follow. New committers must ensure that they are familiar with the Committer Due Diligence Guidelines.

New committers should be encouraged to join the Incubation Mailing List; this list is a good place to ask questions about process, services available, and other aspects of working as a committer.

What are the Requirements?

There are only three requirements around nominating and electing new committers (note that there are additional committer paperwork requirements for the new committer):

  • Define trust;

  • Maintain vendor/employer neutrality; and

  • Operate transparently (public and archived election).

Each project is entitled to define how it evaluates "[people] who have the trust of the Project’s Committers …​ [through] contributing and showing discipline and good judgement". This definition must be consistent with the top-level project charter, and must be transparent and public document on the project’s website. It is extremely important to publish these criteria to avoid any issues around cliques or "the in-crowd" preventing others from joining a project.

There must not be any hint of "we (company W) hired person X to work on project Y thus person X should elected a committer". Committer status is independent of employment; there are well-supported mechanisms for contributors without commit-rights and thus committer status is not required for a team member to be effective. Additionally, the team will want to make sure that they have confidence in the candidate irrespective of employment and management because the committer status will continue even after moves to another job.

The nomination and election process for a new committer is for more than just the project team - it is also for the entire Eclipse community, current and future. The larger community uses the artifacts of elections as (one of many pieces of) evidence about the maturity of the project team, and thus quality of the frameworks.

Note

Nominations such as "we all know Bob, vote for him" may work within the team, but actually harm the project’s reputation in the larger Eclipse community: that larger community does not know Bob and does not understand why the project team trusts him with the source code.

What Should a Nomination Look Like?

A committer nomination should explain the candidate’s contributions to the project and thus why they should be elected as a committer. Cite the issues they have fixed via patches; cite the community forum postings they have answered; cite the dev-list design discussions to which they have contributed; etc. In all cases, provide URLs to source material.

How does an Election work?

Use the Committer Tools  Nominate a Committer link on the corresponding project page and follow the workflow to start a committer election.

committer election2
The New Committer Nomination Form

Project committers will be notified to participate in the election via the project’s dev-list.

Note

Your project must have a dev-list specified in the project’s metadata and existing project team members must be subscribed to the list.

An election starts with a nomination by an existing committer.

elections overview
An overview of the Election Process

Only project committers may nominate a new committer or vote in a committer election. To be successful, the election must receive a minimum of three positive +1 votes. Any committer can veto the election by casting a -1 vote, or indicate their participation in the process but with no opinion with a +0 vote. For projects with three or fewer committers all committers must vote. Committer elections run for one week, but will end prematurely if all project committers vote +1.

Tip

Committers can change their vote while the election is in progress. Committers may post questions about the committer or ask for clarification of the merit statement in the project’s dev-list, and change their vote based on what they discover. The merit statement itself cannot be changed after the election has started.

Following a successful committer vote, the project’s Project Management Committee (PMC) will review the election results and then either approve or veto the election. An election may be vetoed, for example, if the PMC feels that the merit statement is not strong enough.

The paperwork process will automatically be initiated following PMC approval of an election.

Project Lead Elections

Similar to a committer election, a project lead election starts with a statement of merit. The merit statement should, rather than focus on specific code contributions, focus instead on the leadership qualities expressed by the individual.

Example 1. Project Lead merit statement

Robert Smith has been part of the Eclipse Dash development since before the initial contribution. He played an important role ever since, as he is one of the key developers. With regards to the number of commits Robert is currently the top committer of Eclipse Dash:

https://github.com/eclipse/dash-licenses/commits?author=RobertSmith

Apart from that Robert took care of the project page and the build. He also handed the governance aspects of the 0.6 release.

Finally I would like to mention a blog post he did at thecure.com:

https://thecure.com/dash

Project leads are normally also committers. A project may have more than one project lead (so-called co-leads).

Use the Committer Tools  Nominate a Project Lead link on the corresponding project page to start a project lead election.

Only project committers can nominate a new project lead or vote in a project lead election. To be successful, a project lead election must receive a minimum of three positive +1 votes. Any committer can veto the election by casting a -1 vote. For projects with three or fewer committers all committers must vote. Committer elections run for one week, but will end prematurely if all project committers vote +1.

Following a successful committer vote, the project’s PMC will review the election results and then either approve or veto the election. A PMC-approved election will be referred to the EMO/ED as a recommendation for appointment. The final decision rests with the EMO/ED.

PMC Member Elections

Project Management Committee (PMC) members are elected by the existing PMC leads and members, and approved by the EMO/ED. The criteria by which a PMC Member is selected varies by PMC. Some PMCs are set up to have a representative from each of the projects in the top-level project. Other PMCs are more exclusive and require a demonstration of merit.

In all cases, the PMC Lead makes a recommendation to the EMO/ED to appoint a PMC Member. The final decision rests with the EMO/ED.

Tip

No specific infrastructure is exists for PMC Member elections. PMCs must use their PMC mailing list to nominate and elect new members, and report the results to the EMO. The EMO will get approval from the EMO/ED and make the appointment.

PMC Lead Appointments

Project Management Committee (PMC) Leads are not elected. They are vetted by the EMO, approved by the Eclipse Board of Directors, and appointed by the EMO/ED.

Committer Retirement

A committer can retire themselves from a project. Retirement cannot be undone: to rejoin a project as a committer after being retired, a contributor must again be nominated and elected into the role.

Tip

To retire from a project, navigate to the project page, open the Who’s Involved tab, and click on your image in the committer list. Then, in the "Retire Committer Status" box on the on the project role page, check the checkbox and click the Submit button.

elections retire self

A project lead may also retire a committer. A project lead might, for example, retire a committer that has been inactive for an extended period of time (e.g., longer than a year). Before retiring a committer, the project’s community should be informed of the change and the committer must be given a chance to defend retaining their status via the project’s dev-list.

Retired committers are listed as Historic Committers on a project’s Who’s Involved page. To restore an historic committer to committer status, they must be re-elected into the role.

Note

A common practice is for the project lead to use the project’s dev-list to announce generically that they’re going to retire committers that have been inactive for some designated period of time and give the committers a chance to speak up before a deadline.

There is no means by which a committer can be forced out of a project if they have not done anything wrong (there is no notion of "voting a committer out" of a project). Leaving the company that sponsors the project, for example, is not a valid reason for retirement. On the other hand, that a committer has changed jobs or roles and can no longer continue to contribute the project is a completely valid reason for retirement.

Project Lead Retirement

A project lead can retire themselves from a project. Prior to retiring, a project lead should work with the project team to ensure the continuity of the role (e.g., in the case where a project’s sole project lead plans retirement, they should engage with the team to identify and elect a replacement). In the spirit of open source transparency, a retiring project lead should announce their retirement on the project’s dev-list.

Tip

To retire from a project, navigate to the project page, open the Who’s Involved tab, and click on your image in the project lead list. Then, in the "Retire Project Lead Status" box on the on the project role page, check the checkbox and click the Submit button.

elections retire pl

Retiring Other Roles

Connect with the PMC or EMO for assistance.

Troubleshooting

In the case where the project is dysfunctional (e.g., there is no active project lead and an insufficient number of active committers to offset inactive committers), options are available to the PMC to add and/or remove committers.

Tip

If you believe that a project is in a dysfunctional state, contact the PMC via their mailing list to request assistance.

Frequently Asked Questions

  1. Do we really need to do this?

    Yes.

  2. Can I still be a committer if I change employers?

    Yes. Your status as a committer is not tied to your employment status. You may, however, require Committer Paperwork from your new employer (or if you become self-employed). If you change employers, please contact the EMO Records Team for help regarding paperwork requirements.

  3. What happens if committers don’t vote?

    If a project has three or fewer committers, then all committers must vote. If even one out of the three does not vote, then the election will end in failure. If the non-voting committer is also not active, then they can, perhaps, be retired by the project lead.

  4. Can we change a merit statement?

    The election infrastructure doesn’t permit changing a merit statement after an election has begun (the principle being that changing the question after you start a vote is considered bad form).

    In cases where the merit statement is omitted or considered inadequate, or committers have additional questions about a candidate, it’s completely reasonable to discuss it on the mailing list, and for committers to then use that discussion as the basis for their vote. Committers who have already voted, can return to the election record and change their vote.

    Committers can also add information via the comment that accompanies their vote on an election.

  5. Can a committer change their vote on an election?

    Yes. A committer can change their vote while an election is still in progress.

  6. How do we transfer committers from one project to another?

    Short answer: you don’t

    We have no concept of transferring committers. if committers need to move from one project to another, then they must be elected as committers to the new project and retire themselves from the old one.

  7. Can a project lead retire a disruptive committer?

    The EDP allows a project lead to retire a disruptive committer. This is basically the "nuclear" option and so should be used sparingly; we have only retired a few committers in this manner. Should a project lead decide to take this step, they should be prepared to provide evidence to back up the claim of disruption. The project lead should work with the PMC and EMO to determine how (or if) that evidence is tracked and disseminated.

Committer Paperwork

The Eclipse Foundation needs to ensure that all committers with write access to the code, websites, and issue tracking systems understand their role in the intellectual property process. The Eclipse Foundation also needs to ensure that we have accurate records of the people who are acting as change agents on the projects. To ensure that committers understand their role, and that the Eclipse Foundation has accurate records, committers must provide documentation asserting that they have read, understood, and will follow the committer guidelines. Committers must also gain their employers consent to their participation in Eclipse Foundation open source projects.

All committers must complete the Committer Agreement Workflow, which includes the Committer Questionnaire and documentation as described below.

Committer Questionnaire

The Committer Questionnaire is an online form that must be completed by all new committers. This form offers two separate paths: one for committers who work for a member company that has provided a signed Member Committer and Contributor Agreement (MCCA), and one for everyone else.