Four basic principles lie at the heart of the EDP:

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.

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 organizations 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 organization or individuals who claim copyright of the code are the legitimate copyright holders, and the copyright holders legitimately agree to make the code available under the license(s) that the project works under. As a committer, you must be careful that you do not copy code and inadvertently claim it as your own.

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.

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.

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

When you feel that the proposal is ready, send a note to the Eclipse Management Organization (EMO) 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, project leads, and mentors 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.

The proposal must list at least one mentor from the Eclipse Architecture Council. Members of the Eclipse Architecture Council have considerable experience with Eclipse Foundation practices, and the Eclipse Foundation Development Process. The EMO will engage directly with the Architecture Council to identify mentors as necessary. Mentors are assigned to the project through the incubation phase; they are released from their duties when the project graduates.

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

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.

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.

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.

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.

Eclipse projects move through various phases. Projects in active phases (incubation or mature) engage in all the normal sorts of development activies: 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.

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

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:

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 Organization(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.

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.

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.

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.

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 organization 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.

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.

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.

The Eclipse Management Organization (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, mentor, or PMC, ask the EMO.

Project resources make use of two sorts of ids:

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.

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).

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:

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.

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.

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 organize 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 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:

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.

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:

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. Open an issue to request that the Eclipse IT Team configure your Git repository for Gerrit.

Commits may be pushed directly to the Git repository through Gerrit by a project committer (e.g. to the main branch).

Anybody can push to a refs/for/* branch for review in a Gerrit repository. A push that includes commits that do not conform to the required form will be rejected. Commits intended for review should have a Change-Id. The Eclipse Contributor Agreement (ECA) hook will inspect incoming Gerrit review requests to ensure that the contributor has a valid ECA on file; attempts to push will fail in the case where the author credentials cannot be matched to an Eclipse Foundation account with a signed ECA.

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

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).

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.

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 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 webite. 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.

Project websites must implement the branding guidelines for project websites.

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).

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.

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.

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.

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.

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

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.

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

The following rules apply:

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.

External resources can be used for:

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.

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.

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 {Helpdesk}[https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/new]. 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.

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.

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.

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.

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

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:

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

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.

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.

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.

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 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.

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.

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

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 organizations. 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 judgment. 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.

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.

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.

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.

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.

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.

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.

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.

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 replacment). In the spirit of open source transparency, a retiring project lead should announce their retirement on the project’s dev-list.

Connect with the PMC or EMO for assistance.

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.

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.

The Committer Questionnaire is accessible only after an individual has been elected into the role of a committer on a project (note that all committer relationships are between an individual and a specific project), either as an initial committer on a new project, or via Committer Election on an existing project. New committers will be sent a link to the questionnaire via email.

The specific agreements required depends on the nature of the project and the employment status of the individual. For committers on an open source software project (i.e., most Eclipse projects), the agreements described below are required. For committers on an open source specification project, additional working group agreements are required.

The new committer must download and print the documents, complete and sign them, and then provide them to the EMO Records Team. The Committer Agreement Workflow provides a means of uploading these documents; alternatively, the team may ask you to provide them via email.