| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title></title> |
| </head> |
| <body> |
| <h1>Eclipse Development Process</h1> |
| <div class="homeitem3col"> |
| <h2>Contents</h2> |
| <div id="toc"> |
| <ul> |
| <li>1 Purpose</li> |
| <li>2 Principles |
| <ul> |
| <li>2.1 Open Source Rules of Engagement</li> |
| <li>2.2 Eclipse Ecosystem</li> |
| <li>2.3 Three Communities</li> |
| <li>2.4 Clear, Concise, and Evolving</li> |
| </ul> |
| </li> |
| <li>3 Requirements |
| <ul> |
| <li>3.1 Requirements and Guidelines</li> |
| </ul> |
| </li> |
| <li>4 Project Structure and Organization |
| <ul> |
| <li>4.1 Committers</li> |
| <li>4.2 Code and Releases</li> |
| <li>4.3 IP Records</li> |
| <li>4.4 Community Awareness</li> |
| <li>4.5 Scope</li> |
| <li>4.6 Leaders |
| <ul> |
| <li>4.6.1 Project Management Committee (PMC)</li> |
| <li>4.6.2 Project Lead(s)</li> |
| </ul> |
| </li> |
| <li>4.7 Committers and Contributors</li> |
| <li>4.8 Councils</li> |
| <li>4.9 Incubator Projects</li> |
| </ul> |
| </li> |
| <li>5 <strike>Roadmap Process</li></strike> <font color="green">[Reserved]</li></font> |
| <li>6 Development Process |
| <ul> |
| <li>6.1 Mentors</li> |
| <li>6.2 Project Lifecycle</li> |
| <li>6.2.1 Pre-proposal</li> |
| <li>6.2.2 Proposal</li> |
| <li>6.2.3 Incubation</li> |
| <li>6.2.4 Mature</li> |
| <li>6.2.5 Top-Level</li> |
| <li>6.2.6 Archived</li> |
| <li>6.3 Reviews |
| <ul> |
| <li>6.3.1 Creation Review</li> |
| <li>6.3.2 Graduation Review</li> |
| <li>6.3.3 Release Review</li> |
| <li>6.3.4 Promotion Review</li> |
| <li>6.3.5 Continuation Review</li> |
| <li>6.3.6 Termination Review</li> |
| <li>6.3.7 Move Review</li> |
| <li>6.3.8 Restructuring Review</li> |
| <li>6.3.9 Combining Reviews</li> |
| </ul> |
| </li> |
| <li>6.4 Releases</li> |
| <li>6.5 Grievance Handling</li> |
| </ul> |
| </li> |
| <li>7 Precedence</li> |
| <li>8 Revisions |
| <ul> |
| <li>8.1 Revision 2.4</li> |
| </ul> |
| </li> |
| </ul> |
| </div> |
| </div> |
| <h2>1. Purpose</h2> |
| <p>This document describes the Development Process for the Eclipse |
| Foundation. In particular, it describes how the Membership at Large, |
| the Board of Directors, other constituents of the Ecosystem, and the |
| Eclipse Management Organization (EMO) lead, influence, and collaborate |
| with Eclipse Projects to achieve these Eclipse purposes:</p> |
| <blockquote><em>The Eclipse technology is a vendor-neutral, open |
| development platform supplying frameworks and exemplary, extensible |
| tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary in |
| that they verify the utility of the Eclipse frameworks, illustrate the |
| appropriate use of those frameworks, and support the development and |
| maintenance of the Eclipse Platform itself; Eclipse Platform tools are |
| extensible in that their functionality is accessible via documented |
| programmatic interfaces. The purpose of Eclipse Foundation Inc., is to |
| advance the creation, evolution, promotion, and support of the Eclipse |
| Platform and to cultivate both an open source community and an |
| ecosystem of complementary products, capabilities, and |
| services.</em></blockquote> |
| <div class="postit"> |
| <p>Explanatory comments, guidelines, and checklists - as well as |
| additional requirements added by the EMO per section 3 - are noted in |
| yellow boxes.</p> |
| </div> |
| <p>This document has <strike>five</strike> <font color="green">the following</font> sections:</p> |
| <ul> |
| <li><em>Principles</em> outlines the basic principles upon which the |
| development process is based.</li> |
| <li><em>Requirements</em> describes the requirements that the Eclipse |
| community has for its development process.</li> |
| <li><em>Structure and Organization</em> specifies the structure and |
| organization of the projects and project community at Eclipse.</li> |
| <strike><li><em>Roadmap Process</em> describes the manner by which the EMO will |
| work with the projects to create the annual Eclipse Roadmap.</li></strike> |
| <li><em>Development Process</em> outlines the lifecycle and processes |
| required of all Eclipse projects.</li> |
| </ul> |
| <h2>2. Principles</h2> |
| <p>The following describes the guiding principles used in developing |
| this Development Process.</p> |
| <h3>2.1 Open Source Rules of Engagement</h3> |
| <ul> |
| <li><b>Open</b> - Eclipse 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.</li> |
| <li><b>Transparent</b> - Project discussions, minutes, deliberations, |
| project plans, plans for new features, and other artifacts are open, |
| public, and easily accessible.</li> |
| <li><b>Meritocracy</b> - Eclipse is a meritocracy. The more you |
| contribute the more responsibility you will earn. Leadership roles in |
| Eclipse are also merit-based and earned by peer acclaim.</li> |
| </ul> |
| <h3>2.2 Eclipse Ecosystem</h3> |
| <p>Eclipse as a brand is the sum of its parts (all of the Projects), |
| and Projects should strive for the highest possible quality in |
| extensible frameworks, exemplary tools, transparent processes, and |
| project openness.</p> |
| <p>The Eclipse Foundation has the responsibility to |
| <em>...cultivate...an ecosystem of complementary products, |
| capabilities, and services...</em>. It is therefore a key principle |
| that the Eclipse Development Process ensures that the projects are |
| managed for the benefit of both the open source community and the |
| ecosystem members. To this end, all Eclipse projects are required |
| to:</p> |
| <ul> |
| <li>communicate their project plans and plans for new features (major |
| and minor) in a timely, open and transparent manner;</li> |
| <li>create platform quality frameworks capable of supporting the |
| building of commercial grade products on top of <strike>them;</li></strike> <font color="green">them; and</li></font> |
| <li>ship extensible, exemplary tools which help enable a broad |
| community of <strike>users; and</li> |
| <li>participate in the annual Roadmap process to ensure maximum |
| transparency and bi-directional communication with the ecosystem.</li></strike> <font color="green">users</li></font> |
| </ul> |
| <h3>2.3 Three Communities</h3> |
| <p>Essential to the Purposes of the Eclipse Foundation is the |
| development of three inter-related communities around each Project:</p> |
| <ul> |
| <li><b>Contributors</b> and <b>Committers</b> - 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. |
| <ul> |
| <li>Projects must have diversity goals to ensure diversity of thought |
| and avoid relying on any one company or organization. At the same time, |
| we acknowledge that enforcing a particular diversity metric is a poor |
| way to achieve these goals; rather we expect the project leadership to |
| help the diversity evolve organically.</li> |
| <li>Diversity is a means to an end, not an end in itself, thus |
| diversity goals will differ by project based on the other |
| accomplishments of the project(s).</li> |
| <li>Projects are required to explain their diversity efforts and |
| accomplishments during Reviews.</li> |
| </ul> |
| </li> |
| <li><b>Users</b> - an active and engaged user community is |
| proof-positive that the Project's exemplary tools are useful and |
| needed. Furthermore, a large user community is one of the key factors |
| in creating a viable ecosystem around an Eclipse project, thus |
| encouraging additional open source and commercial organizations to |
| participate. Like all good things, a user community takes time and |
| effort to bring to fruition, but once established is typically |
| self-sustaining.</li> |
| <li><b>Adopters</b> - an active and engaged adopter/plug-in developer |
| community is the only way to prove that an Eclipse project is providing |
| extensible frameworks and extensible tools accessible via documented |
| APIs. Reuse of the frameworks within the companies that are |
| contributing to the project is necessary, but not sufficient to |
| demonstrate an adopter community. Again, creating, encouraging, and |
| nurturing an adopter community outside of the Project's developers |
| takes time, energy, and creativity by the Project Leadership, but is |
| essential to the Project's long-term open source success.</li> |
| </ul> |
| <p>The Eclipse community considers the absence of any one or more of |
| these communities as proof that the Project is not sufficiently open, |
| transparent, and inviting, and/or that it has emphasized tools at the |
| expense of extensible frameworks or vice versa.</p> |
| <h3>2.4 Clear, Concise, and Evolving</h3> |
| <p>It is an explicit goal of the Development Process to be as clear and |
| concise as possible so as to help the Project teams navigate the |
| complexities, avoid the pitfalls, and become successful as quickly as |
| possible.</p> |
| <p>This document imposes requirements and constraints on the operation |
| of the Projects, and it does so on behalf of the larger Eclipse |
| community. It is an explicit goal of the Development Process to provide |
| as much freedom and autonomy to the Projects as possible while ensuring |
| the collective qualities benefit the entire Eclipse community.</p> |
| <p>Similarly, this document should not place undue constraints on the |
| EMO or the Board that prevent them from governing the process as |
| necessary. We cannot foresee all circumstances and as such should be |
| cautious of being overly prescriptive and/or requiring certain fixed |
| metrics.</p> |
| <p>The frameworks, tools, projects, processes, community, and even the |
| definition of Quality continues to, and will continue to, evolve. |
| Creating rules or processes that force a static snapshot of any of |
| these is detrimental to the health, growth, and ecosystem impact of |
| Eclipse.</p> |
| <p>Part of the strength of this document is in what it does not say, |
| and thus opens for community definition through convention, guidelines, |
| and public consultation. A document with too much structure becomes too |
| rigid and prevents the kind of innovation and change we desire for |
| Eclipse. In areas where this document is vague, we expect the Projects |
| and Members to engage the community-at-large to clarify the current |
| norms and expectations.</p> |
| <h2>3. Requirements</h2> |
| <p>This document and any additional criteria as established by the EMO |
| contains requirements, recommendations, and suggestions.</p> |
| <strike><p><span style= |
| "margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times;"> |
| R</span><b>Required</b></strike> |
| <font color="green"><p><b>Required</b></font> - Certain responsibilities and behaviors are |
| required of participants in Eclipse open source projects. Projects that |
| fail to perform the required behaviors will be terminated by the EMO. |
| In keeping with the Guiding Principles, the number of requirements must |
| be kept to an absolute minimum.</p> |
| <strike><p><span style= |
| "margin-right:6px; margin-top:5px; float:left; color:ivory; background:#00CC99; border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; padding-right:2px; font-family:times;"> |
| G</span><b>Guideline</b></strike> |
| <font color="green"><p><b>Guideline</b></font> - Other responsibilities and behaviors are |
| recommended best practices. Collectively, we have learned that Projects |
| are more likely to be successful if the team members and leaders follow |
| these recommendations. Projects are strongly encouraged to follow these |
| recommendations, but will not be penalized by this Process if they do |
| not.</p> |
| <h3>3.1 Requirements and Guidelines</h3> |
| <p>This document is entirely composed of requirements. In addition to |
| the requirements specified in this Development Process, the EMO is |
| instructed to clarify, expand, and extend this Process by creating a |
| set of Eclipse Project Development Guidelines to advance the creation, |
| evolution, promotion, and support of the Eclipse Platform and to |
| cultivate both an open source community and an ecosystem of |
| complementary products and services.</p> |
| <p>The EMO is not permitted to override or ignore the requirements |
| listed in this document without the express written endorsement of the |
| Board of Directors.</p> |
| <h2>4. Project Structure and Organization</h2> |
| <p>A <b>Project</b> is the main operational unit at Eclipse. |
| Specifically, all open source software development at Eclipse occurs |
| within the context of a Project. Projects have leaders, developers, |
| code, builds, downloads, websites, and more. Projects are more than |
| just the sum of their many parts, they are the means by which open |
| source work is organized when presented to the communities of |
| developers, adopters, and users. Projects provide structure that helps |
| developers expose their hard work to a broad audience of consumers.</p> |
| <p>Eclipse Projects are organized hierarchically. A special type of |
| Project, <b>Top-Level Projects</b>, sit at the top of the hierarchy. |
| Each Top-Level Project contains one or more Projects. Each Project may |
| itself contain zero or more Projects. A <strike>project</strike> <font color="green">Project</font> that has one or more |
| Projects is said to be the "parent" of those Projects. A Project that |
| has a parent is oftentimes referred to as a <b>Sub-Project</b>. The |
| term Project refers to either a Top-Level Project or a Sub-Project. |
| Projects may be referred to as Sub-Projects or Components, but the |
| choice of common name does not change the characteristics of the |
| Project.</p> |
| <p>The <b>descendants</b> of a Project are the Project itself and |
| transitive closure of its child Projects. The <b>top parent</b> of a |
| Project is the Top-Level Project at the top of the hierarchy.</p> |
| <p>Projects are the unit entity for:</p> |
| <ul> |
| <li>Committers</li> |
| <li>Code and Releases</li> |
| <li>IP Records</li> |
| <li>Community Awareness</li> |
| </ul> |
| <p>As defined by the Eclipse Bylaws - Article VII, the <b>Eclipse |
| Management Organization (EMO)</b> consists of the Foundation staff and |
| the Councils. The term <b>EMO(ED)</b>, when discussing an approval |
| process, refers to the subset of the EMO consisting of the Executive |
| Director and whomever he or she may delegate that specific approval |
| authority to.</p> |
| <h3>4.1 Committers</h3> |
| <p>Each project has exactly one set of committers. Each Project's set |
| of Committers is distinct from that of any other Project, including |
| Sub-Projects or parent Projects. All Project Committers have equal |
| rights and responsibilities within the Project. Partitioning of |
| responsibility within a Project is managed using social convention. A |
| Project may, for example, divide itself into logical partitions of |
| functionality; it is social convention that prevents Committers from |
| one logical partition from doing inappropriate work in another. If |
| finer-grained management of committer responsibilities is required, a |
| project should consider partitioning (via a Restructuring Review) into |
| two or more Sub-Projects.</p> |
| <p>The Committers of a project have the exclusive right to elect new |
| Committers to their Project–no other group, including a parent |
| Project, can force a Project to accept a new Committer.</p> |
| <p>There is no roll-up of <strike>committers:</strike> <font color="green">Committers:</font> the set of <strike>committers</strike> <font color="green">Committers</font> on a |
| <strike>project</strike> |
| <font color="green">Project</font> is exactly that set of people who have been explicitly elected |
| into that role for the project (i.e. being a committer on a sub-project |
| does not give you any automatic rights on the "parent" project).</p> |
| <p>In practical terms, each Project has a single Unix group of its |
| Committers that provides write-access to the Project's resources. |
| Pictorially below, we see that a Project, in addition to the various |
| resources and Committers it has, can also have zero or more |
| Sub-Projects. Each of these Sub-Projects has its own distinct set of |
| Committers and resources.</p> |
| <img src="images/subprojects-resources-291x300.png"> |
| <h3>4.2 Code and Releases</h3> |
| <p>Each Project owns and maintains a collection of resources.</p> |
| <p>Resources may include source code, a project website, space on the |
| downloads server, access to build resources, and other services |
| provided by the Eclipse Foundation infrastructure. The exact |
| infrastructure provided by the Eclipse Foundation varies over time and |
| is defined outside this process document.</p> |
| <p>A project is not strictly required to make use of all the resources |
| made available; a project might, for example, opt to <em>not</em> |
| maintain a source code repository. Such a Project might operate as an |
| organizational unit, or container, for several Sub-Projects. Similarly, |
| a Project might opt to provide a consolidated website, build and/or |
| download site for its Sub-Projects (the Sub-Projects would then not |
| require those resources for themselves).</p> |
| <p>Each Project has a single Bugzilla component for its bugs.</p> |
| <p>Any Project in the Mature Phase may make a <b>Release</b>. A Project |
| in the Incubation Phase with two Mentors may make a pre-1.0 |
| <b>Release</b>. A Release may include the code from any subset of the |
| Project's descendants.</p> |
| <h3>4.3 IP Records</h3> |
| <p>A Project at any level may receive IP clearance for contributions |
| and third-party libraries. IP approval will often include the same |
| approval for all descendant Projects. However, IP clearance will only |
| be granted at the most appropriate technical level.</p> |
| <h3>4.4 Community Awareness</h3> |
| <p>Projects are the level of communication with the larger Eclipse |
| community and ecosystem. Projects may either have their own |
| communications (website, mailing lists, forums/newsgroups, etc) or they |
| may be part of a parent Project's communications (website, mailing |
| list, forums/newsgroups, etc). In either case, the Project is required |
| to maintain an open and public communication channel with the Eclipse |
| community including, but not limited to, project plans, schedules, |
| design discussions, and so on.</p> |
| <p>All Projects must make the communication channels easy to find. |
| Projects are further required to make the separate communication |
| channels of their child Projects (if any) easy to find.</p> |
| <p>Any Project in the Incubation Phase must correctly identify its |
| website and Releases. A Project with at least one descendant Project in |
| Incubation Phase must correctly annotate its own website so as to |
| notify the Eclipse community that incubating Projects exist in its |
| hierarchy. Any Release containing code from an Incubation Phase project |
| must be correctly labeled, i.e., the Incubation Phase is viral and |
| expands to cover all Releases in which it is included.</p> |
| <h3>4.5 Scope</h3> |
| <p>Each Top-Level Project has a <b>Charter</b> which describes the |
| purpose, <b>Scope</b>, and operational rules for the Top-Level Project. |
| The Charter should refer to, and describe any refinements to, the |
| provisions of this Development Process. The Board approves the Charter |
| of each Top-Level Project.</p> |
| <p>Sub-Projects do not have separate Charters; Sub-Projects operate |
| under the Charter of their parent Top-Level Project.</p> |
| <p>All Projects have a defined <b>Scope</b> and all initiatives within |
| that Project are required to reside within that Scope. Initiatives and |
| code that is found to be outside the Scope of a Project may result in |
| the termination of the Project. The Scope of Top-Level Projects is part |
| of the Charter, as approved by the Board of Directors of the Eclipse |
| Foundation.</p> |
| <p>The Scope of a Sub-Project is defined by the initial project |
| proposal as reviewed and approved by the <b>Project Management |
| Committee (PMC)</b> (as further defined below) of the Project's |
| Project's top parent and by the EMO. A Project's Scope must be a subset |
| of its parent's Scope.</p> |
| <h3>4.6 Leaders</h3> |
| <p>There are two different types of Project leadership at Eclipse: The |
| Project Management Committee (PMC) and Project Leads. Both forms of |
| leadership are required to:</p> |
| <ul> |
| <li>ensure that their Project is operating effectively by guiding the |
| overall direction and by removing obstacles, solving problems, and |
| resolving conflicts;</li> |
| <li>operate using open source rules of engagement: meritocracy, |
| transparency, and open participation; and</li> |
| <li>ensure that the Project and its Sub-Projects (if any) conform to |
| the Eclipse Foundation IP Policy and Procedures.</li> |
| </ul> |
| <p>The leadership for a Project is composed of the Project's Project |
| Lead(s), the leadership of the parent Project (if any) and the PMC |
| Leads and PMC Members for the Top-Level Project.</p> |
| <h4>4.6.1 Project Management Committee (PMC)</h4> |
| <p>Top-level projects are managed by a Project Management Committee |
| (PMC). A PMC has one or more PMC Leads and zero or more PMC Members. |
| Together the PMC provides oversight and overall leadership for the |
| projects that fall under their top-level project. The PMC as a whole, |
| and the PMC Leads in particular, are ultimately responsible for |
| ensuring that the Eclipse Development Process is understood and |
| followed by their projects. The PMC is additionally responsible for |
| maintaining the top-level project's charter.</p> |
| <p>PMC Leads are approved by the Board; PMC members are elected by the |
| existing PMC Leads and Members, and approved by the EMO(ED).</p> |
| <h4>4.6.2 Project Lead</h4> |
| <p>Eclipse Projects are managed by one or more Project Leads. Project |
| Leads are responsible for ensuring that their Project's Committers are |
| following the Eclipse Development Process, and that the project is |
| engaging in the right sorts of activities to develop vibrant |
| communities of users, adopters, and contributors. The initial project |
| leadership is appointed and approved in the creation review. |
| Subsequently, additional Project Leads must be elected by the project's |
| Committers and approved by the Project's PMC and the EMO(ED).</p> |
| <p>In the unlikely event that a member of the Project leadership |
| 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 Project Leads (if there are at least two other Project |
| Leads), or unanimous vote of the Project's PMC.</p> |
| <p>In exceptional situations, such as projects with zero active |
| committers or projects with disruptive Committers and 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.</p> |
| <h3>4.7 Committers and Contributors</h3> |
| <p>Each Project has a <b>Development Team</b>, led by the Project |
| Leaders. The Development Team is composed of <b>Committers</b> and |
| <b>Contributors</b>. <b>Contributors</b> are individuals who contribute |
| code, fixes, tests, documentation, or other work that is part of the |
| Project. <b>Committers</b> 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.</p> |
| <div class="postit">See guidelines and checklists for electing a new |
| committer.</div> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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 Leaders 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 Leaders. (Unless |
| otherwise specified, "an extended period" is defined as "no activity |
| for more than six months".)</p> |
| <p>Active participation in the user forums/newsgroups and the |
| appropriate developer mailing lists is a responsibility of all |
| Committers, and is critical to the success of the Project. Committers |
| are required to monitor and contribute to the user |
| forums/newsgroups.</p> |
| <p>Committers are required to monitor the mailing lists associated with |
| the Project. This is a condition of being granted commit rights to the |
| Project. It is mandatory because committers must participate in votes |
| (which in some cases require a certain minimum number of votes) and |
| must respond to the mailing list in a timely fashion in order to |
| facilitate the smooth operation of the Project. When a Committer is |
| granted commit rights they will be added to the appropriate mailing |
| lists. A Committer must not be unsubscribed from a developer mailing |
| list unless their associated commit privileges are also revoked.</p> |
| <p>Committers are required to track, participate in, and vote on, |
| relevant discussions in their associated Projects and components. There |
| are three voting responses: +1 (yes), -1 (no, or veto), and 0 |
| (abstain).</p> |
| <p>Committers are responsible for proactively reporting problems in the |
| bug tracking system, and annotating problem reports with status |
| information, explanations, clarifications, or requests for more |
| information from the submitter. Committers are responsible for updating |
| problem reports when they have done work related to the problem.</p> |
| <p>Committer, PMC Lead, Project Lead, and Council Representative(s) are |
| roles; an individual may take on more than one of these roles |
| simultaneously.</p> |
| <h3>4.8 Councils</h3> |
| <p>The <strike>three</strike> Councils defined in Bylaws section VII are comprised of |
| Strategic members and PMC representatives. The <strike>three</strike> Councils help guide the |
| Projects as follows:</p> |
| <ul> |
| <li>The <strike><b>Requirements Council</b> is primarily responsible for the |
| Eclipse Roadmap. There will always be more requirements than there are |
| resources to satisfy them, thus the Requirements Council gathers, |
| reviews, and categorizes all of these incoming requirements - from the |
| entire Eclipse ecosystem - and proposes a coherent set of <b>Themes and |
| Priorities</b>.</li> |
| <li>The</strike> <b>Planning Council</b> is responsible for establishing a |
| coordinated Simultaneous Release (a.k.a, "the release <strike>train") that |
| supports the Themes and Priorities in the Roadmap.</strike> <font color="green">train").</font> The |
| Planning Council is <font color="green">further</font> responsible for cross-project planning, |
| architectural issues, user interface conflicts, and all other |
| coordination and integration issues. The Planning Council discharges |
| its responsibility via collaborative evaluation, prioritization, and |
| compromise.</li> |
| <li> |
| <div class="postit">See guidelines and checklists for the Architecture |
| Council.</div> |
| The <b>Architecture Council</b> is responsible for <strike>the development, |
| articulation,</strike> <font color="green">(i) monitoring, |
| guiding,</font> and <strike>maintenance of</strike> <font color="green">influencing</font> the <strike>Eclipse Platform Architecture</strike> <font color="green">software architectures used by Projects, |
| (ii) new project mentoring,</font> and |
| <strike>ensuring the Principles of</strike> <font color="green">(iii) maintaining and revising</font> the |
| <font color="green">Eclipse</font> Development <strike>Process through mentorship.</strike> <font color="green">Process.</font> Membership in the Architecture Council is |
| per the Bylaws through Strategic Membership, PMCs, and by appointment. |
| The Architecture Council will, at least annually, recommend to the |
| EMO(ED), Eclipse Members who have sufficient experience, wisdom, and |
| time to be appointed to the Architecture Council and serve as Mentors. |
| Election as a Mentor is a highly visible confirmation of the Eclipse |
| community's respect for the candidate's technical vision, good |
| judgement, software development skills, past and future contributions |
| to Eclipse. It is a role that should be neither given nor taken |
| lightly. Appointed members of the Architecture Council are appointed to |
| two year renewable terms.</li> |
| </ul> |
| <h3>4.9 Incubator Projects</h3> |
| <p>A Project may designate a Sub-Project as an "Incubator". An |
| Incubator is a Project that is intended to perpetually remain in the |
| Incubation phase. 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.</p> |
| <p>Incubator Projects never have releases; they do not require yearly |
| continuation reviews and they are not part of the annual release train. |
| 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. Incubators do not |
| graduate.</p> |
| <p>The scope of an Incubator Project must fall within the scope of its |
| parent project. The committer group of the 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). Incubator |
| projects do not require Architecture Council mentors (the parent |
| project's committers are responsible for ensuring that the Incubator |
| project conform to the rules set forth by the Eclipse Development |
| Process).</p> |
| <p>An Incubator project should designated as such by including the word |
| "Incubator" in its name (e.g. "Eclipse Incubator"). To do otherwise is |
| considered exceptional and requires approval from the PMC and |
| EMO(ED).</p> |
| <p>Only Top-Level Projects and Projects in the Mature phase may create |
| an Incubator. Incubators are created via a Creation Review. |
| Alternatively, an Incubator can be created as part of a Graduation, |
| Promotion, or Restructuring <strike>Review.</p></strike> <font color="green">Review. A proposal is not required to |
| create an Incubator project.</p></font> |
| <h2>5. <strike>Roadmap</strike> <font color="green">[Reserved]</h2> |
| <h2>6. Development</font> Process</h2> |
| <strike><p>The Roadmap describes the collective Eclipse</strike> |
| <font color="green"><p>Projects must work within their Scope.</font> Projects <strike>future |
| directions and consists of two parts:</p> |
| <ol> |
| <li><b>Themes and Priorities</b> from the Requirements Council</li> |
| <li><b>Project Plans</b> from Projects</li> |
| </ol> |
| <p>The Roadmap</strike> <font color="green">that desire to |
| expand beyond their current Scope</font> must <strike>be consistent with the Purposes</strike> <font color="green">seek an enlargement of their |
| Scope using a public Review</font> as described <strike>in |
| Bylaws section 1.1. It is developed using</strike> <font color="green">below. Further, projects must |
| fit within</font> the <strike>prescribed roadmap |
| process.</p> |
| <p>The Roadmap is prepared</strike> <font color="green">scope defined</font> by <strike>the Councils</strike> <font color="green">their containing projects</font> and <strike>approved by the Board |
| annually. A proposed Roadmap or Roadmap update is disseminated to</strike> the |
| <strike>Membership at Large for comment and feedback</strike> <font color="green">scope |
| defined</font> in <strike>advance</strike> <font color="green">the charter</font> of <strike>its |
| adoption. This dissemination and all discussion and debate around</strike> <font color="green">their Top-Level Project.</p> |
| <p>All projects are required to report their status at least quarterly |
| using</font> the |
| <strike>Roadmap</strike> <font color="green">EMO defined status reporting procedures.</p> |
| <p>Projects</font> must <strike>be held in an open and transparent public forum, such as |
| mailing lists or newsgroups.</p> |
| <p>Prior to any Board vote to approve a Roadmap or Roadmap update, |
| every Member has the right to communicate concerns and objections to |
| the Board.</p> |
| <p>The process of producing or updating the Roadmap is expected to be |
| iterative. An initial set of Themes and Priorities may be infeasible to |
| implement in the desired timeframe; subsequent consideration may reveal |
| new implementation alternatives or critical requirements that alter the |
| team's perspective on priorities. The EMO orchestrates interaction |
| among and within the Councils to drive the Roadmap to convergence.</p> |
| <p>This Development Process, the EMO, the Councils, and the Projects |
| all acknowledge that the success of the Eclipse ecosystem is dependent |
| on a balanced set of requirements and implementations. A Roadmap that |
| provides too large a burden on the Projects will be rejected and |
| ignored; similarly, a Roadmap that provides no predictable Project |
| plans will be unhelpful to the business and technical plans being |
| created by the ecosystem. A careful balance of demands and commitments |
| is essential to the ongoing success of the Eclipse Projects, |
| frameworks, and ecosystem.</p> |
| <p>The Project Leadership is expected to ensure that their Project |
| Plans are consistent with the Roadmap, and that all plans, technical |
| documents and reports are publicly available. To meet this requirement, |
| each Project is required to create a transparently available Project |
| Plan in an EMO-defined file format that meets the following |
| criteria:</p> |
| <ol> |
| <li>Enumerates the areas of change in the frameworks and tools for each |
| proposed Release</li> |
| <li>Consistent with and categorized in terms of the themes and |
| priorities of the Roadmap</li> |
| <li>Identifies and accommodates cross-project dependencies</li> |
| <li>Addresses requirements critical to the Ecosystem and/or the |
| Membership at Large</li> |
| <li>Advances the Project in functionality, quality, and |
| performance</li> |
| </ol> |
| <p>A Project may incrementally revise their Project Plan to deliver |
| additional tasks provided that:</p> |
| <ol> |
| <li>the approved Roadmap is not put in jeopardy; and</li> |
| <li>the work is consistent with the Project Plan criteria (as described |
| above)</li> |
| </ol> |
| <p>A project may produce an aggregate plan for itself and its |
| descendants. In this case descendents would share their ancestor's |
| plan.</p> |
| <h2>6. Development Process</h2> |
| <p>All Eclipse Projects, and hence all Project Proposals, must be |
| consistent with the Purposes and the then-current Roadmap.</p> |
| <p>Projects must work within their Scope. Projects that desire to |
| expand beyond their current Scope must seek an enlargement of their |
| Scope using a public Review as described below.</p> |
| <p>All projects are required to report their status at least quarterly |
| using the EMO defined status reporting procedures.</p> |
| <p>Projects must provide advanced notification of upcoming features</strike> <font color="green">provide advanced notification of upcoming features</font> and |
| frameworks via their Project Plan.</p> |
| <h3>6.1 Mentors</h3> |
| <p>New Proposals that intend to do a Release are required to have at |
| least two <b>Mentors</b>. New Proposals that will only Release code as |
| part of a parent Project's Release are not required to have Mentors. |
| Mentors must be members of the Architecture Council. The Mentors |
| (including name, affiliation, and current Eclipse projects/roles) must |
| be listed in the Proposal. Mentors are required to monitor and advise |
| the new Project during its Incubation Phase, but are released from that |
| duty once the Project graduates to the Mature Phase.</p> |
| <h3>6.2 Project Lifecycle</h3> |
| <img src="/projects/images/Development-process-small.gif" align= |
| "right"> |
| <p>Projects go through six distinct phases. The transitions from phase |
| to phase are open and transparent public reviews.</p> |
| <h4>6.2.1 Pre-proposal</h4> |
| <div class="postit">See guidelines and checklists about writing a |
| proposal.</div> |
| <p>An individual or group of individuals declares their interest in, |
| and rationale for, establishing a project. The EMO will assist such |
| groups in the preparation of a project Proposal.</p> |
| <ul> |
| <li>The Pre-proposal phase ends when the Proposal is published by EMO |
| and announced to the membership by the EMO.</li> |
| </ul> |
| <h4>6.2.2 Proposal</h4> |
| <div class="postit">See guidelines and checklists about gathering |
| support for a proposal.</div> |
| <p>The proposers, in conjunction with the destination PMC and the |
| community, collaborate in public to enhance, refine, and clarify the |
| proposal. Mentors (if necessary) for the project must be identified |
| during this phase.</p> |
| <ul> |
| <li>The Proposal phase ends with a Creation Review, or withdrawal.</li> |
| <li>The Proposal may be withdrawn by the proposers.</li> |
| <li>The EMO(ED) will withdraw a proposal that has been inactive for |
| more than six months.</li> |
| </ul> |
| <h4>6.2.3 Incubation</h4> |
| <div class="postit">See guidelines and checklists about |
| incubation.</div> |
| <p>After the project has been created, the purpose of the incubation |
| phase is to establish a fully-functioning open-source project. In this |
| context, incubation is about developing the process, the community, and |
| the technology. Incubation is a phase rather than a place: new projects |
| may be incubated under any existing Project.</p> |
| <ul> |
| <li>The Incubation phase may continue with a Continuation Review or a |
| Release Review.</li> |
| <li>Top-Level Projects cannot be incubated and can only be created from |
| one or more existing Mature-phase Projects.</li> |
| <li>The Incubation phase ends with a Graduation Review or a Termination |
| Review.</li> |
| <li>Designated Incubator Projects may remain perpetually in the |
| Incubation phase; no reviews are required.</li> |
| </ul> |
| <p>Many Eclipse Projects are proposed and initiated by individuals with |
| extensive and successful software development experience. This document |
| attempts to define a process that is sufficiently flexible to learn |
| from all its participants. At the same time, however, the Incubation |
| phase is useful for new Projects to learn the community-defined |
| Eclipse-centric open source processes.</p> |
| <div class="postit">See guidelines and checklists for utilizing the |
| Parallel IP process.</div> |
| <p>Only projects that are properly identified as being in the |
| incubation phase (including designated Incubator Projects) may use the |
| Parallel IP process to reduce IP clearance process for new |
| contributions.</p> |
| <h4>6.2.4 Mature</h4> |
| <div class="postit">See guidelines and checklists about the mature |
| phase.</div> |
| <p>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.</p> |
| <ul> |
| <li>Mature phase projects have Releases through Release Reviews.</li> |
| <li>A Mature Project may be promoted to a Top-Level Project through a |
| Promotion Review.</li> |
| <li>A Mature Project that does not participate in a Release in given |
| year may continue through a Continuation Review.</li> |
| <li>Inactive Mature phase projects may be archived through a |
| Termination Review.</li> |
| </ul> |
| <h4>6.2.5 Top-Level</h4> |
| <div class="postit">See guidelines and checklists about being a |
| top-level project.</div> |
| <p>Projects that have demonstrated the characteristics of a Top-Level |
| Project (e.g., consistent leadership in a technical area and the |
| recruitment of a wider developer community) can be promoted to |
| Top-Level Project status. This promotion occurs through a Promotion |
| Review. Upon the successful completion of a Promotion Review, the |
| EMO(ED) may recommend that the project be promoted to the Board of |
| Directors and ask that its Charter be reviewed and approved.</p> |
| <h4>6.2.6 Archived</h4> |
| <div class="postit">See guidelines and checklists for archiving |
| projects.</div> |
| <p>Projects that become inactive, either through dwindling resources or |
| by reaching their natural conclusion, are archived. Projects can reach |
| their natural conclusion in a number of ways: for example, a project |
| might become so popular that it is absorbed into one of the other major |
| frameworks. Projects are moved to Archived status through a Termination |
| Review.</p> |
| <p>If there is sufficient community interest in reactivating an |
| Archived Project, the Project will start again with Creation Review. As |
| there must be good reasons to have moved a Project to the Archives, the |
| Creation Review provides a sufficiently high bar to prove that those |
| reasons are no longer <strike>valid. It also ensures that the original or |
| updated project goals are still consistent with the Purposes and |
| Roadmap.</p></strike> <font color="green">valid.</p></font> |
| <h3>6.3 Reviews</h3> |
| <p>The Eclipse Development Process is predicated on open and |
| transparent behavior. All major changes to Eclipse projects must be |
| announced and reviewed by the membership-at-large. Major changes |
| include the Project Phase transitions as well as the introduction or |
| exclusion of significant new technology or capability. It is a clear |
| requirement of this document that members who are monitoring the |
| appropriate media channels (e.g., mailing lists or RSS feeds) not be |
| surprised by the post-facto actions of the Projects.</p> |
| <p>All Projects are required to participate in at least one Review per |
| year.</p> |
| <p>For each <b>Review</b>, the project leadership <strike>makes a presentation |
| to,</strike> <font color="green">prepares |
| documentation for,</font> and receives feedback from, the Eclipse |
| membership.</p> |
| <p>A Review is a fairly comprehensive process. Gathering the material |
| for a Review and preparing the <strike>presentation</strike> <font color="green">documentation</font> is a non-trivial effort, |
| but the introspection offered by this exercise is useful for the |
| Project and results are very useful for the entire Eclipse community. |
| In addition, Reviews have a specific relationship to the requirements |
| of the Eclipse IP Policy.</p> |
| <p>All Reviews have the same general process:</p> |
| <ol> |
| <li>Projects are responsible for initiating the appropriate reviews. |
| However, if a Project does not do so and the EMO believes a Review is |
| necessary, the EMO may initiate a Review on the Project's behalf.</li> |
| <li>A Review then continues with the Project's Leadership requesting |
| that the EMO(ED) schedule the Review.</li> |
| <li>Prior to the start of the review period, the Project leadership |
| provides the EMO with review documentation. |
| <ul> |
| <li>The review documentation material always includes a document that |
| describes the review. The minimum contents of the document are |
| specified by the individual Review types.</li> |
| <li>The <strike>presentation material</strike> <font color="green">review documentation</font> must be available in a format that anyone |
| in the Eclipse membership can review. <strike>For example, Microsoft Powerpoint |
| files are not an acceptable single format: such files may be one of the |
| formats, but not the only format. Similarly for Apple Keynote files and |
| Microsoft Word files.</strike> PDF and HTML are acceptable |
| single formats.</li> |
| <li>The <strike>presentation material</strike> <font color="green">review documentation</font> must have a correct copyright statement |
| and license.</li> |
| <li>The <strike>presentation material</strike> <font color="green">review documentation</font> must be <em>archival quality</em>. This |
| means that the materials must be comprehensible and complete on their |
| own without requiring explanation by a human presenter, reference to a |
| wiki, or to other non-archived web pages.</li> |
| </ul> |
| </li> |
| <li>The EMO announces the Review schedule and makes the documentation |
| available to the membership-at-large.</li> |
| </ol> |
| <p>The criteria for the successful completion of each type of Review |
| will be documented in writing by the EMO in guidelines made available |
| via the www.eclipse.org website. Such guidelines will include, but are |
| not limited to the following:</p> |
| <ol> |
| <li>Clear evidence that the project has vibrant committer, adopter and |
| user communities as appropriate for the type of Review.</li> |
| <li>Reasonable diversity in its committer population as appropriate for |
| the type of Review. Diversity status must be provided not only as |
| number of people/companies, but also in terms of effort provided by |
| those people/companies.</li> |
| <li>Documented completion of all required due diligence under the |
| Eclipse IP Policy.</li> |
| <li>For Continuation, Graduation and Release Reviews, the project must |
| have a current project plan, in the format specified by the EMO, |
| available to the community.</li> |
| <li>Balanced progress in creating both frameworks and extensible, |
| exemplary tools.</li> |
| <li>Showcase the project's quality through project-team chosen metrics |
| and measures, e.g., coupling, cyclomatic complexity, test/code |
| coverage, documentation of extensions points, etc.</li> |
| </ol> |
| <p>The Review period is open for no less than one week and usually no |
| more than two weeks of generally accepted business days.</p> |
| <ol> |
| <li>The Review begins with the EMO's posting of the review materials at |
| the start of the Review period</li> |
| <li>The proper functioning of the Eclipse Development Process is |
| contingent on the active participation of the Eclipse Members and |
| Committers, especially in Reviews, thus each Review has an |
| EMO-designated discussion and feedback communication channel: a |
| forum/newgroup, a mailing list, or some other public forum.</li> |
| <li>If a Committer election is required for a Review (for example, for |
| a Creation Review), then it is held simultaneously with the Review |
| period. Thus the election and the Review will end at the same time, |
| allowing quick and efficient provisioning of the resulting |
| Project.</li> |
| <li>The EMO(ED) 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.</li> |
| <li>The Review ends with the announcement of the results in the defined |
| Review communication channel (the EMO(ED) will request that the Project |
| Lead make this announcement).</li> |
| </ol> |
| <p>If any Member believes that the EMO has acted incorrectly in |
| approving or failing a Review may appeal to the Board to review the |
| EMO's decision.</p> |
| <h4>6.3.1 Creation Review</h4> |
| <div class="postit">See guidelines and checklists about Creation |
| Reviews.</div> |
| <p>The purpose of the Creation Review is to assess the community and |
| membership response to the proposal, to verify that appropriate |
| resources are available for the project to achieve its plan, and to |
| serve as a committer election for the project's initial Committers. The |
| Eclipse Foundation strives not to be a repository of "code dumps" and |
| thus projects must be sufficiently staffed for forward progress.</p> |
| <p>The Creation Review documents must include short nomination bios of |
| the proposed initial committers. These bios should discuss their |
| relationship to, and history with, the incoming code and/or their |
| involvement with the area/technologies covered by the proposal. The |
| goal is to help keep any legacy contributors connected to new project |
| and explain that connection to the current and future Eclipse |
| membership, as well as justify the initial Committers' participation in |
| a meritocracy.</p> |
| <h4>6.3.2 Graduation Review</h4> |
| <div class="postit">See guidelines and checklists about Graduation |
| Reviews.</div> |
| <p>The purpose of the Graduation Review is to confirm that the Project |
| is/has:</p> |
| <ul> |
| <li>a working and demonstrable code base of sufficiently high |
| quality</li> |
| <li>active and sufficiently diverse communities appropriate to the size |
| of the graduating code base: adopters, developers, and users</li> |
| <li>operating fully in the open following the Principles and Purposes |
| of Eclipse</li> |
| <li>a credit to Eclipse and is functioning well within the larger |
| Eclipse community</li> |
| </ul> |
| <p>The Graduation Review is about the phase change from Incubation |
| Phase to Mature Phase. If the Project and/or some of its code is |
| simultaneously relocating to another Project, the Graduation Review |
| will be combined with a Restructuring Review.</p> |
| <h4>6.3.3 Release Review</h4> |
| <div class="postit">See guidelines and checklists about Release |
| Reviews.</div> |
| <p>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.</p> |
| <h4>6.3.4 Promotion Review</h4> |
| <p>The purpose of a Promotion Review is to determine if the Project has |
| demonstrated the characteristics of a Top-Level Project, e.g., |
| consistent leadership in a technical area and the recruitment of a |
| wider developer community. The Project will already be a |
| well-functioning Mature Eclipse Project, so evidence to the contrary |
| will be a negative for promotion. Top-Level Projects, both through |
| their existence and their Council memberships, have substantial |
| influence over direction and operation of Eclipse, thus it behooves the |
| membership to grant Top-Level status only for merit: for demonstrated |
| service to the larger Eclipse ecosystem.</p> |
| <h4>6.3.5 Continuation Review</h4> |
| <p>The purpose of a Continuation Review is to verify that a Proposal or |
| Project continues to be a viable effort and a credit to Eclipse. The |
| Project team will be expected to explain the recent technical progress |
| and to demonstrate sufficient adopter, developer, and user support for |
| the Project. The goal of the Continuation Review is to avoid having |
| inactive projects looking promising but never actually delivering |
| extensible frameworks and exemplary tools to the ecosystem.</p> |
| <h4>6.3.6 Termination Review</h4> |
| <div class="postit">See Termination Review "How To" for more |
| information.</div> |
| <p>The purpose of a Termination Review is to provide a final |
| opportunity for the Committers and/or Eclipse membership to discuss the |
| proposed withdrawal of a Proposal or archiving of a Project. The |
| desired outcome is to find sufficient evidence of renewed interest and |
| resources in keeping the Project or Proposal active.</p> |
| <h4>6.3.7 Move Review</h4> |
| <p>A Move Review is considered to be a special type of Restructuring |
| Review.</p> |
| <h4>6.3.8 Restructuring Review</h4> |
| <p>The purpose of a Restructuring Review is to notify the community of |
| your intent to make significant changes to one or more projects. |
| "Significant changes" includes:</p> |
| <ul> |
| <li>Movement of significant chunks of functionality from one project to |
| another;</li> |
| <li>Modification of the project structure, e.g. combining multiple |
| projects into a single project, or decomposing a single project into |
| multiple projects; and/or</li> |
| <li>Change of project scope.</li> |
| </ul> |
| <p>A Restructuring Review may include the movement of significant |
| chunks of code. A move is considered significant if it has an impact on |
| the community (i.e. if segments of the community will notice that the |
| code has moved). This may include entire projects, bundles, and |
| features, but likely excludes small fragments, code snippets and |
| individual files. The IP Log of all moved code must be reviewed prior |
| to the start of the review period (this, typically, is a subset of the |
| project's IP Log). If all of the code is moved out of a project, a |
| Termination Review for that project can be combined with the |
| Restructuring Review.</p> |
| <p>Note that, regardless of whether or not a review is required, moving |
| code from one Project to another is subject to the Eclipse IP |
| Policy.</p> |
| <p>A Restructuring Review may necessitate the construction of one or |
| more new projects. This tends to occur when an existing project is |
| decomposed into two or more projects. In this case, a Restructuring |
| Review is similar to a Creation Review. Any new projects that are |
| created as part of a Restructuring Review must have their scope |
| explicitly specified as part of the review. The scope of any new |
| project must be a subset of the scope of the original project. |
| Likewise, the set of committers assigned to a new project must be a |
| subset of the committers of the original project (additional committers |
| can be elected to the new project after it is created). Any new |
| projects that fall outside of the scope of the original project, or |
| wish to establish a different set of committers, must undergo the full |
| project creation process.</p> |
| <p>Committers can be moved along with code into a new project as part |
| of the project provisioning process. Committers cannot be moved along |
| with code into an existing project. In this case, the existing project |
| must elect the new committers into the project.</p> |
| <p>A project is expected to socialize pending changes using established |
| communication channels prior to initiating the review. A Restructuring |
| Review must provide the community with at least one week to review and |
| respond to the changes. Prior to the start of that review period, the |
| community must be provided with (via the EMO) completed review |
| documentation that describes in specific terms what will be changed as |
| part of the restructuring.</p> |
| <p>This may include:</p> |
| <ul> |
| <li>Name, description, scope, and committer lists of new projects that |
| need to be created;</li> |
| <li>Source and target locations for moves of source code |
| directories;</li> |
| <li>Reorganization of builds and downloads;</li> |
| <li>Contribution questionnaires (CQs) that need to be moved or |
| piggy-back CQs that must be created;</li> |
| <li>Location of the approved IP Log; and</li> |
| <li>Other information that helps the community understand the |
| change.</li> |
| </ul> |
| <h4>6.3.9 Combining Reviews</h4> |
| <p>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.</p> |
| <p>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 it's child Projects generally makes sense. |
| Combining Release Reviews for multiple unrelated projects most likely |
| does not.</p> |
| <h3>6.4 Releases</h3> |
| <p><em>(Most of this section is borrowed and paraphrased from the |
| excellent Apache Software Foundation Releases FAQ. The Eclipse |
| community has many of the same beliefs about Releases as does the |
| Apache community and their words were already excellent. The Apache |
| Software Foundation Releases FAQ is distributed under the Apache |
| License, Version 2.0.)</em></p> |
| <p>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.</p> |
| <p><em>(Exception 1: nightly and integration builds)</em> 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.</p> |
| <p><em>(Exception 2: milestone and release candidate builds)</em> |
| 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.</p> |
| <ul> |
| <li>Milestones are to be labeled <code>x.yMz</code>, e.g., 2.3M1 |
| (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version |
| 2.3), etc.</li> |
| <li>Release candidates are to be labeled <code>x.yRCz</code>, e.g., |
| 2.3RC1 (release candidate 1 towards version 2.3).</li> |
| <li>Official Releases are the only downloads allowed to be labeled with |
| <code>x.y</code>, e.g., 0.5, 1.0, 2.3, etc.</li> |
| </ul> |
| <p>All official Releases must have a successful Release Review before |
| being made available for download.</p> |
| <p><em>(Exception 3: bug fix releases with no new features)</em> 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.</p> |
| <p>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.</p> |
| <h3>6.5 Grievance Handling</h3> |
| <p>When a Member has a concern about a Project, the Member will raise |
| that concern with the Project's Leadership. If the Member is not |
| satisfied with the result, the Member can raise the concern with the |
| parent Project's Leadership. The Member can continue appeals up the |
| Project Leadership Chain and, if still not satisfied, thence to the |
| EMO, then the Executive Director, and finally to the Board. All appeals |
| and discussions will abide by the Guiding Principles of being open, |
| transparent, and public.</p> |
| <p>Member concerns may include:</p> |
| <ul> |
| <li><b>Out of Scope.</b> It is alleged that a Project is exceeding its |
| approved scope.</li> |
| <strike><li><b>Inconsistent with Purposes.</b> It is alleged that a Project is |
| inconsistent with the Roadmap and/or Purposes.</li></strike> |
| <li><b>Dysfunctional.</b> It is alleged that a Project is not |
| functioning correctly or is in violation of one or more requirements of |
| the Development Process.</li> |
| <li><b>Contributor Appeal.</b> It is alleged that a Contributor who |
| desires to be a Committer is not being treated fairly.</li> |
| <li><b>Invalid Veto.</b> It is alleged that a -1 vote on a Review is |
| not in the interests of the Project and/or of Eclipse.</li> |
| </ul> |
| <p>A variety of grievance resolutions are available to the EMO up to, |
| and including, rebooting or restarting a project with new Committers |
| and leadership.</p> |
| <h2>7. Precedence</h2> |
| <p>In the event of a conflict between this document and a |
| Board-approved project charter, the most recently approved document |
| will take precedence.</p> |
| <h2>8. Revisions</h2> |
| <p>As specified in the Bylaws, the EMO is responsible for maintaining |
| this document and all changes must be approved by the Board.</p> |
| <p>Due to the continued evolution of the Eclipse technology, the |
| Eclipse community, and the software marketplace, it is expected that |
| the Development Process (this document) will be reviewed and revised on |
| at least an annual basis. The timeline for that review should be chosen |
| so as to incorporate the lessons of the previous annual coordinate |
| release and to be applied to the next annual coordinated release.</p> |
| <p>The EMO is further responsible for ensuring that all plans, |
| documents and reports produced in accordance with this Development |
| Process be made available to the Membership at Large via an appropriate |
| mechanism in a timely, effective manner.</p> |
| <h4>8.1 Revision <strike>2.5</h4></strike> <font color="green">2.6</h4></font> |
| <p>This document was approved by the Eclipse Foundation Board of |
| Directors in its meeting on <strike>May 19/2010.</strike> <font color="green">XXXXXXXX.</font> It takes effect (replacing all |
| previous versions) on August <strike>1/2010.</p></strike> <font color="green">1/2011.</p></font> |
| </body> |
| </html> |