source/chapters/preamble.adoc - gerrit/dash/org.eclipse.dash.handbook - Git at Google

 ////
  * 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
 ////

 [[preamble]]
 == Overview

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

 ifeval::["{forgeName}"!="Eclipse"]
 While this document is focused on {forgeName}, it makes several "Eclipse" references, including the _Eclipse Foundation_, _Eclipse Development Process_, and _Eclipse Management Organization_. The Eclipse Foundation is the legal entity that manages the operations of the {forgeName} working group, software development forge, and community.Many of the provided services and contacts are so-named on that basis.
 endif::[]

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

 [[preamble-principles]]
 === Principles

 Four basic principles lie at the heart of the Eclipse Development Process:

 * 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 {forgeName} means quite a lot more than "open book" (which is really a synonym for transparent). The project is open to all; {forgeName} 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.

 {forgeName} 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 {forgeName} 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 <<elections, election>>.

 [NOTE]
 ====
 Employment status has no bearing at whether or not somebody can participate in an open source project at {forgeName}. 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, {forgeName} 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, {forgeName} quality means working with a transparent and open process, open and welcoming to participation from technical leaders, regardless of affiliation.

 _<<ip,Intellectual property>>_ (IP) is any artifact that is made available from a {forgeName} 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 {forgeName} project is used by organizations to build products. These adopters of {forgeName} 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.
	////
	* 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
	////

	[[preamble]]
	== Overview

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

	ifeval::["{forgeName}"!="Eclipse"]
	While this document is focused on {forgeName}, it makes several "Eclipse" references, including the _Eclipse Foundation_, _Eclipse Development Process_, and _Eclipse Management Organization_. The Eclipse Foundation is the legal entity that manages the operations of the {forgeName} working group, software development forge, and community.Many of the provided services and contacts are so-named on that basis.
	endif::[]

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

	[[preamble-principles]]
	=== Principles

	Four basic principles lie at the heart of the Eclipse Development Process:

	* 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 {forgeName} means quite a lot more than "open book" (which is really a synonym for transparent). The project is open to all; {forgeName} 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.

	{forgeName} 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 {forgeName} 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 <<elections, election>>.

	[NOTE]
	====
	Employment status has no bearing at whether or not somebody can participate in an open source project at {forgeName}. 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, {forgeName} 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, {forgeName} quality means working with a transparent and open process, open and welcoming to participation from technical leaders, regardless of affiliation.

	_<<ip,Intellectual property>>_ (IP) is any artifact that is made available from a {forgeName} 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 {forgeName} project is used by organizations to build products. These adopters of {forgeName} 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.