| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title> </title> |
| </head> |
| <body> |
| <h1>Eclipse Development Process <font color="green">2014</font> </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 |
| <font color="green"><ul> |
| <li>2.3.1 Contributors and Committers </li> |
| <li>2.3.2 Users </li> |
| <li>2.3.3 Adopters </li> |
| </ul></font> |
| </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 <strike>Releases</strike> <font color="green">Resources</font> </li> |
| <li>4.3 <strike>IP</strike> <font color="green">Intellectual Property (IP)</font> 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 <font color="green">Permanent</font> Incubator Projects </li> |
| </ul> |
| </li> |
| <li>5 [Reserved] </li> |
| <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 <strike>Top-Level</strike> <font color="green">[Reserved]</font> </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 <strike>Promotion Review</strike> <font color="green">[Reserved]</font> </li> |
| <li>6.3.5 <strike>Continuation Review</strike> <font color="green">[Reserved]</font> </li> |
| <li>6.3.6 Termination Review </li> |
| <li>6.3.7 <strike>Move Review</strike> <font color="green">[Reserved]</font> </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> |
| <font color="green"><blockquote></font> <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> <font color="green"></blockquote></font> |
| <p>This document has the following 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> |
| <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> |
| <strike><li>Open</strike> |
| <font color="green"><li> <b>Open </b></font> - 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> |
| <strike><li>Transparent</strike> |
| <font color="green"><li> <b>Transparent </b></font> - Project discussions, minutes, deliberations, |
| project plans, plans for new features, and other artifacts are open, |
| public, and easily accessible. </li> |
| <strike><li>Meritocracy</strike> |
| <font color="green"><li> <b>Meritocracy </b></font> - 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 them; and </li> |
| <li>ship extensible, exemplary tools which help enable a broad |
| community of users </li> |
| </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> |
| <strike><ul> |
| <li>Contributors</strike> |
| <font color="green"><h4>2.3.1 Contributors</font> and Committers <strike>- a</strike> <font color="green"></h4> |
| <p>A</font> thriving, <strike>diverse</strike> <font color="green">diverse,</font> 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. |
| <strike><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>Users - an</strike> <font color="green"></p> |
| <h4>2.3.2 Users </h4> |
| <p>An</font> 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. <strike></li> |
| <li>Adopters - an</strike> <font color="green"></p> |
| <h4>2.3.3 Adopters </h4> |
| <p>An</font> 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. <strike></li> |
| </ul></strike> <font color="green"></p></font> |
| <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> |
| <p>Required - 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> |
| <p>Guideline - 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 project 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, <strike>Top-Level</strike> <font color="green">"top-level"</font> projects, 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 project 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 <strike>Sub-Project.</strike> <font color="green">"subproject".</font> The term |
| project refers to either a top-level project or a <strike>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.</strike> <font color="green">subproject.</font> </p> |
| <p>The descendants of a project are the project itself and transitive |
| closure of its child projects. The top parent of a project is the |
| top-level project at the top of the hierarchy. </p> |
| <p>Projects are the unit entity for: </p> |
| <ul> |
| <strike><li>Committers</strike> |
| <font color="green"><li>committers;</font> </li> |
| <li>code and <strike>Releases</strike> <font color="green">releases;</font> </li> |
| <strike><li>IP Records</strike> |
| <font color="green"><li>intellectual property (IP) records; and</font> </li> |
| <li>community awareness </li> |
| </ul> |
| <p>As defined by <strike>the Eclipse</strike> Bylaws <font color="green">of Eclipse Foundation</font> - Article VII, the <strike>Eclipse</strike> |
| <font color="green">"Eclipse</font> Management <strike>Organization</strike> <font color="green">Organization"</font> (EMO) consists of the <font color="green">Eclipse</font> |
| Foundation staff and the councils. The term EMO(ED), 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 |
| <strike>Sub-Projects</strike> |
| <font color="green">subprojects</font> 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 <strike>Sub-Projects.</strike> <font color="green">subprojects.</font> </p> |
| <p>The committers of a project have the exclusive right to elect new |
| committers to their <strike>Project–no</strike> <font color="green">project; no</font> other group, including a parent |
| project, can force a project to accept a new committer. </p> |
| <p>There is no roll-up of committers: the set of committers on a |
| project is exactly that set of people who have been explicitly elected |
| into that role for the project (i.e. being a committer on a <strike>sub-project</strike> <font color="green">subproject</font> |
| does not give you any automatic rights on the "parent" <font color="green">project or any |
| child</font> 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 |
| <strike>Sub-Projects.</strike> |
| <font color="green">subprojects.</font> Each of these <strike>Sub-Projects</strike> <font color="green">subprojects</font> has its own distinct set of |
| committers and resources. </p> |
| <font color="green"><img src= |
| "/projects/dev_process/images/subprojects-resources-291x300.png"></font> |
| <h3>4.2 Code and <strike>Releases</strike> <font color="green">Resources</font> </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 <strike>Sub-Projects.</strike> <font color="green">subprojects.</font> Similarly, |
| a project might opt to provide a consolidated website, build and/or |
| download site for its <strike>Sub-Projects</strike> <font color="green">subprojects</font> (the <strike>Sub-Projects</strike> <font color="green">subprojects</font> would then not |
| require those resources for themselves). </p> |
| <strike><p>Each Project has</strike> |
| <font color="green"><p>Namespaces are assigned to</font> a <strike>single Bugzilla component for its bugs. </p> |
| <p>Any</strike> project <strike>in</strike> <font color="green">by</font> the <strike>Mature Phase may make a Release. A</strike> <font color="green">EMO. All</font> project <font color="green">source |
| code must be organized</font> in the |
| <strike>Incubation Phase</strike> <font color="green">assigned namespaces and projects can only |
| release code under their own namespace (that is, they cannot infringe |
| on another Eclipse project's namespace). Projects should work</font> with <strike>two</strike> |
| <font color="green">their PMCs and the EMO to request exceptions to this rule, and with |
| their</font> mentors <strike>may make a pre-1.0 Release. A Release |
| may include</strike> <font color="green">and PMC if there are questions regarding</font> the <strike>code from any subset</strike> <font color="green">use</font> of the <strike>Project's descendants.</strike> |
| <font color="green">namespace.</font> </p> |
| <h3>4.3 <strike>IP</strike> <font color="green">Intellectual Property (IP)</font> 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, <font color="green">and</font> |
| design <strike>discussions, and so on.</strike> <font color="green">discussions.</font> </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 charter which describes the purpose, |
| scope, 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 <font color="green">of directors</font> approves the charter |
| of each top-level project. </p> |
| <strike><p>Sub-Projects</strike> |
| <font color="green"><p>Subprojects</font> do not have separate charters; <strike>Sub-Projects</strike> <font color="green">subprojects</font> operate under |
| the charter of their parent top-Level project. </p> |
| <p>All projects have a defined scope 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 <strike>Sub-Project</strike> <font color="green">subproject</font> is defined by the initial project proposal |
| as reviewed and approved by the Project Management Committee (PMC) (as |
| further defined below) of the project's <strike>Project's</strike> 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 <strike>Sub-Projects</strike> <font color="green">subprojects</font> (if any) conform to the |
| Eclipse Foundation IP policy and procedures. </li> |
| </ul> |
| <p>The leadership <font color="green">chain</font> for a project is composed of the project's |
| project lead(s), the leadership of the parent project (if <strike>any) and</strike> <font color="green">any),</font> the PMC |
| leads and PMC members for the top-level <strike>Project.</strike> <font color="green">project, the EMO, and the |
| EMO(ED). </p> |
| <p>In exceptional situations—such as projects with zero active |
| committers, disruptive committers, or 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, and otherwise act on behalf of the project lead.</font> </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 <strike>Board;</strike> <font color="green">board of directors;</font> 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 |
| <strike>leadership is</strike> |
| <font color="green">leads are</font> 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 <strike>member of the</strike> project <strike>leadership</strike> <font color="green">lead</font> becomes disruptive to the |
| process or ceases to contribute for an extended period, the <strike>member</strike> <font color="green">individual</font> |
| 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> |
| <strike><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></strike> |
| <h3>4.7 Committers and Contributors </h3> |
| <p>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. </p> |
| <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 <strike>Leaders</strike> <font color="green">leads</font> 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 <strike>Leaders. (Unless</strike> <font color="green">leads. Unless</font> |
| otherwise specified, "an extended period" is defined as "no activity |
| for more than six <strike>months".)</strike> <font color="green">months".</font> </p> |
| <p>Active participation in the user <strike>forums/newsgroups</strike> <font color="green">communication channels</font> 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 |
| <strike>forums/newsgroups.</strike> <font color="green">communication |
| channels.</font> </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 <strike>Projects and components.</strike> <font color="green">projects.</font> 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 <strike>Lead,</strike> <font color="green">lead or member,</font> 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 councils defined in <strike>Bylaws</strike> <font color="green">the bylaws,</font> section VII are comprised of |
| strategic members and PMC representatives. The councils help guide the |
| projects as follows: </p> |
| <ul> |
| <li>The Planning Council is responsible for establishing a coordinated |
| simultaneous release (a.k.a, "the release train"). The Planning Council |
| is further 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>The Architecture Council is responsible for (i) monitoring, |
| guiding, and influencing the software architectures used by projects, |
| (ii) new project mentoring, and (iii) maintaining and revising the |
| Eclipse Development Process. 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 <font color="green">Permanent</font> Incubator Projects </h3> |
| <p>A project may designate a <strike>Sub-Project</strike> <font color="green">subproject</font> as <strike>an "Incubator". An</strike> <font color="green">a "permanent incubator". A |
| permanent</font> incubator is a project that is intended to perpetually remain |
| in the incubation phase. <font color="green">Permanent</font> 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> |
| <strike><p>Incubator</strike> |
| <font color="green"><p>Permanent incubator</font> projects never have releases; they <strike>do not require yearly |
| continuation reviews and they are not part of</strike> <font color="green">cannot |
| participate in</font> the annual <strike>release train.</strike> <font color="green">simultaneous release. Permanent</font> 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. <font color="green">Permanent</font> incubators do not |
| graduate. </p> |
| <p>The scope of <strike>an</strike> <font color="green">a permanent</font> incubator project must fall within the |
| scope of its parent project. The committer group of the <font color="green">permanent</font> |
| 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). <font color="green">Permanent</font> incubator projects do not require Architecture |
| Council mentors (the parent project's committers are responsible for |
| ensuring that the incubator project <strike>conform</strike> <font color="green">conforms</font> to the rules set forth by |
| the Eclipse Development Process). </p> |
| <strike><p>An</strike> |
| <font color="green"><p>A permanent</font> incubator project <strike>should</strike> <font color="green">must be</font> 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 |
| <strike>an</strike> |
| <font color="green">a permanent</font> incubator. <strike>Incubators</strike> <font color="green">Permanent incubator projects</font> are created <strike>via</strike> <font color="green">upon |
| request;</font> a creation <strike>Review. |
| Alternatively, an Incubator can be created as part of a Graduation, |
| Promotion, or Restructuring Review. A proposal</strike> <font color="green">review</font> is not <strike>required to |
| create an Incubator project.</strike> <font color="green">required.</font> </p> |
| <h2>5. [Reserved] </h2> |
| <h2>6. Development Process </h2> |
| <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. Further, projects must |
| fit within the scope defined by their containing projects and the scope |
| defined in the charter of their top-level project. </p> |
| <strike><p>All projects are required to report their status at least quarterly |
| using the EMO defined status reporting procedures. </p></strike> |
| <p>Projects must provide advanced notification of upcoming features and |
| frameworks via their project plan. </p> |
| <h3>6.1 Mentors </h3> |
| <p>New <font color="green">project</font> proposals <strike>that intend to do a Release</strike> are required to have at least two mentors. <strike>New Proposals that will only Release code as part of |
| a parent Project's Release are not required to have Mentors.</strike> |
| Mentors must be members of the Architecture Council. The mentors <strike>(including |
| name, affiliation, and current Eclipse projects/roles)</strike> must |
| be listed in the proposal. Mentors are required to monitor and advise |
| the new project during its incubation <strike>Phase, but</strike> <font color="green">phase; they</font> are released from |
| that duty once the project graduates to the mature phase. </p> |
| <h3>6.2 Project Lifecycle </h3> |
| <font color="green"><img src= |
| "/projects/dev_process/development_process_2014/images/lifecycle.png" |
| align="right"></font> |
| <p>Projects go through <strike>six</strike> distinct phases. The transitions from phase to |
| phase are open and transparent public reviews. </p> |
| <h4>6.2.1 Pre-proposal </h4> |
| <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> |
| <strike><ul> |
| <li>The</strike> |
| <font color="green"><p>The</font> pre-proposal phase ends when the proposal is published by EMO |
| and announced to the membership by the EMO. <strike></li> |
| </ul></strike> <font color="green"></p></font> |
| <h4>6.2.2 Proposal </h4> |
| <p>The proposers, in conjunction with the destination PMC and the |
| community, collaborate in public to enhance, refine, and clarify the |
| proposal. Mentors <strike>(if necessary)</strike> for the project must be identified during this |
| phase. </p> |
| <strike><ul> |
| <li>The</strike> |
| <font color="green"><p>The</font> proposal phase ends with a creation review, or withdrawal. <strike></li> |
| <li>The</strike> <font color="green">The</font> |
| proposal may be withdrawn by the <strike>proposers. </li> |
| <li>The EMO(ED)</strike> <font color="green">proposers at any point before the |
| start of a creation review. The EMO</font> will withdraw a proposal that has |
| been inactive for more than six months. <strike></li> |
| </ul></strike> <font color="green"></p></font> |
| <h4>6.2.3 Incubation </h4> |
| <strike><p>After the project has been created, the</strike> |
| <font color="green"><p>The</font> 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> |
| <strike><li>The</strike> |
| <font color="green"><li>A project in the</font> incubation phase <strike>may continue with a Continuation Review or a |
| Release Review.</strike> <font color="green">can (and should) make |
| releases;</font> </li> |
| <li>Top-level projects <strike>cannot be incubated</strike> <font color="green">skip incubation</font> and <strike>can only be created from |
| one or more existing Mature-phase Projects.</strike> <font color="green">are immediately put into the |
| mature phase;</font> </li> |
| <li>The incubation phase ends with a graduation review or a termination |
| review. </li> |
| <li>Designated <font color="green">permanent</font> incubator projects <strike>may</strike> remain perpetually in the |
| incubation phase; <font color="green">they do not create releases, so</font> 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> |
| <p>Only projects that are properly identified as being in the |
| incubation phase (including designated <font color="green">permanent</font> incubator projects) |
| may use the Parallel IP Process to reduce IP clearance process for new |
| contributions. </p> |
| <h4>6.2.4 Mature </h4> |
| <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 <strike>Eclipse Quality</strike> <font color="green">Eclipse-quality</font> technology. The project is now a |
| mature member of the Eclipse community. Major releases continue to go |
| through release reviews. </p> |
| <strike><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></strike> |
| <h4>6.2.5 <strike>Top-Level</strike> <font color="green">[Reserved]</font> </h4> |
| <strike><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></strike> |
| <h4>6.2.6 Archived </h4> |
| <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 <strike>will</strike> <font color="green">can</font> start again with <font color="green">a</font> creation review. |
| As there must be good reasons to have <strike>moved</strike> <font color="green">terminated</font> a <strike>Project to the Archives,</strike> <font color="green">project,</font> the |
| creation review provides a sufficiently high bar to prove that those |
| reasons are no longer valid. </p> |
| <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> |
| <strike><p>All Projects are required to participate in at least one Review per |
| year. </p></strike> |
| <p>For each review, the project <strike>leadership prepares</strike> <font color="green">leads prepare</font> documentation for, and <strike>receives</strike> |
| <font color="green">receive</font> feedback from, the Eclipse membership. </p> |
| <p>A review is a fairly comprehensive process. Gathering the material |
| for a review and preparing the documentation 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 <strike>the Project's Leadership</strike> <font color="green">a project lead</font> requesting that the |
| EMO(ED) schedule the review. </li> |
| <li>Prior to the start of the review period, <strike>the</strike> <font color="green">a</font> project <strike>leadership</strike> <font color="green">lead</font> 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 review documentation must be available in a format that anyone |
| in the Eclipse membership can review. PDF and HTML are acceptable |
| single formats. </li> |
| <li>The review documentation must have a correct copyright statement |
| and license. </li> |
| <li>The review documentation 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 <strike>the www.eclipse.org</strike> <font color="green">an Eclipse Foundation</font> 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 <strike>Continuation,</strike> 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 <font color="green">of directors</font> to |
| review the EMO's decision. </p> |
| <h4>6.3.1 Creation Review </h4> |
| <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> |
| <p>The purpose of the graduation review is to <strike>confirm</strike> <font color="green">mark a project's change |
| from the incubation phase to the mature phase. </p> |
| <p>The graduation review confirms</font> that the project is/has: </p> |
| <ul> |
| <li>A working and demonstrable code base of sufficiently high |
| <strike>quality</strike> |
| <font color="green">quality.</font> </li> |
| <li>Active and sufficiently diverse communities appropriate to the size |
| of the graduating code base: adopters, developers, and <strike>users</strike> <font color="green">users.</font> </li> |
| <li>Operating fully in the open following the principles and purposes |
| of <strike>Eclipse</strike> <font color="green">Eclipse.</font> </li> |
| <li>A credit to Eclipse and is functioning well within the larger |
| Eclipse <strike>community</strike> <font color="green">community.</font> </li> |
| </ul> |
| <strike><p>The</strike> |
| <font color="green"><p>A</font> graduation review is <strike>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</strike> <font color="green">generally</font> combined with a <strike>Restructuring</strike> <font color="green">release</font> review. </p> |
| <h4>6.3.3 Release Review </h4> |
| <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 <strike>Promotion Review</strike> <font color="green">[Reserved]</font> </h4> |
| <strike><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></strike> |
| <h4>6.3.5 <strike>Continuation Review</strike> <font color="green">[Reserved]</font> </h4> |
| <strike><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></strike> |
| <h4>6.3.6 Termination Review </h4> |
| <p>The purpose of a termination review is to provide a final |
| opportunity for the committers and/or Eclipse membership to discuss the |
| proposed <strike>withdrawal of a Proposal or</strike> archiving of a Project. The desired outcome is to find |
| sufficient evidence of renewed interest and resources in keeping the |
| project <strike>or Proposal</strike> active. </p> |
| <h4>6.3.7 <strike>Move Review</strike> <font color="green">[Reserved]</font> </h4> |
| <strike><p>A Move Review is considered to be a special type of Restructuring |
| Review. </p></strike> |
| <h4>6.3.8 Restructuring <strike>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</strike> <font color="green">Review </h4> |
| <p>The purpose</font> of <font color="green">a restructuring review is to notify</font> the <strike>restructuring. </p> |
| <p>This may</strike> <font color="green">community of |
| significant changes to one or more projects. Examples of "significant |
| changes"</font> include: </p> |
| <ul> |
| <strike><li>Name, description, scope, and committer lists of new projects that |
| need to be created; </li> |
| <li>Source and target locations for moves</strike> |
| <font color="green"><li>Movement</font> of <strike>source code |
| directories; </li> |
| <li>Reorganization</strike> <font color="green">significant chunks</font> of <strike>builds and downloads; </li> |
| <li>Contribution questionnaires (CQs) that need</strike> <font color="green">functionality from one project</font> to <strike>be moved or |
| piggy-back CQs that must be created;</strike> |
| <font color="green">another.</font> </li> |
| <strike><li>Location</strike> |
| <font color="green"><li>Modification</font> of the <strike>approved IP Log; and</strike> <font color="green">project structure, e.g. combining multiple |
| projects into a single project, or decomposing a single project into |
| multiple projects.</font> </li> |
| <strike><li>Other information that helps the community understand the |
| change.</strike> |
| <font color="green"><li>Change of project scope.</font> </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> |
| <font color="green"><p>Any project, with exception of permanent incubators, may make a |
| release. A release may include the code from any subset of the |
| project's descendants. </p></font> |
| <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> |
| <font color="green"><p>Releases for projects in the incubation phase must be labeled to |
| indicate the incubation status of the project. </p></font> |
| <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 <strike>Board.</strike> <font color="green">board of |
| directors.</font> 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>Out of scope. It is alleged that a project is exceeding its |
| approved scope. </li> |
| <li>Dysfunctional. It is alleged that a project is not functioning |
| correctly or is in violation of one or more requirements of the <font color="green">Eclipse</font> |
| Development Process. </li> |
| <li>Contributor appeal. It is alleged that a contributor who desires to |
| be a committer is not being treated fairly. </li> |
| <li>Invalid veto. 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 |
| <strike>Board-approved</strike> <font color="green">board of |
| directors-approved</font> 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 <strike>Board.</strike> <font color="green">board of |
| directors.</font> </p> |
| <p>Due to the continued evolution of the Eclipse technology, the |
| Eclipse community, and the software marketplace, it is expected that |
| the <font color="green">Eclipse</font> 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.6</strike> <font color="green">2.7</font> </h4> |
| <p>This document was approved by the Eclipse Foundation Board of |
| Directors in its meeting on <strike>June 15/2011.</strike> <font color="green">[TBD].</font> It takes effect (replacing all |
| previous versions) on <strike>August 1/2011.</strike> <font color="green">[TBD]. </p> |
| <h4>8.2 History </h4> |
| <p>Changes made in this document:</font> </p> |
| <font color="green"><ul> |
| <li>(Bug 344041) Yearly reviews are no longer required </li> |
| <li>(Bug 367235) Confusing language regarding termination of project |
| lead role </li> |
| <li>(Bug 368196) A graduation review is generally combined with a |
| release review </li> |
| <li>(Bug 415626) Restructuring review section too verbose </li> |
| <li>(Bug 415629) Permanent Incubator Projects do not require a creation |
| review </li> |
| <li>(Bug 415636) Ensure that social coding is adequately addressed by |
| the EDP </li> |
| <li>(Bug 415696) Move paragraph concerning releases from section 4.2 to |
| section 6.4 </li> |
| <li>(Bug 415714) Remove reference to "Bugzilla" </li> |
| <li>(Bug 415715) Fix capitalization </li> |
| <li>(Bug 416636) "Top-Level" is not a phase </li> |
| <li>(Bug 417883) Termination reviews not required for proposals </li> |
| <li>(Bug 418346) Reduce redundancy in 2.3 "Three Communities" </li> |
| <li>(Bug 418468) Rename Incubators to "Permanent Incubators" </li> |
| <li>(Bug 419717) Complete section 8.2 "History" </li> |
| <li>(Bug 419721) Confusing use of "project leadership" vs. "project |
| lead" </li> |
| <li>(Bug 419724) Include the EMO(ED) in the project leadership |
| chain </li> |
| <li>(Bug 325004) Eliminate Continuation, Promotion, and Move |
| Reviews </li> |
| <li>(Bug 331397) EDP should say more about project namespaces </li> |
| <li>(Bug 345755) Eliminate the pre-1.0 versioning requirement for |
| incubating projects </li> |
| </ul></font> |
| </body> |
| </html> |