Skip to content
Snippets Groups Projects
Commit b3cdf44c authored by Wayne Beaton's avatar Wayne Beaton
Browse files

First pass at an update to the process document.

This includes the definition of a new Progress Review to address Bug
496321 and (at least in part) Bug 534828. I've noted other changes in
the CHANGELOG file.
parent 0ce5fd43
No related branches found
No related tags found
No related merge requests found
# ChangeLog
## [Unreleased]
### Added
- (Bug 496321) The notion of a Progress Review added to augment (and in some cases, replace) Release Reviews.
- Content in the "Releases" has been reorganized.
-- The requirement that a project engage in a Release Review prior to a release has been changed to a requirement that project can only release within a year of successfully engaging in either a Progress Review or a Release Review.
### Changes
- Converted document source format to Asciidoctor.
- Removed the unnecessary statement that "Major releases continue to go through progress reviews." from the description of the Mature Phase.
- Release Reviews have been recast as a special type of Progress Review.
- The time period for votes and reviews is expressed in terms of simple "weeks" rather than "one week of generally accepted business days" which is unnecessarily complicated.
- Content in the Releases section has been reorganized so that the three exceptions are grouped followed by the discussion regarding milestones.
- (Bug 538613) Generalize "public comments" to "feedback" in section 6.3 "Reviews".
- (Bug 484587) Change the title of section 2.3.1 to "Developers", and section 4.7 to "Committers".
## [2015] - 2015-12-31
### Changes
- (Bug 376001) Make the process of retiring/removing project members explicit.
- (Bug 415620) Streamline review requirements.
- (Bug 416185) Rewrite the section on requirements to be more clear and succinct.
- (Bug 418208) Appointed members of the Architecture Council are appointed to two year renewable terms.
- (Bug 471367) Include "Freedom of Action" requirement in the EDP.
- (Bug 477238) Generalize the expected output of projects.
- (Bug 480526) Include definitions of terms required by other legal documents.
- (Bug 463850) Only one mentor required for an incubating project.
\ No newline at end of file
......@@ -6,6 +6,7 @@
:bylawsUrl: https://www.eclipse.org/org/documents/eclipse_foundation-bylaws.pdf
:ipPolicyUrl: https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
:membershipAgreementUrl: https://www.eclipse.org/org/documents/eclipse_membership_agreement.pdf
:incubationBrandingUrl: http://wiki.eclipse.org/Development_Resources/HOWTO/Conforming_Incubation_Branding
= Eclipse Development Process 2018
......@@ -56,7 +57,7 @@ The Eclipse Foundation has the responsibility to _...cultivate...an ecosystem of
Essential to the purposes of the Eclipse Foundation is the development of three inter-related communities around each project:
[#2_3_1_Committers]
==== 2.3.1 Contributors and Committers
==== 2.3.1 Developers
A thriving, diverse, and active community of developers is the key component of any Eclipse project. Ideally, this community should be an open, transparent, inclusive, and diverse community of committers and (non-committer) contributors. Attracting new contributors and committers to an open source project is time consuming and requires active recruiting, not just passive "openness". The project leadership must make reasonable efforts to encourage and nurture promising new contributors.
......@@ -201,13 +202,13 @@ Eclipse projects are managed by one or more project leads. Project leads are res
In the unlikely event that a project lead becomes disruptive to the process or ceases to contribute for an extended period, the individual may be removed by the unanimous vote of the remaining project leads (if there are at least two other project leads), or unanimous vote of the project's PMC.
[#4_7_Committers_and_Contributors]
=== 4.7 Committers and Contributors
=== 4.7 Committers
Each project has a development team, led by the project leaders. The development team is composed of committers and contributors. Contributors are individuals who contribute code, fixes, tests, documentation, or other work that is part of the project. Committers have write access to the project's resources (source code repository, bug tracking system, website, build server, downloads, etc.) and are expected to influence the project's development.
Contributors who have the trust of the project's committers can, through election, be promoted committer 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 member company or any company employing existing committers.
The election process begins with an existing committer on the same project nominating the contributor. The project's committers will vote for a period of no less than one week of standard business days. If there are at least three (3) positive votes and no negative votes within the voting period, the contributor is recommended to the project's PMC for commit privileges. If there are three (3) or fewer committers on the project, a unanimous positive vote of all committers is substituted. If the PMC approves, and the contributor signs the appropriate committer legal agreements established by the EMO (wherein, at the very least, the developer agrees to abide by the Eclipse Intellectual Property Policy), the contributor becomes a committer and is given write access to the source code for that project.
The election process begins with an existing committer on the same project nominating the contributor. The project's committers will vote for a period of no less than one week. If there are at least three (3) positive votes and no negative votes within the voting period, the contributor is recommended to the project's PMC for commit privileges. If there are three (3) or fewer committers on the project, a unanimous positive vote of all committers is substituted. If the PMC approves, and the contributor signs the appropriate committer legal agreements established by the EMO (wherein, at the very least, the developer agrees to abide by the Eclipse Intellectual Property Policy), the contributor becomes a committer and is given write access to the source code for that project.
At times, committers may become inactive for a variety of reasons. The decision making process of the project relies on active committers who respond to discussions and vote in a constructive and timely manner. The project leads are responsible for ensuring the smooth operation of the project. A committer who is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status revoked by the project leads. Unless otherwise specified, "an extended period" is defined as "no activity for more than six months".
......@@ -239,7 +240,7 @@ ____
A project may designate a subproject as a "permanent incubator". A permanent incubator is a project that is intended to perpetually remain in the link:#6_2_3_Incubation[incubation] phase. Permanent incubators are an excellent place to innovate, test new ideas, grow functionality that may one day be moved into another project, and develop new committers.
Permanent incubator projects never have releases; they cannot participate in the annual simultaneous release. Permanent incubators may have builds, and downloads. They conform to the standard incubation branding requirements and are subject to the IP due diligence rules outlined for incubating projects. Permanent incubators do not graduate.
Permanent incubator projects never have releases; they cannot participate in the annual simultaneous release. Permanent incubators may have builds, and downloads. They conform to the standard {incubationBrandingUrl}[incubation branding] requirements and are subject to the IP due diligence rules outlined for incubating projects. Permanent incubators do not graduate.
The scope of a permanent incubator project must fall within the scope of its parent project. The committer group of the permanent incubator project must overlap with that of the parent project (at least one committer from the parent project must be a committer for the incubator). Permanent incubator projects do not require Architecture Council mentors (the parent project's committers are responsible for ensuring that the incubator project conforms to the rules set forth by the Eclipse Development Process).
......@@ -307,7 +308,7 @@ Only projects that are properly identified as being in the incubation phase (inc
[#6_2_4_Mature]
==== 6.2.4 Mature Phase
The project team has demonstrated that they are an open-source project with an open and transparent process; an actively involved and growing community; and Eclipse-quality technology. The project is now a mature member of the Eclipse community. Major releases continue to go through release reviews.
The project team has demonstrated that they are an open-source project with an open and transparent process; an actively involved and growing community; and Eclipse-quality technology. The project is now a mature member of the Eclipse community.
[#6_2_5_Top-Level]
==== 6.2.5 [Reserved]
......@@ -333,11 +334,11 @@ All reviews have the same general process:
3. A project representative presents the review documentation to the project's PMC along with a request to proceed with the review and for approval of the corresponding documentation.
4. Upon receiving approval from the PMC, a project representative makes a request to the EMO to schedule the review.
5. The EMO announces the review schedule and makes the documentation available to the membership-at-large.
6. The EMO approves or fails the review based on the public comments, the scope of the project, and the purposes of the Eclipse Foundation as defined in the bylaws.
6. The EMO approves or fails the review based on the feedback, the scope of the project, and the purposes of the Eclipse Foundation as defined in the bylaws.
The review documentation requirements, and criteria for the successful completion of each type of review will be documented by the EMO. PMCs may establish additional success criteria.
The review period is open for no less than one week and usually no more than two weeks of generally accepted business days. The review ends with the announcement of the results in the defined review communication channel.
The review period is open for no less than one week and usually no more than two weeks. The review ends with the announcement of the results in the defined review communication channel.
If any member believes that the EMO has acted incorrectly in approving or failing a review may appeal to the board of directors to review the EMO's decision.
......@@ -360,18 +361,20 @@ The graduation review confirms that the project is/has:
* Operating fully in the open following the principles and purposes of Eclipse.
* A credit to Eclipse and is functioning well within the larger Eclipse community.
A graduation review is generally link:#6_3_9_Combining_Reviews[combined] with a release review.
A graduation review is generally link:#6_3_9_Combining_Reviews[combined] with a progress or release review.
[#6_3_3_Release_Review]
==== 6.3.3 Release Review
The purposes of a release review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the principles and purposes of Eclipse.
A release review is a type of link:#6_3_5_Progress_Review[progress review] that is aligned directly with a specific release. A release review must be concluded successfully before the corresponding link:#6_4_Releases[release] is announced to the community.
[#6_3_4_Promotion_Review]
==== 6.3.4 [Reserved]
[#6_3_5_Continuation_Review]
==== 6.3.5 [Reserved]
[#6_3_5_Progress_Review]
==== 6.3.5 Progress Review
The purposes of a progress review are: to summarize the accomplishments of the project, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the principles and purposes of Eclipse.
[#6_3_6_Termination_Review]
==== 6.3.6 Termination Review
......@@ -393,9 +396,9 @@ The purpose of a restructuring review is to notify the community of significant
[#6_3_9_Combining_Reviews]
==== 6.3.9 Combining Reviews
Reviews can be combined at the discretion of the PMC and EMO. Multiple projects may participate in a single review. Similarly, multiple review types can be engaged in simultaneously. A parent project may, for example, engage in an aggregated release review involving itself and some or all of its child projects; a consolidated restructuring review may move the code for several projects; or a release review may be combined with a graduation review. When multiple reviews are combined, the review documentation must explicitly state all of the projects and types of reviews involved, and include the required information about each.
Reviews can be combined at the discretion of the PMC and EMO. Multiple projects may participate in a single review. Similarly, multiple review types can be engaged in simultaneously. A parent project may, for example, engage in an aggregated progress review involving itself and some or all of its child projects; a consolidated restructuring review may move the code for several projects; or a progress review may be combined with a graduation review. When multiple reviews are combined, the review documentation must explicitly state all of the projects and types of reviews involved, and include the required information about each.
It should be noted that the purpose of combining reviews is to better serve the community, rather than to reduce effort on the part of the project (though it is fortunate when it does both). Combining a release and graduation review, or aggregating a release review of a project and several of its child projects generally makes sense. Combining release reviews for multiple unrelated projects most likely does not.
It should be noted that the purpose of combining reviews is to better serve the community, rather than to reduce effort on the part of the project (though it is fortunate when it does both). Combining a progress and graduation review, or aggregating a progress review of a project and several of its child projects generally makes sense. Combining progress reviews for multiple unrelated projects most likely does not.
[#6_4_Releases]
=== 6.4 Releases
......@@ -406,23 +409,21 @@ _(Most of this section is borrowed and paraphrased from the excellent http://www
Releases are, by definition, anything that is distributed outside of the committers of a project. If users are being directed to download a build, then that build has been released (modulo the exceptions below). All projects and committers must obey the Eclipse Foundation requirements on approving any release.
A project can make official releases for one calendar year following a successful link:#6_3_5_Progress_Review[progress review] or link:#6_3_3_Release_Review[release review]. The project leadership chain may--at its discretion--require that the project engage in additional reviews (e.g. a progress or release review) prior to issuing a release.
_(Exception 1: nightly and integration builds)_ During the process of developing software and preparing a release, various nightly and integration builds are made available to the developer community for testing purposes. Do not include any links on the project website, blogs, wikis, etc. that might encourage non-early-adopters to download and use nightly builds, release candidates, or any other similar package (links aimed at early-adopters and the project's developers are both permitted and encouraged). The only people who are supposed to know about such packages are the people following the developer mailing list and thus are aware of the limitations of such builds.
_(Exception 2: milestone and release candidate builds)_ Projects are encouraged to use an agile development process including regular milestones (for example, six week milestones). Milestones and release candidates are "almost releases" intended for adoption and testing by early adopters. Projects are allowed to have links on the project website, blogs, wikis, etc. to encourage these outside-the-committer-circle early adopters to download and test the milestones and release candidates, but such communications must include caveats explaining that these are not official releases.
_(Exception 3: bug fix releases with no new features)_ Bug fix releases (x.y.z, e.g., 2.3.1) with no significant changes or additions over the base release (e.g., 2.3) are allowed to be released without an additional review.
* Milestones are to be labeled `x.yMz`, e.g., 2.3M1 (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version 2.3), etc.
* Release candidates are to be labeled `x.yRCz`, e.g., 2.3RC1 (release candidate 1 towards version 2.3).
* Official releases are the only downloads allowed to be labeled with `x.y`, e.g., 0.5, 1.0, 2.3, etc.
All official releases must have a successful link:#6_3_3_Release_Review[release review] before being made available for download.
_(Exception 3: bug fix releases with no new features)_ Bug fix releases (x.y.z, e.g., 2.3.1) with no new features over the base release (e.g., 2.3) are allowed to be released without an additional release review. If a bug fix release contains new features, then the project must have a full release review.
Under no circumstances are builds and milestones to be used as a substitute for doing proper official releases. Proper release management and reviews is a key aspect of Eclipse quality.
See http://wiki.eclipse.org/Development_Resources/HOWTO/Conforming_Incubation_Branding[Incubation Branding] for more information.
Releases for projects in the incubation phase must be labeled to indicate the incubation status of the project.
Releases for projects in the incubation phase must be labeled to indicate the incubation status of the project. See {incubationBrandingUrl}[Incubation Branding] for more information.
[#6_5_Grievance_Handling]
=== 6.5 Grievance Handling
......@@ -456,3 +457,5 @@ The EMO is further responsible for ensuring that all plans, documents and report
=== 8.1 Revision 2.8
This document was approved by the Eclipse Foundation Board of Directors in its meeting on November 2/2015. It takes effect (replacing all previous versions) on December 2/2015.
include::history.adoc[]
\ No newline at end of file
[#8_2_History]
==== 8.2 History
Changes made in this document:
\ No newline at end of file
Changes made in this document:
include::CHANGELOG[leveloffset=+4]
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment