////
 * Copyright (C) 2015 Eclipse Foundation, Inc. and others. 
 * 
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License v. 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0.
 * 
 * SPDX-License-Identifier: EPL-2.0
////

[[elections]]
== 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 {forgeName}. Employment does not, for example, guarantee committer status; committer status must be earned by everybody.
====

[[elections-committer]]
=== 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 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 {forgeName} 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 {committerGuidelinesUrl}[Committer Due Diligence Guidelines].

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

[[elections-requirements]]
==== What are the Requirements?

There are only three requirements around nominating and electing new committers (note that there are additional <<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 judgment". This definition needs to be a transparent and public document on the project's website (the top-level project charter may provide this). 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; thereare 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 {forgeName} 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 {forgeName} community: that larger community does not know Bob and does not understand why the project team _trusts_ him with the source code.
====

[[elections-nomination]]
==== 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.

[[elections-how]]
==== How does an Election work?

Use the menu:Committer Tools[Nominate a Committer] link on the corresponding <<pmi-project-page,project page>> and follow the workflow to start a committer election.

.The New Committer Nomination Form
image::images/committer-election2.png[]

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 <<pmi,metadata>> and existing project team members must be subscribed to the list.
====

An election starts with a nomination by an existing committer.

[graphviz, images/elections-overview, svg]
.An overview of the Election Process
----
digraph {
	// Graph properties
	bgcolor=transparent
	
	// Decisions
	node [shape=diamond;style=filled;fillcolor=white;fontsize=10];
	time [label="", group=g1];
	approval [label="PMC\nApproves", group=g1];
	
	// Notes
	node [shape=plaintext;fillcolor=transparent;fontsize=10]
	oneweek [label="One week passes or\nall committers\nhave voted"];
	
	node [shape=box;style=filled;fillcolor=white;fontsize=12];
	start [label="Nominate", group=g1];
	ongoing [label="Ongoing", group=g1];
	timedout [label="Timed out"];
	complete [label="Complete", group=g1];
	approved [label="Approved"];
	vetoed [label="Vetoed"];
	rejected[label="Rejected"];
	
	{rank=same timedout, approved, vetoed, rejected}
	
	edge [fontsize=10];
	start->ongoing
	ongoing->ongoing [label="Committers Vote"];
	ongoing->time
	time->timedout [xlabel="Not\nenough\nvotes"]
	time->complete
	time->rejected [xlabel="Vetoed\nby\ncommitter"]
	complete->approval
	approval->approved [xlabel="Yes"]
	approval->vetoed [xlabel="No"]
	
	edge [color=grey]
	oneweek->time
}
----


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 `pass:[+1]` votes. Any committer can veto the election by casting a +pass:[-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 `pass:[+1]`.

Following a successful committer vote, the project's 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, paperwork>> process will automatically be initiated following PMC approval of an election. 

[[elections-pl]]
=== 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.

.Project Lead merit statement
=====================================================================
Sounak has been part of the Ogee 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 Sounak is currently the top committer of Ogee:

http://git.eclipse.org/c/ogee/org.eclipse.ogee.git/stats/?period=q&ofs=10

Apart from that Sounak took care of the project page and the build. For release 0.6 he also handled the review formalities for me. Finally I would like to mention a blog post he did at odata.org to promote Ogee in the OData community:

http://www.odata.org/blog/eclipse-ogee 
=====================================================================

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

Use the menu:Committer Tools[Nominate a Project Lead] link on the corresponding <<pmi-project-page,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 `pass:[+1]` votes. Any committer can veto the election by casting a `pass:[-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 `pass:[+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.

[[elections-pmc-member]]
=== PMC Member Elections

The manner in which a top-level project's Project Management Committee (PMC) _Member_ is appointed 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 run an election similar to that of a project lead election. 

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.

[[elections-pmc-lead]]
=== PMC Lead Appointments

PMC _Leads_ are not elected. They are vetted by the EMO, approved by the Eclipse Board of Directors, and appointed by the EMO/ED.

[[elections-faq]]
=== Frequently Asked Questions

[qanda]
Do we really need to do this? ::

Yes.

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 <<paperwork>> from your new employer (or if you become self-employed). If you change employers, please contact the mailto:{emoRecordsEmail}[EMO Records Team] for help regarding paperwork requirements.
	
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. Connect with mailto:{emoEmail}[EMO] for assistance.

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.