| |
| |
| |
| |
| |
| p { margin-bottom:10px; } blockquote { margin-left:2em; margin-right: | p { margin-bottom:10px; } blockquote { margin-left:2em; margin-right: |
| |
| |
| |
| |
| |
| |
| Eclipse Development Process Eclipse Development Process |
| |
| Contents Contents |
| |
| |
| 1 Purpose 1 Purpose |
| 2 Principles 2 Principles |
| |
| 2.1 Open Source 2.1 Open Source |
| Rules of Engagement Rules of Engagement |
| 2.2 Eclipse Ecosystem 2.2 Eclipse Ecosystem |
| 2.3 Three Communities 2.3 Three Communities |
| 2.4 Clear, Concise, and 2.4 Clear, Concise, and |
| Evolving Evolving |
| |
| |
| 3 Requirements 3 Requirements |
| |
| 3.1 Requirements and 3.1 Requirements and |
| Guidelines Guidelines |
| |
| |
| 4 Project Structure and 4 Project Structure and |
| Organization Organization |
| |
| 4.1 Committers 4.1 Committers |
| 4.2 Code and Releases 4.2 Code and Releases |
| 4.3 IP Records 4.3 IP Records |
| 4.4 Community Awareness 4.4 Community Awareness |
| 4.5 Scope 4.5 Scope |
| 4.6 Leaders 4.6 Leaders |
| > |
| > 4.6.1 Project Management Committee |
| > (PMC) |
| > 4.6.2 Project Lead(s) |
| > |
| > |
| 4.7 Committers and 4.7 Committers and |
| Contributors Contributors |
| 4.8 Councils 4.8 Councils |
| 4.9 Incubator Projects 4.9 Incubator Projects |
| |
| |
| 5 Roadmap Process 5 Roadmap Process |
| 6 Development Process 6 Development Process |
| |
| 6.1 Mentors 6.1 Mentors |
| 6.2 Project Lifecycle 6.2 Project Lifecycle |
| 6.2.1 Pre-proposal 6.2.1 Pre-proposal |
| 6.2.2 Proposal 6.2.2 Proposal |
| 6.2.3 Incubation 6.2.3 Incubation |
| 6.2.4 Mature 6.2.4 Mature |
| 6.2.5 Top-Level 6.2.5 Top-Level |
| 6.2.6 Archived 6.2.6 Archived |
| 6.3 Reviews 6.3 Reviews |
| |
| 6.3.1 Creation Review 6.3.1 Creation Review |
| 6.3.2 Graduation Review 6.3.2 Graduation Review |
| 6.3.3 Release Review 6.3.3 Release Review |
| 6.3.4 Promotion Review 6.3.4 Promotion Review |
| 6.3.5 Continuation 6.3.5 Continuation |
| Review Review |
| 6.3.6 Termination 6.3.6 Termination |
| Review Review |
| 6.3.7 Move Review 6.3.7 Move Review |
| 6.3.8 Restructuring 6.3.8 Restructuring |
| Review Review |
| 6.3.9 Combining Reviews 6.3.9 Combining Reviews |
| |
| |
| 6.4 Releases 6.4 Releases |
| 6.5 Grievance Handling 6.5 Grievance Handling |
| |
| |
| 7 Precedence 7 Precedence |
| 8 Revisions 8 Revisions |
| |
| 8.1 Revision 2.4 8.1 Revision 2.4 |
| |
| |
| |
| |
| |
| 1. Purpose 1. Purpose |
| This document describes the Development Process for the Eclipse This document describes the Development Process for the Eclipse |
| Foundation. In particular, it describes how the Membership at Large, Foundation. In particular, it describes how the Membership at Large, |
| the Board of Directors, other constituents of the Ecosystem, and the the Board of Directors, other constituents of the Ecosystem, and the |
| Eclipse Management Organization (EMO) lead, influence, and collaborate Eclipse Management Organization (EMO) lead, influence, and collaborate |
| with Eclipse Projects to achieve these Eclipse purposes: with Eclipse Projects to achieve these Eclipse purposes: |
| The Eclipse technology is a vendor-neutral, open The Eclipse technology is a vendor-neutral, open |
| development platform supplying frameworks and exemplary, extensible development platform supplying frameworks and exemplary, extensible |
| tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary i tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary i |
| that they verify the utility of the Eclipse frameworks, illustrate the that they verify the utility of the Eclipse frameworks, illustrate the |
| appropriate use of those frameworks, and support the development and appropriate use of those frameworks, and support the development and |
| maintenance of the Eclipse Platform itself; Eclipse Platform tools are maintenance of the Eclipse Platform itself; Eclipse Platform tools are |
| extensible in that their functionality is accessible via documented extensible in that their functionality is accessible via documented |
| programmatic interfaces. The purpose of Eclipse Foundation Inc., is to programmatic interfaces. The purpose of Eclipse Foundation Inc., is to |
| advance the creation, evolution, promotion, and support of the Eclipse advance the creation, evolution, promotion, and support of the Eclipse |
| Platform and to cultivate both an open source community and an Platform and to cultivate both an open source community and an |
| ecosystem of complementary products, capabilities, and ecosystem of complementary products, capabilities, and |
| services. services. |
| |
| | Explanatory comments, guidelines, and checklists - as well as |
| | additional requirements added by the EMO per <a href= |
| Explanatory comments, guidelines, and checklists - as < |
| well as additional requirements added by the EMO per <a href= < |
| "#3_Requirements">section 3 - are noted in yellow boxes. "#3_Requirements">section 3 - are noted in yellow boxes. |
| |
| < |
| < |
| This document has five sections: This document has five sections: |
| |
| Principles outlines the basic Principles outlines the basic |
| principles upon which the development process is based. principles upon which the development process is based. |
| Requirements describes the Requirements describes the |
| requirements that the Eclipse community has for its development requirements that the Eclipse community has for its development |
| process. process. |
| Structure and Structure and |
| Organization specifies the structure and organization of the Organization specifies the structure and organization of the |
| projects and project community at Eclipse. projects and project community at Eclipse. |
| Roadmap Process describes Roadmap Process describes |
| the manner by which the EMO will work with the projects to create the the manner by which the EMO will work with the projects to create the |
| annual Eclipse Roadmap. annual Eclipse Roadmap. |
| Development Process Development Process |
| outlines the lifecycle and processes required of all Eclipse outlines the lifecycle and processes required of all Eclipse |
| projects. projects. |
| |
| 2. Principles 2. Principles |
| The following describe the guiding principles used in developing this | The following describes the guiding principles used in developing |
| Development Process. | this Development Process. |
| 2.1 Open Source 2.1 Open Source |
| Rules of Engagement Rules of Engagement |
| |
| Open - Eclipse is open to all; Eclipse provides the same Open - Eclipse is open to all; Eclipse provides the same |
| opportunity to all. Everyone participates with the same rules; there opportunity to all. Everyone participates with the same rules; there |
| are no rules to exclude any potential contributors which include, of are no rules to exclude any potential contributors which include, of |
| course, direct competitors in the marketplace. course, direct competitors in the marketplace. |
| Transparent - Project discussions, minutes, deliberations, Transparent - Project discussions, minutes, deliberations, |
| project plans, plans for new features, and other artifacts are open, project plans, plans for new features, and other artifacts are open, |
| public, and easily accessible. public, and easily accessible. |
| Meritocracy - Eclipse is a meritocracy. The more you Meritocracy - Eclipse is a meritocracy. The more you |
| contribute the more responsibility you will earn. Leadership roles in contribute the more responsibility you will earn. Leadership roles in |
| Eclipse are also merit-based and earned by peer acclaim. Eclipse are also merit-based and earned by peer acclaim. |
| |
| 2.2 Eclipse Ecosystem 2.2 Eclipse Ecosystem |
| Eclipse as a brand is the sum of its parts (all of the Projects), and | Eclipse as a brand is the sum of its parts (all of the Projects), |
| Projects should strive for the highest possible quality in extensible | and Projects should strive for the highest possible quality in |
| frameworks, exemplary tools, transparent processes, and project | extensible frameworks, exemplary tools, transparent processes, and |
| openness. | project openness. |
| The Eclipse Foundation has the responsibility to The Eclipse Foundation has the responsibility to |
| ...cultivate...an ecosystem of complementary products, ...cultivate...an ecosystem of complementary products, |
| capabilities, and services.... It is therefore a key principle capabilities, and services.... It is therefore a key principle |
| that the Eclipse Development Process ensures that the projects are that the Eclipse Development Process ensures that the projects are |
| managed for the benefit of both the open source community and the managed for the benefit of both the open source community and the |
| ecosystem members. To this end, all Eclipse projects are required ecosystem members. To this end, all Eclipse projects are required |
| to: to: |
| |
| communicate their project plans and plans for new features (major communicate their project plans and plans for new features (major |
| and minor) in a timely, open and transparent manner; and minor) in a timely, open and transparent manner; |
| create platform quality frameworks capable of supporting the create platform quality frameworks capable of supporting the |
| building of commercial grade products on top of them; building of commercial grade products on top of them; |
| ship extensible, exemplary tools which help enable a broad ship extensible, exemplary tools which help enable a broad |
| community of users; and community of users; and |
| participate in the annual Roadmap process to ensure maximum participate in the annual Roadmap process to ensure maximum |
| transparency and bi-directional communication with the ecosystem. transparency and bi-directional communication with the ecosystem. |
| |
| 2.3 Three Communities 2.3 Three Communities |
| Essential to the Purposes of the Eclipse Foundation is the development | Essential to the Purposes of the Eclipse Foundation is the |
| of three inter-related communities around each Project: | development of three inter-related communities around each Project: |
| |
| Contributors and Committers - a thriving, diverse and Contributors and Committers - a thriving, diverse and |
| active community of developers is the key component of any Eclipse active community of developers is the key component of any Eclipse |
| Project. Ideally, this community should be an open, transparent, Project. Ideally, this community should be an open, transparent, |
| inclusive, and diverse community of Committers and (non-Committer) inclusive, and diverse community of Committers and (non-Committer) |
| Contributors. Attracting new Contributors and Committers to an open Contributors. Attracting new Contributors and Committers to an open |
| source project is time consuming and requires active recruiting, not source project is time consuming and requires active recruiting, not |
| just passive "openness". The Project Leadership must make reasonable just passive "openness". The Project Leadership must make reasonable |
| efforts to encourage and nurture promising new Contributors. efforts to encourage and nurture promising new Contributors. |
| |
| Projects must have the diversity goals to ensure diversity of | Projects must have diversity goals to ensure diversity of thought |
| thought and avoiding relying on any one company or organization. At th | and avoid relying on any one company or organization. At the same time |
| same time, we acknowledge that enforcing a particular diversity metric | we acknowledge that enforcing a particular diversity metric is a poor |
| is a poor way to achieve these goals; rather we expect the project | way to achieve these goals; rather we expect the project leadership to |
| leadership to help the diversity evolve organically. | help the diversity evolve organically. |
| Diversity is a means to an end, not an end in itself, thus Diversity is a means to an end, not an end in itself, thus |
| diversity goals will differ by project based on the other diversity goals will differ by project based on the other |
| accomplishments of the project(s). accomplishments of the project(s). |
| Project are required to explain their diversity efforts and | Projects are required to explain their diversity efforts and |
| accomplishments during Reviews. accomplishments during Reviews. |
| |
| |
| Users - an active and engaged user community is Users - an active and engaged user community is |
| proof-positive that the Project's exemplary tools are useful and proof-positive that the Project's exemplary tools are useful and |
| needed. Furthermore, a large user community is one of the key factors needed. Furthermore, a large user community is one of the key factors |
| in creating a viable ecosystem around an Eclipse project, thus in creating a viable ecosystem around an Eclipse project, thus |
| encouraging additional open source and commercial organizations to encouraging additional open source and commercial organizations to |
| participate. Like all good things, a user community takes time and participate. Like all good things, a user community takes time and |
| effort to bring to fruition, but once established is typically effort to bring to fruition, but once established is typically |
| self-sustaining. self-sustaining. |
| Adopters - an active and engaged adopter/plug-in developer Adopters - an active and engaged adopter/plug-in developer |
| community is the only way to prove that an Eclipse project is providin community is the only way to prove that an Eclipse project is providin |
| extensible frameworks and extensible tools accessible via documented extensible frameworks and extensible tools accessible via documented |
| APIs. Reuse of the frameworks within the companies that are APIs. Reuse of the frameworks within the companies that are |
| contributing to the project is necessary, but not sufficient to contributing to the project is necessary, but not sufficient to |
| demonstrate an adopter community. Again, creating, encouraging, and demonstrate an adopter community. Again, creating, encouraging, and |
| nurturing an adopter community outside of the Project's developers nurturing an adopter community outside of the Project's developers |
| takes time, energy, and creativity by the Project Leadership, but is takes time, energy, and creativity by the Project Leadership, but is |
| essential to the Project's long-term open source success. essential to the Project's long-term open source success. |
| |
| The Eclipse community considers the absence of any one or more of thes | The Eclipse community considers the absence of any one or more of |
| communities as proof that the Project is not sufficiently open, | these communities as proof that the Project is not sufficiently open, |
| transparent, and inviting, and/or that it has emphasized tools at the transparent, and inviting, and/or that it has emphasized tools at the |
| expense of extensible frameworks or vice versa. expense of extensible frameworks or vice versa. |
| 2.4 Clear, Concise, 2.4 Clear, Concise, |
| and Evolving and Evolving |
| It is an explicit goal of the Development Process to be as clear and 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 concise as possible so as to help the Project teams navigate the |
| complexities, avoid the pitfalls, and become successful as quickly as complexities, avoid the pitfalls, and become successful as quickly as |
| possible. possible. |
| This document imposes requirements and constraints on the operation This document imposes requirements and constraints on the operation |
| of the Projects, and it does so on behalf of the larger Eclipse of the Projects, and it does so on behalf of the larger Eclipse |
| community. It is an explicit goal of the Development Process to provid community. It is an explicit goal of the Development Process to provid |
| as much freedom and autonomy to the Projects as possible while ensurin as much freedom and autonomy to the Projects as possible while ensurin |
| the collective qualities benefit the entire Eclipse community. the collective qualities benefit the entire Eclipse community. |
| Similarly, this document should not place undue constraints on the Similarly, this document should not place undue constraints on the |
| EMO or the Board that prevent them from governing the process as EMO or the Board that prevent them from governing the process as |
| necessary. We cannot foresee all circumstances and as such should be necessary. We cannot foresee all circumstances and as such should be |
| cautious of being overly prescriptive and/or requiring certain fixed cautious of being overly prescriptive and/or requiring certain fixed |
| metrics. metrics. |
| The frameworks, tools, projects, processes, community, and even the The frameworks, tools, projects, processes, community, and even the |
| definition of Quality continues to, and will continue to, evolve. definition of Quality continues to, and will continue to, evolve. |
| Creating rules or processes that force a static snapshot of any of Creating rules or processes that force a static snapshot of any of |
| these is detrimental to the health, growth, and ecosystem impact of these is detrimental to the health, growth, and ecosystem impact of |
| Eclipse. Eclipse. |
| Part of the strength of this document is in what it does not say, Part of the strength of this document is in what it does not say, |
| and thus opens for community definition through convention, guidelines and thus opens for community definition through convention, guidelines |
| and public consultation. A document with too much structure becomes to and public consultation. A document with too much structure becomes to |
| rigid and prevents the kind of innovation and change we desire for rigid and prevents the kind of innovation and change we desire for |
| Eclipse. In areas where this document is vague, we expect the Projects Eclipse. In areas where this document is vague, we expect the Projects |
| and Members to engage the community-at-large to clarify the current and Members to engage the community-at-large to clarify the current |
| norms and expectations. norms and expectations. |
| 3. Requirements 3. Requirements |
| This document and any additional criteria as established by the EMO This document and any additional criteria as established by the EMO |
| contain requirements, recommendations, and suggestions. | contains requirements, recommendations, and suggestions. |
| <span style= <span style= |
| "margin-right:6px; margin-top:5px; float:left; color:ivory; background "margin-right:6px; margin-top:5px; float:left; color:ivory; background |
| RRequired - Certain responsibilities and behaviors are RRequired - Certain responsibilities and behaviors are |
| required of participants in Eclipse open source projects. Projects tha required of participants in Eclipse open source projects. Projects tha |
| fail to perform the required behaviors will be terminated by the EMO. fail to perform the required behaviors will be terminated by the EMO. |
| In keeping with the Guiding Principles, the number of requirements mus In keeping with the Guiding Principles, the number of requirements mus |
| be kept to an absolute minimum. be kept to an absolute minimum. |
| <span style= <span style= |
| "margin-right:6px; margin-top:5px; float:left; color:ivory; background "margin-right:6px; margin-top:5px; float:left; color:ivory; background |
| GGuideline - Other responsibilities and behaviors are GGuideline - Other responsibilities and behaviors are |
| recommended best practices. Collectively, we have learned that Project recommended best practices. Collectively, we have learned that Project |
| are more likely to be successful if the team members and leaders follo are more likely to be successful if the team members and leaders follo |
| these recommendations. Projects are strongly encouraged to follow thes these recommendations. Projects are strongly encouraged to follow thes |
| recommendations, but will not be penalized by this Process if they do recommendations, but will not be penalized by this Process if they do |
| not. not. |
| 3.1 Requirements and 3.1 Requirements and |
| Guidelines Guidelines |
| This document is entirely composed of requirements. In addition to the | This document is entirely composed of requirements. In addition to |
| requirements specified in this Development Process, the EMO is | the requirements specified in this Development Process, the EMO is |
| instructed to clarify, expand, and extend this Process by creating a instructed to clarify, expand, and extend this Process by creating a |
| set of Eclipse Project Development Guidelines to advance the creation, set of Eclipse Project Development Guidelines to advance the creation, |
| evolution, promotion, and support of the Eclipse Platform and to evolution, promotion, and support of the Eclipse Platform and to |
| cultivate both an open source community and an ecosystem of cultivate both an open source community and an ecosystem of |
| complementary products and services. complementary products and services. |
| The EMO is not permitted to override or ignore the requirements The EMO is not permitted to override or ignore the requirements |
| listed in this document without the express written endorsement of the listed in this document without the express written endorsement of the |
| Board of Directors. Board of Directors. |
| 4. Structure and | 4. Project Structure and |
| Organization Organization |
| The Eclipse Projects are organized hierarchically. The top of the | |
| hierarchy are the set of Top Level Projects. Each Top Level | This version of the document adds the word "Project" to the title of |
| Project contains one or more Sub-Projects. Each Sub-Project | this section to better qualify that it discusses the structure and |
| contains zero or more Sub-Projects. The term Project refers to | organization of projects. The <a href= |
| either a Top-Level Project or a Sub-Project. Projects may be referred | "#4_Structure_and_Organization">previous version of this document |
| to as Sub-Projects or Components, but the choice of common name does | defined notions of "Operating" and "Container" Projects. These notions |
| not change the characteristics of the Project. | have been abandoned in favour of a more generalized notion of Project. |
| Projects with no child Projects are Operating Projects. | Under this new structure, projects can opt to function as Operating |
| Projects with one or more child Projects are Container Projects. | Projects by choosing not to maintain a code repository. |
| > See <a href= |
| > "https://bugs.eclipse.org/bugs/show_bug.cgi?id=301065">Bug |
| > 301065. |
| > |
| > 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 help |
| > developers expose their hard work to a broad audience of consumers. |
| > Eclipse Projects are organized hierarchically. A special type of |
| > Project, Top-Level 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 Sub-Project. 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. |
| The descendants of a Project are the Project itself and The descendants of a Project are the Project itself and |
| transitive closure of its child Projects. The top parent of a transitive closure of its child Projects. The top parent of a |
| Project is the Top-Level Project at the top of the hierarchy. Project is the Top-Level Project at the top of the hierarchy. |
| Projects are the unit entity for: Projects are the unit entity for: |
| |
| Committers Committers |
| Code and Releases Code and Releases |
| IP Records IP Records |
| Community Awareness Community Awareness |
| |
| As defined by the <a href= As defined by the <a href= |
| "/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf#page=19">Ecl "/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf#page=19">Ecl |
| Bylaws - Article VII, the Eclipse Management Organization Bylaws - Article VII, the Eclipse Management Organization |
| (EMO) consists of the Foundation staff and the Councils. The term (EMO) consists of the Foundation staff and the Councils. The term |
| EMO(ED), when discussing an approval process, refers to the EMO(ED), when discussing an approval process, refers to the |
| subset of the EMO consisting of the Executive Director and whomever he subset of the EMO consisting of the Executive Director and whomever he |
| or she may delegate that specific approval authority to. or she may delegate that specific approval authority to. |
| 4.1 Committers 4.1 Committers |
| An Operating Project has a self-managing set of Committers. The | |
| Committers of an Operating Project have the exclusive right to elect | The previous version of this document |
| new Committers to their Project -- no other group, including a parent | introduced a notion of a "union" of committers that was never fully |
| > defined or utilized. That notion has been removed. |
| > We attempt to make it clear that each project has exactly one set of |
| > committers. This has been driven by the negative experiences of the |
| > past in attempting to manage multiple committer groups in a single |
| > project. We further attempt to make it clear that there is no roll-up |
| > of committers; a committer in a sub-project is not automatically a |
| > committer in a parent project. |
| > |
| > 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 <a href= |
| > "#6_3_8_Restructuring_Review">Restructuring Review) into two or |
| > more Sub-Projects. |
| > 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. Project, can force a Project to accept a new Committer. |
| The set of Committers of a Container Project is the union of all the | There is no roll-up of committers: the set of committers on a |
| Committers of the child Projects. | 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 sub-projec |
| > does not give you any automatic rights on the "parent" project). |
| > 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. |
| > |
| 4.2 Code and Releases 4.2 Code and Releases |
| Each Operating Project owns and maintains a collection of source code | |
| and/or web pages. | The previous version of this |
| Each Operating Project is the finest grained unit of infrastructure | document restricted code ownership to the former notion of "Operating" |
| supplied by the Eclipse Foundation. Each Operating Project has a singl | projects. With the generalization of projects, it is now possible for |
| Unix group of its Committers that provides write-access to the | project at any level in the hierarchy to have (or not have) code. |
| Project's files. Each Operating Project has a single bugzilla componen | This version of the document clarifies that a project in the |
| for its bugs. ... The exact infrastructure provided by the Eclipse | incubation phase may make pre-1.0 releases only. |
| Foundation varies over time and is defined outside this process | |
| document. | Each Project owns and maintains a collection of resources. |
| While Operating Projects are the finest grained unit of | Resources may include source code, a project website, space on the |
| infrastructure, there are no constraints on Projects self governing | downloads server, access to build resources, and other services |
| themselves with finer-grained divisions on labor. For example, if | provided by the Eclipse Foundation infrastructure. The exact |
| Project A wants to divide its code-based into two modules, A1 and A2, | infrastructure provided by the Eclipse Foundation varies over time and |
| and have separate groups of its Committers work on each module, that's | is defined outside this process document. |
| perfectly acceptable. However, if Project A wants to have fine-grained | A project is not strictly required to make use of all the resources |
| access control for those two groups (i.e., separate unix groups), then | made available; a project might, for example, opt to not |
| Project A will need to become a Container Project and create two new | maintain a source code repository. Such a Project might operate as an |
| Sub-Projects, A.A1 and A.A2, as Operating Projects. That division will | organizational unit, or container, for several Sub-Projects. Similarly |
| require a Creation+Move Review. | a Project might opt to provide a consolidated website, build and/or |
| Container Projects do not have file infrastructure: no Unix group | download site for its Sub-Projects (the Sub-Projects would then not |
| and no repository. | require those resources for themselves). |
| > Each Project has a single Bugzilla component for its bugs. |
| Any Project in the Mature Phase may make a Release. A Project Any Project in the Mature Phase may make a Release. A Project |
| in the Incubation Phase with two Mentors may make a Release. A | in the Incubation Phase with two Mentors may make a pre-1.0 |
| Release may include the code from any subset of the Project's | Release. A Release may include the code from any subset of the |
| descendants. However, if any code is included from an Operating | Project's descendants. |
| Project, all the code from that Project must be included. In other < |
| words, an Operating Project is the level of granularity of code. < |
| 4.3 IP Records 4.3 IP Records |
| A Project at any level may receive IP clearance for contributions and | A Project at any level may receive IP clearance for contributions |
| third-party libraries. IP approval will often include the same approva | and third-party libraries. IP approval will often include the same |
| for all descendant Projects. However, IP clearance will only be grante | approval for all descendant Projects. However, IP clearance will only |
| at the most appropriate technical level thus only Operating Projects | be granted at the most appropriate technical level. |
| should request IP clearance for contributions and Container Projects < |
| may request IP clearance for third-party libraries only if a majority < |
| of their descendants need that library. < |
| 4.4 Community Awareness 4.4 Community Awareness |
| Projects are the level of communication with the larger Eclipse Projects are the level of communication with the larger Eclipse |
| community and eco-system. Projects may either have their own | community and ecosystem. Projects may either have their own |
| communications (website, mailing lists, newsgroups, etc) or they may b | communications (website, mailing lists, forums/newsgroups, etc) or the |
| part of a parent Project's communications (website, mailing list, | may be part of a parent Project's communications (website, mailing |
| newsgroups, etc). In either case, the Project is required to maintain | list, forums/newsgroups, etc). In either case, the Project is required |
| an open and public communication channel with the Eclipse community | to maintain an open and public communication channel with the Eclipse |
| including, but not limited to, project plans, schedules, design | community including, but not limited to, project plans, schedules, |
| discussions, and so on. | design discussions, and so on. |
| All Projects must make the communication channels easy to find. All Projects must make the communication channels easy to find. |
| Container Projects are further required to make the separate | Projects are further required to make the separate communication |
| communication channels of their child Projects (if any) easy to | channels of their child Projects (if any) easy to find. |
| find. < |
| Any Project in the Incubation Phase must correctly identify its Any Project in the Incubation Phase must correctly identify its |
| website and Releases. A Container Project with at least one descendant | website and Releases. A Project with at least one descendant Project i |
| Project in Incubation Phase must correctly annotate its own website so | Incubation Phase must correctly annotate its own website so as to |
| as to notify the Eclipse community that incubating Projects exist in | notify the Eclipse community that incubating Projects exist in its |
| its hierarchy. Any Release containing code from an Incubation Phase | hierarchy. Any Release containing code from an Incubation Phase projec |
| project must be correctly labeled, i.e., the Incubation Phase is viral | must be correctly labeled, i.e., the Incubation Phase is viral and |
| and expands to cover all Releases in which it is included. | expands to cover all Releases in which it is included. |
| 4.5 Scope 4.5 Scope |
| Each Top-Level Project has a Charter which describes the Each Top-Level Project has a Charter which describes the |
| purpose, Scope, and operational rules for the Top-Level Project. purpose, Scope, and operational rules for the Top-Level Project. |
| The Charter should refer to, and describe any refinements to, the The Charter should refer to, and describe any refinements to, the |
| provisions of this Development Process. The Board approves the Charter provisions of this Development Process. The Board approves the Charter |
| of each Top-Level Project. of each Top-Level Project. |
| Sub-Projects do not have separate Charters; Sub-Projects operate Sub-Projects do not have separate Charters; Sub-Projects operate |
| under the Charter of their parent Top-Level Project. under the Charter of their parent Top-Level Project. |
| All Projects have a defined Scope and all initiatives within All Projects have a defined Scope and all initiatives within |
| that Project are required to reside within that Scope. Initiatives and 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 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 par the termination of the Project. The Scope of Top-Level Projects is par |
| of the Charter, as approved by the Board of Directors of the Eclipse of the Charter, as approved by the Board of Directors of the Eclipse |
| Foundation. Foundation. |
| The Scope of a Sub-Project is defined by the initial project The Scope of a Sub-Project is defined by the initial project |
| proposal as reviewed and approved by the Project Management proposal as reviewed and approved by the Project Management |
| Committee (PMC) (as further defined below) of the Project's Committee (PMC) (as further defined below) of the Project's |
| Project's top parent and by the EMO. A Project's Scope must be a subse Project's top parent and by the EMO. A Project's Scope must be a subse |
| of its parent's Scope. of its parent's Scope. |
| 4.6 Leaders 4.6 Leaders |
| Top-Level Projects are managed by a Project Management Committee | |
| (PMC). Sub-Projects are managed by one or more Project | The previous version of this document |
| Leaders. The PMC Lead(s) of a Top-Level Project are the Project | used confusing language in an attempt to combine the discussion of PMC |
| Leader(s) of that project. | and Project Leads. This version separates these discussions in an |
| PMC Leads are approved by the Board; PMC members and Project Leads | attempt to make more explicit the process of bringing leaders on board |
| are approved by the EMO(ED). The initial Project Leadership is | and the role that the two different types of leaders play. Sections |
| appointed and approved in the Creation Review. Subsequently, additiona | 4.6.1 and 4.6.2 are new with this version of the document. |
| Project Leadership (PMC members or Sub-Project Leaders) must be electe | See <a href= |
| by the Project's Committers1 and the Board or EMO(ED) (for | "https://bugs.eclipse.org/bugs/show_bug.cgi?id=300002">Bug 300002 |
| PMC members and Sub-Project Leads respectively). In the unlikely event | and Bug |
| that a member of the Project Leadership becomes disruptive to the | 300006. |
| process or ceases to contribute for an extended period, the member may | |
| be removed by (a) if there are at least two other Project Leaders, the | There are two different types of Project leadership at Eclipse: The |
| unanimous vote of the remaining Project Leadership; or (b) unanimous | Project Management Committee (PMC) and Project Leads. Both forms of |
| vote of the Project Leadership of the parent Project. | leadership are required to: |
| 1Until such time as the Foundation portal supports | |
| Project Leader elections, an election held on the Project's developer | ensure that their Project is operating effectively by guiding the |
| mailing list will suffice. | overall direction and by removing obstacles, solving problems, and |
| Each Project's leadership is required to: | resolving conflicts; |
| < |
| ensure that the Project is operating effectively by guiding the < |
| Project's overall direction and by removing obstacles, solving < |
| problems, and resolving conflicts < |
| operate using open source rules of engagement: meritocracy, operate using open source rules of engagement: meritocracy, |
| transparency, and open participation. | transparency, and open participation; and |
| ensure that the projects and its sub-projects (if any) conform to | ensure that the Project and its Sub-Projects (if any) conform to |
| the Eclipse Foundation IP Policy and procedures. | the Eclipse Foundation IP Policy and Procedures. |
| | |
| In exceptional situations, such as Projects with zero active | The leadership for a Project is composed of the Project's Project |
| Committers or Projects with disruptive Committers and no effective | Lead(s), the leadership of the parent Project (if any) and the PMC |
| Project Leader(s), the Project Leadership Chain has the authority to | Leads and PMC Members for the Top-Level Project. |
| make changes (add, remove) to the set of Committers and/or Project | 4.6.1 Project Management Committee |
| Lead(s) of that Project. | (PMC) |
| > 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. |
| > PMC Leads are approved by the Board; PMC members are elected by the |
| > existing PMC Leads and Members, and approved by the EMO(ED). |
| > 4.6.2 Project Lead |
| > 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' |
| > Committers and approved by the Project's PMC and the EMO(ED). |
| > 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 th |
| > remaining Project Leads (if there are at least two other Project |
| > Leads), or unanimous vote of the Project's PMC. |
| > 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. |
| 4.7 Committers and 4.7 Committers and |
| Contributors Contributors |
| 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 source code < |
| repository(ies) of the Project and are expected to influence the < |
| Project's development. < |
| < |
| |
| > The previous version |
| > made specific references to the types of resources that a committer ha |
| > write access to (code, web, and Bugzilla). In this version, the |
| > discussion of the resources has been generalized. |
| |
| > 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. |
| See guidelines and See guidelines and |
| checklists for electing a new committer. checklists for electing a new committer. |
| < |
| < |
| < |
| Contributors who have the trust of the Project's Committers can, Contributors who have the trust of the Project's Committers can, |
| through election, be promoted Committer for that Project. The breadth through election, be promoted Committer for that Project. The breadth |
| of a Committer's influence corresponds to the breadth of their of a Committer's influence corresponds to the breadth of their |
| contribution. A Development Team's Contributors and Committers may (an contribution. A Development Team's Contributors and Committers may (an |
| should) come from a diverse set of organizations. A Committer has writ | should) come from a diverse set of organizations. A Committer gains |
| access to the source code repository for the Project and/or website | voting rights allowing them to affect the future of the Project. |
| and/or bug tracking system. A Committer gains voting rights allowing | Becoming a Committer is a privilege that is earned by contributing and |
| them to affect the future of the Project. Becoming a Committer is a | showing discipline and good judgment. It is a responsibility that |
| privilege that is earned by contributing and showing discipline and | should be neither given nor taken lightly, nor is it a right based on |
| good judgment. It is a responsibility that should be neither given nor | employment by an Eclipse Member company or any company employing |
| taken lightly, nor is it a right based on employment by an Eclipse | existing committers. |
| Member company or any company employing existing committers. | The election process begins with an existing Committer on the same |
| The election process for Committers uses the open and transparent | Project nominating the Contributor. The Project's Committers will vote |
| portal election system. The election process begins with an existing | for a period of no less than one week of standard business days. If |
| Committer on the same Project nominating the Contribtor. The Project's | there are at least three (3) positive votes and no negative votes |
| Committers will vote for a period of no less than one week of standard | within the voting period, the Contributor is recommended to the |
| business days. If there are at least three (3) positive votes and no | project's PMC for commit privileges. If there are three (3) or fewer |
| negative votes within the voting period, the Contributor is recommende | Committers on the Project, a unanimous positive vote of all Committers |
| to the root project's PMC for commit privileges. If there are three (3 | is substituted. If the PMC approves, and the Contributor signs the |
| or fewer Committers on the Project, a unanimous positive vote of all | appropriate Committer legal agreements established by the EMO (wherein |
| Committers is substituted. If the PMC approves, and the Contributor | at the very least, the Developer agrees to abide by the Eclipse |
| signs the appropriate Committer legal agreements established by the EM | Intellectual Property Policy), the Contributor becomes a Committer and |
| (wherein, at the very least, the Developer agrees to abide by the | is given write access to the source code for that Project. |
| Eclipse Intellectual Property Policy), the Contributor becomes a < |
| Committer and is given write access to the source code for that < |
| Project. < |
| At times, Committers may become inactive for a variety of reasons. At times, Committers may become inactive for a variety of reasons. |
| The decision making process of the Project relies on active committers The decision making process of the Project relies on active committers |
| who respond to discussions and vote in a constructive and timely who respond to discussions and vote in a constructive and timely |
| manner. The Project Leaders are responsible for ensuring the smooth manner. The Project Leaders are responsible for ensuring the smooth |
| operation of the Project. A Committer who is disruptive, does not operation of the Project. A Committer who is disruptive, does not |
| participate actively, or has been inactive for an extended period may participate actively, or has been inactive for an extended period may |
| have his or her commit status revoked by the Project Leaders. (Unless have his or her commit status revoked by the Project Leaders. (Unless |
| otherwise specified, "an extended period" is defined as "no activity otherwise specified, "an extended period" is defined as "no activity |
| for more than six months".) for more than six months".) |
| Active participation in the user newsgroup and the appropriate | Active participation in the user forums/newsgroups and the |
| developer mailing lists is a responsibility of all Committers, and is | appropriate developer mailing lists is a responsibility of all |
| critical to the success of the Project. Committers are required to | Committers, and is critical to the success of the Project. Committers |
| monitor and contribute to the user newsgroup. | are required to monitor and contribute to the user |
| > forums/newsgroups. |
| Committers are required to monitor the mailing lists associated with Committers are required to monitor the mailing lists associated with |
| the Project. This is a condition of being granted commit rights to the the Project. This is a condition of being granted commit rights to the |
| Project. It is mandatory because committers must participate in votes Project. It is mandatory because committers must participate in votes |
| (which in some cases require a certain minimum number of votes) and (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 must respond to the mailing list in a timely fashion in order to |
| facilitate the smooth operation of the Project. When a Committer is facilitate the smooth operation of the Project. When a Committer is |
| granted commit rights they will be added to the appropriate mailing granted commit rights they will be added to the appropriate mailing |
| lists. A Committer must not be unsubscribed from a developer mailing lists. A Committer must not be unsubscribed from a developer mailing |
| list unless their associated commit privileges are also revoked. list unless their associated commit privileges are also revoked. |
| Committers are required to track, participate in, and vote on, Committers are required to track, participate in, and vote on, |
| relevant discussions in their associated Projects and components. Ther relevant discussions in their associated Projects and components. Ther |
| are three voting responses: +1 (yes), -1 (no, or veto), and 0 are three voting responses: +1 (yes), -1 (no, or veto), and 0 |
| (abstain). (abstain). |
| Committers are responsible for proactively reporting problems in the Committers are responsible for proactively reporting problems in the |
| bug tracking system, and annotating problem reports with status bug tracking system, and annotating problem reports with status |
| information, explanations, clarifications, or requests for more information, explanations, clarifications, or requests for more |
| information from the submitter. Committers are responsible for updatin information from the submitter. Committers are responsible for updatin |
| problem reports when they have done work related to the problem. problem reports when they have done work related to the problem. |
| Committer, PMC Lead, Project Lead, and Council Representative(s) are Committer, PMC Lead, Project Lead, and Council Representative(s) are |
| roles; an individual may take on more than one of these roles roles; an individual may take on more than one of these roles |
| simultaneously. simultaneously. |
| 4.8 Councils 4.8 Councils |
| The three Councils defined in Bylaws section VII are comprised of The three Councils defined in Bylaws section VII are comprised of |
| Strategic members and PMC representatives. The three Councils help Strategic members and PMC representatives. The three Councils help |
| guide the Projects as follows: guide the Projects as follows: |
| |
| The Requirements Council is primarily responsible for the The Requirements Council is primarily responsible for the |
| Eclipse Roadmap. There will always be more requirements than there are Eclipse Roadmap. There will always be more requirements than there are |
| resources to satisfy them, thus the Requirements Council gathers, resources to satisfy them, thus the Requirements Council gathers, |
| reviews, and categorizes all of these incoming requirements - from the reviews, and categorizes all of these incoming requirements - from the |
| entire Eclipse ecosystem - and proposes a coherent set of Themes and entire Eclipse ecosystem - and proposes a coherent set of Themes and |
| Priorities. Priorities. |
| The Planning Council is responsible for establishing a The Planning Council is responsible for establishing a |
| coordinated Simultaneous Release (a.k.a, "the release train") that coordinated Simultaneous Release (a.k.a, "the release train") that |
| supports the Themes and Priorities in the Roadmap. The Planning Counci supports the Themes and Priorities in the Roadmap. The Planning Counci |
| is responsible for cross-project planning, architectural issues, user is responsible for cross-project planning, architectural issues, user |
| interface conflicts, and all other coordination and integration issues interface conflicts, and all other coordination and integration issues |
| The Planning Council discharges its responsibility via collaborative The Planning Council discharges its responsibility via collaborative |
| evaluation, prioritization, and compromise. evaluation, prioritization, and compromise. |
| |
| | See guidelines |
| | and checklists for the Architecture Council. |
| < |
| See guidelines and < |
| checklists for the Architecture Council. < |
| < |
| < |
| < |
| The Architecture Council is responsible for the development, The Architecture Council is responsible for the development, |
| articulation, and maintenance of the Eclipse Platform Architecture and articulation, and maintenance of the Eclipse Platform Architecture and |
| ensuring the Principles of the Development Process through mentorship. ensuring the Principles of the Development Process through mentorship. |
| Membership in the Architecture Council is per the Bylaws through Membership in the Architecture Council is per the Bylaws through |
| Strategic Membership, PMCs, and by appointment. The Architecture Strategic Membership, PMCs, and by appointment. The Architecture |
| Council will, at least annually, recommend to the EMO(ED), Eclipse Council will, at least annually, recommend to the EMO(ED), Eclipse |
| Members who have sufficient experience, wisdom, and time to be Members who have sufficient experience, wisdom, and time to be |
| appointed to the Architecture Council and serve as Mentors. Election a appointed to the Architecture Council and serve as Mentors. Election a |
| a Mentor is a highly visible confirmation of the Eclipse community's a Mentor is a highly visible confirmation of the Eclipse community's |
| respect for the candidate's technical vision, good judgement, software respect for the candidate's technical vision, good judgement, software |
| development skills, past and future contributions to Eclipse. It is a development skills, past and future contributions to Eclipse. It is a |
| role that should be neither given nor taken lightly. Appointed members role that should be neither given nor taken lightly. Appointed members |
| of the Architecture Council are appointed to two year renewable of the Architecture Council are appointed to two year renewable |
| terms. terms. |
| |
| > 4.9 Incubator Projects |
| > |
| > This version of this document formalizes the notion of an |
| > "Incubator" project. The original draft of this document attempted to |
| > restrict the number and structure of incubators, but the language was |
| > removed to allow for future flexibility. A project may have more than |
| > one incubator; an incubator project may itself have an incubator |
| > sub-project. Creating multiple incubators is expected to be atypical; |
| > attempts to create multiple incubators will be challenged by the PMC |
| > and EMO. |
| > An important requirement for an incubator is that there must be some |
| > set of committers from the parent project who are also committers on |
| > the incubator. Since incubators are never expected to graduate, they d |
| > not require mentors. |
| > |
| > 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. |
| > 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 standar |
| > incubation branding requirements and are subject to the IP due |
| > diligence rules outlined for incubating Projects. Incubators do not |
| > graduate. |
| > 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). |
| > 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). |
| > Only Top-Level Projects and Projects in the <a href= |
| > "#6_2_4_Mature">Mature phase may create an Incubator. Incubators |
| > are created via a Creation Review. |
| > Alternatively, an Incubator can be created as part of a <a href= |
| > "#6_3_2_Graduation_Review">Graduation, <a href= |
| > "#6_3_4_Promotion_Review">Promotion, or <a href= |
| > "#6_3_8_Restructuring_Review">Restructuring Review. |
| 5. Roadmap Process 5. Roadmap Process |
| The Roadmap describes the collective Eclipse Projects future direction | |
| and consists of two parts: | This section has been modified to explicitly state that project may |
| > opt to aggregate their plan with that of descendant projects. |
| > |
| > The Roadmap describes the collective Eclipse Projects future |
| > directions and consists of two parts: |
| |
| Themes and Priorities from the Requirements Council Themes and Priorities from the Requirements Council |
| Project Plans from Projects Project Plans from Projects |
| |
| The Roadmap must be consistent with the Purposes as described in Bylaw | The Roadmap must be consistent with the Purposes as described in |
| section 1.1. It is developed using the prescribed <a href= | Bylaws section 1.1. It is developed using the prescribed <a href= |
| "/org/councils/roadmap_v2_0/index.php#process">roadmap process. "/org/councils/roadmap_v2_0/index.php#process">roadmap process. |
| The Roadmap is prepared by the Councils and approved by the Board The Roadmap is prepared by the Councils and approved by the Board |
| annually. A proposed Roadmap or Roadmap update is disseminated to the annually. A proposed Roadmap or Roadmap update is disseminated to the |
| Membership at Large for comment and feedback in advance of its Membership at Large for comment and feedback in advance of its |
| adoption. This dissemination and all discussion and debate around the adoption. This dissemination and all discussion and debate around the |
| Roadmap must be held in an open and transparent public forum, such as Roadmap must be held in an open and transparent public forum, such as |
| mailing lists or newsgroups. mailing lists or newsgroups. |
| Prior to any Board vote to approve a Roadmap or Roadmap update, Prior to any Board vote to approve a Roadmap or Roadmap update, |
| every Member has the right to communicate concerns and objections to every Member has the right to communicate concerns and objections to |
| the Board. the Board. |
| The process of producing or updating the Roadmap is expected to be The process of producing or updating the Roadmap is expected to be |
| iterative. An initial set of Themes and Priorities may be infeasible t iterative. An initial set of Themes and Priorities may be infeasible t |
| implement in the desired timeframe; subsequent consideration may revea implement in the desired timeframe; subsequent consideration may revea |
| new implementation alternatives or critical requirements that alter th new implementation alternatives or critical requirements that alter th |
| team's perspective on priorities. The EMO orchestrates interaction team's perspective on priorities. The EMO orchestrates interaction |
| among and within the Councils to drive the Roadmap to convergence. among and within the Councils to drive the Roadmap to convergence. |
| This Development Process, the EMO, the Councils, and the Projects This Development Process, the EMO, the Councils, and the Projects |
| all acknowledge that the success of the Eclipse ecosystem is dependent all acknowledge that the success of the Eclipse ecosystem is dependent |
| on a balanced set of requirements and implementations. A Roadmap that on a balanced set of requirements and implementations. A Roadmap that |
| provides too large a burden on the Projects will be rejected and provides too large a burden on the Projects will be rejected and |
| ignored; similarly, a Roadmap that provides no predictable Project ignored; similarly, a Roadmap that provides no predictable Project |
| plans will be unhelpful to the business and technical plans being plans will be unhelpful to the business and technical plans being |
| created by the ecosystem. A careful balance of demands and commitments created by the ecosystem. A careful balance of demands and commitments |
| is essential to the ongoing success of the Eclipse Projects, is essential to the ongoing success of the Eclipse Projects, |
| frameworks, and ecosystem. frameworks, and ecosystem. |
| The Project Leadership is expected to ensure that their Project The Project Leadership is expected to ensure that their Project |
| Plans are consistent with the Roadmap, and that all plans, technical Plans are consistent with the Roadmap, and that all plans, technical |
| documents and reports are publicly available. To meet this requirement documents and reports are publicly available. To meet this requirement |
| each Project is required to create a transparently available Project each Project is required to create a transparently available Project |
| Plan in an EMO-defined file format that meets the following Plan in an EMO-defined file format that meets the following |
| criteria: criteria: |
| |
| Enumerates the areas of change in the frameworks and tools for each Enumerates the areas of change in the frameworks and tools for each |
| proposed Release proposed Release |
| Consistent with and categorized in terms of the themes and Consistent with and categorized in terms of the themes and |
| priorities of the Roadmap priorities of the Roadmap |
| Identifies and accommodates cross-project dependencies Identifies and accommodates cross-project dependencies |
| Addresses requirements critical to the Ecosystem and/or the Addresses requirements critical to the Ecosystem and/or the |
| Membership at Large Membership at Large |
| Advances the Project in functionality, quality, and Advances the Project in functionality, quality, and |
| performance performance |
| |
| A Project may incrementally revise their Project Plan to deliver A Project may incrementally revise their Project Plan to deliver |
| additional tasks provided that: additional tasks provided that: |
| |
| the approved Roadmap is not put in jeopardy; and the approved Roadmap is not put in jeopardy; and |
| the work is consistent with the Project Plan criteria (as described the work is consistent with the Project Plan criteria (as described |
| above) above) |
| |
| > A project may produce an aggregate plan for itself and its |
| > descendants. In this case descendents would share their ancestor's |
| > plan. |
| 6. Development Process 6. Development Process |
| All Eclipse Projects, and hence all Project Proposals, must be All Eclipse Projects, and hence all Project Proposals, must be |
| consistent with the Purposes and the then-current Roadmap. consistent with the Purposes and the then-current Roadmap. |
| Projects must work within their Scope. Projects that desire to Projects must work within their Scope. Projects that desire to |
| expand beyond their current Scope must seek an enlargement of their expand beyond their current Scope must seek an enlargement of their |
| Scope using a public Review as described below. Scope using a public Review as described below. |
| All projects are required to report their status at least quarterly All projects are required to report their status at least quarterly |
| using the <a href= using the <a href= |
| "/projects/dev_process/project-status-infrastructure.php">EMO defined "/projects/dev_process/project-status-infrastructure.php">EMO defined |
| status reporting procedures. status reporting procedures. |
| Projects must provide advanced notification of upcoming features and Projects must provide advanced notification of upcoming features and |
| frameworks via their Project Plan. frameworks via their Project Plan. |
| 6.1 Mentors 6.1 Mentors |
| New Proposals that intend to do a Release are required to have at leas | New Proposals that intend to do a Release are required to have at |
| two Mentors. New Proposals that will only Release code as part | least two Mentors. New Proposals that will only Release code as |
| of a parent Project's Release are not required to have Mentors. Mentor | part of a parent Project's Release are not required to have Mentors. |
| must be members of the Architecture Council. The Mentors (including | Mentors must be members of the Architecture Council. The Mentors |
| name, affiliation, and current Eclipse projects/roles) must be listed | (including name, affiliation, and current Eclipse projects/roles) must |
| in the Proposal. Mentors are required to monitor and advise the new | be listed in the Proposal. Mentors are required to monitor and advise |
| Project during its Incubation Phase, but are released from that duty | the new Project during its Incubation Phase, but are released from tha |
| once the Project graduates to the Mature Phase. | duty once the Project graduates to the Mature Phase. |
| The Mentors must attend the Creation and Graduation Reviews. < |
| 6.2 Project Lifecycle 6.2 Project Lifecycle |
| <img src="/projects/images/Development-process-small.gif" align= <img src="/projects/images/Development-process-small.gif" align= |
| "right"> Projects go through six distinct phases. The transitions from | "right"> |
| phase to phase are open and transparent public reviews. | Projects go through six distinct phases. The transitions from phase |
| > to phase are open and transparent public reviews. |
| 6.2.1 Pre-proposal 6.2.1 Pre-proposal |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about writing a proposal. checklists about writing a proposal. |
| | 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. |
| 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. < |
| |
| The Pre-proposal phase ends when the Proposal is published by EMO The Pre-proposal phase ends when the Proposal is published by EMO |
| and announced to the membership by the EMO. and announced to the membership by the EMO. |
| |
| 6.2.2 Proposal 6.2.2 Proposal |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about gathering support for a proposal. checklists about gathering support for a proposal. |
| < |
| < |
| < |
| The proposers, in conjunction with the destination PMC and the The proposers, in conjunction with the destination PMC and the |
| community, collaborate in public to enhance, refine, and clarify the community, collaborate in public to enhance, refine, and clarify the |
| proposal. Mentors (if necessary) for the project must be identified proposal. Mentors (if necessary) for the project must be identified |
| during this phase. during this phase. |
| |
| The Proposal phase ends with a Creation Review or a Termination | The Proposal phase ends with a <a href= |
| Review. | "#6_3_1_Creation_Review">Creation Review, or withdrawal. |
| > The Proposal may be withdrawn by the proposers. |
| > The EMO(ED) will withdraw a proposal that has been inactive for |
| > more than six months. |
| |
| 6.2.3 Incubation 6.2.3 Incubation |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about incubation. checklists about incubation. |
| | After the project has been created, the purpose of the incubation |
| | phase is to establish a fully-functioning open-source project. In this |
| < |
| After the project has been created, the purpose of the incubation phas < |
| is to establish a fully-functioning open-source project. In this < |
| context, incubation is about developing the process, the community, an context, incubation is about developing the process, the community, an |
| the technology. Incubation is a phase rather than a place: new project the technology. Incubation is a phase rather than a place: new project |
| may be incubated under any existing Project. may be incubated under any existing Project. |
| |
| The Incubation phase may continue with a Continuation Review or a The Incubation phase may continue with a Continuation Review or a |
| Release Review. Release Review. |
| Top-Level Projects cannot be incubated and can only be created from Top-Level Projects cannot be incubated and can only be created from |
| one or more existing Mature-phase Projects. one or more existing Mature-phase Projects. |
| The Incubation phase ends with a Graduation Review or a Termination The Incubation phase ends with a Graduation Review or a Termination |
| Review. Review. |
| > Designated Incubator Projects may |
| > remain perpetually in the Incubation phase; no reviews are |
| > required. |
| |
| Many Eclipse Projects are proposed and initiated by individuals with Many Eclipse Projects are proposed and initiated by individuals with |
| extensive and successful software development experience. This documen extensive and successful software development experience. This documen |
| attempts to define a process that is sufficiently flexible to learn attempts to define a process that is sufficiently flexible to learn |
| from all its participants. At the same time, however, the Incubation from all its participants. At the same time, however, the Incubation |
| phase is useful for new Projects to learn the community-defined phase is useful for new Projects to learn the community-defined |
| Eclipse-centric open source processes. Eclipse-centric open source processes. |
| | See guidelines |
| | and checklists for utilizing the Parallel IP process. |
| | Only projects that are properly identified as being in the |
| See guidelines and | incubation phase (including designated <a href= |
| checklists for utilizing the Parallel IP process. | "#4_9_Incubators">Incubator Projects) may use the Parallel IP |
| | process to reduce IP clearance process for new contributions. |
| < |
| < |
| Only projects that are properly identified as being in the incubation < |
| phase may use the Parallel IP process to reduce IP clearance process < |
| for new contributions. < |
| 6.2.4 Mature 6.2.4 Mature |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about the mature phase. checklists about the mature phase. |
| | The project team has demonstrated that they are an open-source |
| | project with an open and transparent process; an actively involved and |
| | growing community; and Eclipse Quality technology. The project is now |
| The project team has demonstrated that they are an open-source project | mature member of the Eclipse Community. Major releases continue to go |
| with an open and transparent process; an actively involved and growing | through Release Reviews. |
| community; and Eclipse Quality technology. The project is now a mature < |
| member of the Eclipse Community. Major releases continue to go through < |
| Release Reviews. < |
| |
| Mature phase projects have Releases through Release Reviews. Mature phase projects have Releases through Release Reviews. |
| A Mature Project may be promoted to a Top-Level Project through a A Mature Project may be promoted to a Top-Level Project through a |
| Promotion Review. Promotion Review. |
| A Mature Project that does not participate in a Release in given A Mature Project that does not participate in a Release in given |
| year may continue through a Continuation Review. year may continue through a Continuation Review. |
| Inactive Mature phase projects may be archived through a Inactive Mature phase projects may be archived through a |
| Termination Review. Termination Review. |
| |
| 6.2.5 Top-Level 6.2.5 Top-Level |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about being a top-level project. checklists about being a top-level project. |
| < |
| < |
| < |
| Projects that have demonstrated the characteristics of a Top-Level Projects that have demonstrated the characteristics of a Top-Level |
| Project (e.g., consistent leadership in a technical area and the Project (e.g., consistent leadership in a technical area and the |
| recruitment of a wider developer community) can be promoted to recruitment of a wider developer community) can be promoted to |
| Top-Level Project status. This promotion occurs through a Promotion Top-Level Project status. This promotion occurs through a Promotion |
| Review. Upon the successful completion of a Promotion Review, the Review. Upon the successful completion of a Promotion Review, the |
| EMO(ED) may recommend that the project be promoted to the Board of EMO(ED) may recommend that the project be promoted to the Board of |
| Directors and ask that its Charter be reviewed and approved. Directors and ask that its Charter be reviewed and approved. |
| 6.2.6 Archived 6.2.6 Archived |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists for archiving projects. checklists for archiving projects. |
| | Projects that become inactive, either through dwindling resources or |
| | by reaching their natural conclusion, are archived. Projects can reach |
| < |
| Projects that become inactive, either through dwindling resources or b < |
| reaching their natural conclusion, are archived. Projects can reach < |
| their natural conclusion in a number of ways: for example, a project 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 majo might become so popular that it is absorbed into one of the other majo |
| frameworks. Projects are moved to Archived status through a Terminatio frameworks. Projects are moved to Archived status through a Terminatio |
| Review. Review. |
| If there is sufficient community interest in reactivating an If there is sufficient community interest in reactivating an |
| Archived Project, the Project will start again with Creation Review. A Archived Project, the Project will start again with Creation Review. A |
| there must be good reasons to have moved a Project to the Archives, th there must be good reasons to have moved a Project to the Archives, th |
| Creation Review provides a sufficiently high bar to prove that those Creation Review provides a sufficiently high bar to prove that those |
| reasons are no longer valid. It also ensures that the original or reasons are no longer valid. It also ensures that the original or |
| updated project goals are still consistent with the Purposes and updated project goals are still consistent with the Purposes and |
| Roadmap. Roadmap. |
| 6.3 Reviews 6.3 Reviews |
| The Eclipse Development Process is predicated on open and transparent | |
| behavior. All major changes to Eclipse projects must be announced and | This iteration of the document removes the notion of a "review call" |
| reviewed by the membership-at-large. Major changes include the Project | in favour of a "review period" during which the community is given an |
| Phase transitions as well as the introduction or exclusion of | opportunity to comment. This acknowledges the reality that the optiona |
| significant new technology or capability. It is a clear requirement of | review calls required by the previous |
| this document that members who are monitoring the appropriate media | version of this document never actually occurred. Given |
| channels (e.g., mailing lists or RSS feeds) not be surprised by the | that there will be no review calls, references to "slides" have been |
| post-facto actions of the Projects. | removed. |
| > See <a href= |
| > "https://bugs.eclipse.org/bugs/show_bug.cgi?id=304878">Bug |
| > 304878. |
| > |
| > 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. |
| All Projects are required to participate in at least one Review per All Projects are required to participate in at least one Review per |
| year. year. |
| For each Review, the project leadership makes a presentation For each Review, the project leadership makes a presentation |
| to, and receives feedback from, the Eclipse membership. to, and receives feedback from, the Eclipse membership. |
| A Review is a fairly comprehensive process. Gathering the material A Review is a fairly comprehensive process. Gathering the material |
| for a Review and preparing the presentation is a non-trivial effort, for a Review and preparing the presentation is a non-trivial effort, |
| but the introspection offered by this exercise is useful for the but the introspection offered by this exercise is useful for the |
| Project and results are very useful for the entire Eclipse community. Project and results are very useful for the entire Eclipse community. |
| In addition, Reviews have a specific relationship to the requirements In addition, Reviews have a specific relationship to the requirements |
| of the Eclipse IP of the Eclipse IP |
| Policy. Policy. |
| All Reviews have the same general process: All Reviews have the same general process: |
| |
| Projects are responsible for initiating the appropriate reviews. Projects are responsible for initiating the appropriate reviews. |
| However, if a Project does not do so and the EMO believes a Review is 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. The | necessary, the EMO may initiate a Review on the Project's behalf. |
| Project Leader initiates a review through the portal.2 < |
| A Review then continues with the Project's Leadership requesting A Review then continues with the Project's Leadership requesting |
| that the EMO(ED) schedule the Review. that the EMO(ED) schedule the Review. |
| No less than one week in advance of the Review conference call, and | Prior to the start of the review period, the Project leadership |
| preferably at least two weeks in advance, the Project leadership | provides the EMO with review documentation. |
| provides the EMO with the archival presentation material. | |
| | The review documentation material always includes a document that |
| The presentation material always includes a summary slide | describes the review. The minimum contents of the document are |
| presentation or document. The minimum contents of the presentation are | specified by the individual Review types. |
| proscribed by the individual Review types. < |
| The presentation material must be available in a format that anyone The presentation material must be available in a format that anyone |
| in the Eclipse membership can review. For example, Microsoft Powerpoin in the Eclipse membership can review. For example, Microsoft Powerpoin |
| files are not an acceptable single format - such files may be one of | files are not an acceptable single format: such files may be one of th |
| the formats, but not the only format. Similarly for Apple Keynote file | formats, but not the only format. Similarly for Apple Keynote files an |
| and Microsoft Word files. PDF and HTML are acceptable single | Microsoft Word files. PDF and HTML are acceptable single formats. |
| formats. < |
| The presentation material must have a correct copyright statement The presentation material must have a correct copyright statement |
| and license. and license. |
| The presentation material must be archival quality. This The presentation material must be archival quality. This |
| means that the materials must be comprehensible and complete on their means that the materials must be comprehensible and complete on their |
| own without requiring explanation by a human presenter, reference to a own without requiring explanation by a human presenter, reference to a |
| wiki, or to other non-archived web pages. wiki, or to other non-archived web pages. |
| |
| |
| The EMO announces the Review schedule and makes the presentation | The EMO announces the Review schedule and makes the documentation |
| materials available to the membership-at-large. | available to the membership-at-large. |
| |
| The criteria for the successful completion of each type of Review will | The criteria for the successful completion of each type of Review |
| be documented in writing by the EMO in guidelines made available via | will be documented in writing by the EMO in guidelines made available |
| the www.eclipse.org website. Such guidelines will include, but are not | via the www.eclipse.org website. Such guidelines will include, but are |
| limited to the following: | not limited to the following: |
| |
| Clear evidence that the project has vibrant committer, adopter and Clear evidence that the project has vibrant committer, adopter and |
| user communities as appropriate for the type of Review. user communities as appropriate for the type of Review. |
| Reasonable diversity in its committer population as appropriate for Reasonable diversity in its committer population as appropriate for |
| the type of Review. Diversity status must be provided not only as the type of Review. Diversity status must be provided not only as |
| number of people/companies, but also in terms of effort provided by number of people/companies, but also in terms of effort provided by |
| those people/companies. those people/companies. |
| Documented completion of all required due diligence under the Documented completion of all required due diligence under the |
| Eclipse IP Eclipse IP |
| Policy. Policy. |
| For Continuation, Graduation and Release Reviews, the project must For Continuation, Graduation and Release Reviews, the project must |
| have a current project plan, in the format specified by the EMO, have a current project plan, in the format specified by the EMO, |
| available to the community. available to the community. |
| Balanced progress in creating both frameworks and extensible, Balanced progress in creating both frameworks and extensible, |
| exemplary tools. exemplary tools. |
| Showcase the project's quality through project-team chosen metrics Showcase the project's quality through project-team chosen metrics |
| and measures, e.g., coupling, cyclomatic complexity, test/code and measures, e.g., coupling, cyclomatic complexity, test/code |
| coverage, documentation of extensions points, etc. coverage, documentation of extensions points, etc. |
| |
| 2Until such time as the Foundation portal supports | The Review period is open for no less than one week and usually no |
| initiating Reviews, email to the <a href= | more than two weeks of generally accepted business days. |
| "mailto:emo@eclipse.org">EMO will suffice. | |
| The Review itself: < |
| < |
| The Review is open for no less than one week and usually no more < |
| than two weeks of generally accepted business days. This is the < |
| Review period. < |
| The Review begins with the EMO's posting of the review materials at The Review begins with the EMO's posting of the review materials at |
| the start of the Review period, and ends with either the end of the | the start of the Review period |
| Review period or (see below) an optional conference call or other < |
| conference technology (e.g., web conferencing) so long as the < |
| technology is available to all members and incurs no additional costs < |
| to the attendees. < |
| The proper functioning of the Eclipse Development Process is The proper functioning of the Eclipse Development Process is |
| contingent on the active participation of the Eclipse Members and contingent on the active participation of the Eclipse Members and |
| Committers, especially in Reviews, thus each Review has an Committers, especially in Reviews, thus each Review has an |
| EMO-designated discussion and feedback communication channel: a EMO-designated discussion and feedback communication channel: a |
| newgroup, a mailing list, or some other public forum. | forum/newgroup, a mailing list, or some other public forum. |
| If a Committer election is required for a Review (for example, for If a Committer election is required for a Review (for example, for |
| a Move Review), then it is held simultaneously with the Review period. | a Creation Review), then it is |
| Thus the election and the Review will end at the same time, allowing | held simultaneously with the Review period. Thus the election and the |
| quick and efficient provisioning of the resulting Project. | Review will end at the same time, allowing quick and efficient |
| Simultaneously with the opening of the Review, a date and time for | provisioning of the resulting Project. |
| the optional conference call is announced. The call date shall be no < |
| less than the next day and no more than one week of standard business < |
| days after the last day of the Review. (For example, if the Review run < |
| from Wednesday the 4th through Tuesday the 10th, the call may be < |
| previously scheduled for any time from Wednesday the 11th through < |
| Wednesday the 18th.) < |
| The default is that the optional conference call not be held. However, < |
| during the Review period, any Eclipse Member with voting rights may < |
| request, via the Review's public communication channel, that the < |
| conference call be held. If any such requests exist at the end of the < |
| Review period, the conference call is held at its previously scheduled < |
| date and time. < |
| During the conference call, the Project Leadership (or EMO < |
| appointed Project representative) provides a brief summary of the < |
| reasons and justifications for the phase transition followed by a < |
| question and answer session. < |
| The EMO(ED) approves or fails the Review based on the public The EMO(ED) approves or fails the Review based on the public |
| comments, the scope of the Project, and the Purposes of the Eclipse comments, the scope of the Project, and the Purposes of the Eclipse |
| Foundation as defined in the Bylaws. The EMO(ED) announces the result | Foundation as defined in the Bylaws. |
| in the defined Review communication channel. | The Review ends with the announcement of the results in the defined |
| > Review communication channel (the EMO(ED) will request that the Projec |
| > Lead make this announcement). |
| |
| If any Member believes that the EMO has acted incorrectly in If any Member believes that the EMO has acted incorrectly in |
| approving or failing a Review may appeal to the Board to review the approving or failing a Review may appeal to the Board to review the |
| EMO's decision. EMO's decision. |
| 6.3.1 Creation Review 6.3.1 Creation Review |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about Creation Reviews. checklists about Creation Reviews. |
| < |
| < |
| < |
| The purpose of the Creation Review is to assess the community and The purpose of the Creation Review is to assess the community and |
| membership response to the proposal, to verify that appropriate membership response to the proposal, to verify that appropriate |
| resources are available for the project to achieve its plan, and to resources are available for the project to achieve its plan, and to |
| serve as a committer election for the project's initial Committers. Th serve as a committer election for the project's initial Committers. Th |
| Eclipse Foundation strives not to be a repository of ''code dumps'' an | Eclipse Foundation strives not to be a repository of "code dumps" and |
| thus projects must be sufficiently staffed for forward progress. thus projects must be sufficiently staffed for forward progress. |
| The Creation Review archival documents must include short nomination | The Creation Review documents must include short nomination bios of |
| bios of the proposed initial committers. These bios should discuss | the proposed initial committers. These bios should discuss their |
| their relationship to, and history with, the incoming code and/or thei | relationship to, and history with, the incoming code and/or their |
| involvement with the area/technologies covered by the proposal. The involvement with the area/technologies covered by the proposal. The |
| goal is to help keep any legacy contributors connected to new project goal is to help keep any legacy contributors connected to new project |
| and explain that connection to the current and future Eclipse and explain that connection to the current and future Eclipse |
| membership, as well as justify the initial Committers' participation i membership, as well as justify the initial Committers' participation i |
| a meritocracy. (See [<a href= | a meritocracy. |
| "http://mail-archives.apache.org/mod_mbox/incubator-general/200610.mbo < |
| 6.3.2 Graduation Review 6.3.2 Graduation Review |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about Graduation Reviews. checklists about Graduation Reviews. |
| < |
| < |
| < |
| The purpose of the Graduation Review is to confirm that the Project The purpose of the Graduation Review is to confirm that the Project |
| is/has: is/has: |
| |
| a working and demonstratable code base of sufficiently high | a working and demonstrable code base of sufficiently high |
| quality quality |
| active and sufficiently diverse communities appropriate to the size active and sufficiently diverse communities appropriate to the size |
| of the graduating code base: adopters, developers, and users of the graduating code base: adopters, developers, and users |
| operating fully in the open following the Principles and Purposes operating fully in the open following the Principles and Purposes |
| of Eclipse of Eclipse |
| a credit to Eclipse and is functioning well within the larger a credit to Eclipse and is functioning well within the larger |
| Eclipse community Eclipse community |
| |
| The Graduation Review is about the phase change from Incubation Phase | The Graduation Review is about the phase change from Incubation |
| to Mature Phase. If the Project and/or some of its code is | Phase to Mature Phase. If the Project and/or some of its code is |
| simultaneously relocating to another Project, the Graduation Review simultaneously relocating to another Project, the Graduation Review |
| will be combined with a Move Review. | will be combined with a <a href= |
| > "#6_3_8_Restructuring_Review">Restructuring Review. |
| 6.3.3 Release Review 6.3.3 Release Review |
| < |
| < |
| < |
| See guidelines and See guidelines and |
| checklists about Release Reviews. checklists about Release Reviews. |
| | 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 |
| The purposes of a Release Review are: to summarize the accomplishments | remaining quality and/or architectural issues, and to verify that the |
| of the release, to verify that the IP Policy has been followed and all | project is continuing to operate according to the Principles and |
| approvals have been received, to highlight any remaining quality and/o | Purposes of Eclipse. |
| architectural issues, and to verify that the project is continuing to < |
| operate according to the Princples and Purposes of Eclipse. < |
| 6.3.4 Promotion Review 6.3.4 Promotion Review |
| The purpose of a Promotion Review is to determine if the Project has The purpose of a Promotion Review is to determine if the Project has |
| demonstrated the characteristics of a Top-Level Project, e.g., demonstrated the characteristics of a Top-Level Project, e.g., |
| consistent leadership in a technical area and the recruitment of a consistent leadership in a technical area and the recruitment of a |
| wider developer community. The Project will already be a wider developer community. The Project will already be a |
| well-functioning Mature Eclipse Project, so evidence to the contrary well-functioning Mature Eclipse Project, so evidence to the contrary |
| will be a negative for promotion. Top-Level Projects, both through will be a negative for promotion. Top-Level Projects, both through |
| their existance and their Council memberships, have substantial | their existence and their Council memberships, have substantial |
| influence over direction and operation of Eclipse, thus it behooves th influence over direction and operation of Eclipse, thus it behooves th |
| membership to grant Top-Level status only for merit: for demonstrated membership to grant Top-Level status only for merit: for demonstrated |
| service to the larger Eclipse eco-system. | service to the larger Eclipse ecosystem. |
| 6.3.5 Continuation 6.3.5 Continuation |
| Review Review |
| The purpose of a Continuation Review is to verify that a Proposal or 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 continues to be a viable effort and a credit to Eclipse. The |
| Project team will be expected to explain the recent technical progress Project team will be expected to explain the recent technical progress |
| and to demonstrate sufficient adopter, developer, and user support for and to demonstrate sufficient adopter, developer, and user support for |
| the Project. The goal of the Continuation Review is to avoid having the Project. The goal of the Continuation Review is to avoid having |
| inactive projects looking promising but never actually delivering inactive projects looking promising but never actually delivering |
| extensible frameworks and exemplary tools to the ecosystem. extensible frameworks and exemplary tools to the ecosystem. |
| 6.3.6 Termination 6.3.6 Termination |
| Review Review |
| < |
| < |
| < |
| See <a href= See <a href= |
| "http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Informatio "http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Informatio |
| Termination Review "How To" for more information. Termination Review "How To" for more information. |
| | The purpose of a Termination Review is to provide a final |
| | opportunity for the Committers and/or Eclipse membership to discuss th |
| | proposed withdrawal of a Proposal or archiving of a Project. The |
| The purpose of a Termination Review is to provide a final opportunity | desired outcome is to find sufficient evidence of renewed interest and |
| for the Committers and/or Eclipse membership to discuss the proposed | resources in keeping the Project or Proposal active. |
| withdrawl 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. < |
| 6.3.7 Move Review 6.3.7 Move Review |
| | A Move Review is considered to be a special type of <a href= |
| | "#6_3_8_Restructuring_Review">Restructuring Review. |
| < |
| See <a href= < |
| "http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Informatio < |
| Move Review "How To" for more information about Move Reviews. < |
| < |
| < |
| < |
| The purpose of a Move Review is to verify that there are no IP Legal < |
| impediments to the proposed move of code from one Project to another < |
| Project, and to act as an election (if necessary) for the Committers < |
| who are being added to the new Project. < |
| There are four Move Review cases: < |
| < |
| A subset of code is moving out of one Project (A) and into another < |
| Project (B). -- Project B's Committers may not have new committers < |
| imposed upon them, thus project B's Committers must elect (the subset < |
| of) Project A's Committers who are moving with the code to Project < |
| B.3 < |
| An entire Project's (A) code is moving into another Project (B) and < |
| Project A is being terminated. -- Same as above: Project B's Committer < |
| must elect Project A's Committers to committer status on Project < |
| B. < |
| An entire Project (A) is moving from one parent Project (P) to < |
| another parent Project (Q). -- No Committers are changing Operating < |
| Projects, thus no elections are necessary. < |
| Code is moving out of one Project (A) and starting a new Project < |
| (C). -- This is a Creation Review, not a Move Review. Project C < |
| committers will be defined by the Creation Review. < |
| < |
| 3Until such time as the Foundation portal supports < |
| Committer election-style voting for Move Reviews, an election held on < |
| the destination Project's developer mailing list will suffice. < |
| 6.3.8 Restructuring 6.3.8 Restructuring |
| Review Review |
| The purpose of a Restructuring Review is to verify that there are no I | |
| Legal impediments to the proposed restructuring, and to allow the | This iteration of the document provides more detail on Restructuring |
| community a chance to comment on that restructuring. Restructuring may | Reviews. It also considers a Move Review (as defined by the <a href= |
| involve splitting an existing Project into multiple Projects (typicall | "#6_3_7_Move_Review">previous version of this document) to be a |
| one Operating Project into a Container Project with multiple new | special type of a Restructuring Review. |
| Operating Sub-Projects) and/or combining existing Projects into fewer | This version of the document makes explicit a loophole that permits |
| Projects (typically multiple Operating Projects into a single Operatin | the creation of new projects without engaging in the full |
| Project). | proposal/creation process. This applies only to new project with a |
| If a Restructuring Review involves combining two or more Committer | scope that is a subset of the original project's scope. There is no |
| populations, each Committer population must elect the | explicit requirement that a project become a parent to the new |
| other3, in order to explicitly maintain the principle of not | projects. New projects can be created as siblings or elsewhere in the |
| allowing any Committer population to have new Committers imposed there | project hierarchy. In the event that a restructuring review results in |
| upon. | unrelated projects, it is expected that the scope of the original |
| > project will be adjusted accordingly. |
| > |
| > 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: |
| > |
| > Movement of significant chunks of functionality from one project to |
| > another; |
| > Modification of the project structure, e.g. combining multiple |
| > projects into a single project, or decomposing a single project into |
| > multiple projects; and/or |
| > Change of project scope. |
| > |
| > A Restructuring Review may include the movement of significant |
| > chunks of code. A move is considered significant if it has an impact o |
| > 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. |
| > Note that, regardless of whether or not a review is required, moving |
| > code from one Project to another is subject to the <a href= |
| > "/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP Policy. |
| > 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 committer |
| > 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. |
| > 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. |
| > 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. |
| > This may include: |
| > |
| > Name, description, scope, and committer lists of new projects that |
| > need to be created; |
| > Source and target locations for moves of source code |
| > directories; |
| > Reorganization of builds and downloads; |
| > Contribution questionnaires (CQs) that need to be moved or |
| > piggy-back CQs that must be created; |
| > Location of the approved IP Log; and |
| > Other information that helps the community understand the |
| > change. |
| > |
| 6.3.9 Combining Reviews 6.3.9 Combining Reviews |
| Multiple Reviews may occur simultaneous for a given Project. The most | |
| common combinations include Move+Release and Move+Graduation and | This section has been modified to explicitly allow multiple projects |
| Graduation+Release. | to participate in a single. It is possible, for example, for a project |
| > and its descendants to engage in a simultaneous Release Review. |
| > |
| > 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. |
| > It should be noted that the purpose of combining reviews is to |
| > better serve the community, rather than to reduce effort on the part o |
| > 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. |
| 6.4 Releases 6.4 Releases |
| (Most of this section is borrowed and paraphrased from the (Most of this section is borrowed and paraphrased from the |
| excellent Apache excellent Apache |
| Software Foundation Releases FAQ. The Eclipse community has many of Software Foundation Releases FAQ. The Eclipse community has many of |
| the same beliefs about Releases as does the Apache community and their the same beliefs about Releases as does the Apache community and their |
| words were already excellent. The Apache Software Foundation Releases words were already excellent. The Apache Software Foundation Releases |
| FAQ is distributed under the <a href= FAQ is distributed under the <a href= |
| "http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version "http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version |
| 2.0.) 2.0.) |
| Releases are, by definition, anything that is distributed outside of Releases are, by definition, anything that is distributed outside of |
| the Committers of a Project. If users are being directed to download a the Committers of a Project. If users are being directed to download a |
| build, then that build has been released (modulo the exceptions below) build, then that build has been released (modulo the exceptions below) |
| All Projects and Committers must obey the Eclipse Foundation All Projects and Committers must obey the Eclipse Foundation |
| requirements on approving any release. requirements on approving any release. |
| (Exception 1: nightly and integration builds) During the (Exception 1: nightly and integration builds) During the |
| process of developing software and preparing a Release, various nightl process of developing software and preparing a Release, various nightl |
| and integration builds are made available to the developer community and integration builds are made available to the developer community |
| for testing purposes. Do not include any links on the project website, for testing purposes. Do not include any links on the project website, |
| blogs, wikis, etc. that might encourage non-early-adopters to download blogs, wikis, etc. that might encourage non-early-adopters to download |
| and use nightly builds, release candidates, or any other similar and use nightly builds, release candidates, or any other similar |
| package (links aimed at early-adopters and the project's developers ar package (links aimed at early-adopters and the project's developers ar |
| both permitted and encouaged). The only people who are supposed to kno | both permitted and encouraged). The only people who are supposed to |
| about such packages are the people following the developer mailing lis | know about such packages are the people following the developer mailin |
| and thus are aware of the limitations of such builds. | list and thus are aware of the limitations of such builds. |
| (Exception 2: milestone and release candidate builds) (Exception 2: milestone and release candidate builds) |
| Projects are encouraged to use an agile development process including Projects are encouraged to use an agile development process including |
| regular milestones (for example, six week milestones). Milestones and regular milestones (for example, six week milestones). Milestones and |
| release candidates are "almost releases" intended for adoption and release candidates are "almost releases" intended for adoption and |
| testing by early adopters. Projects are allowed to have links on the testing by early adopters. Projects are allowed to have links on the |
| project website, blogs, wikis, etc. to encourage these project website, blogs, wikis, etc. to encourage these |
| outside-the-committer-circle early adopters to download and test the outside-the-committer-circle early adopters to download and test the |
| milestones and release candidates, but such communications must includ milestones and release candidates, but such communications must includ |
| caveats explaining that these are not official Releases. caveats explaining that these are not official Releases. |
| |
| Milestones are to be labeled x.yMz, e.g., 2.3M1 Milestones are to be labeled x.yMz, e.g., 2.3M1 |
| (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version |
| 2.3), etc. 2.3), etc. |
| Release candidates are to be labeled x.yRCz, e.g., Release candidates are to be labeled x.yRCz, e.g., |
| 2.3RC1 (release candidate 1 towards version 2.3). 2.3RC1 (release candidate 1 towards version 2.3). |
| Official Releases are the only downloads allowed to be labeled with Official Releases are the only downloads allowed to be labeled with |
| x.y, e.g., 0.5, 1.0, 2.3, etc. x.y, e.g., 0.5, 1.0, 2.3, etc. |
| |
| All official Releases must have a successful Release Review before | All official Releases must have a successful <a href= |
| being made available for download. | "#6_3_3_Release_Review">Release Review before being made available |
| > for download. |
| (Exception 3: bug fix releases with no new features) Bug (Exception 3: bug fix releases with no new features) Bug |
| fix releases (x.y.z, e.g., 2.3.1) with no new features over the base 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 (e.g., 2.3) are allowed to be released without an additional |
| Release Review. If a bug fix release contains new features, then the Release Review. If a bug fix release contains new features, then the |
| Project must have a full Release Review. Project must have a full Release Review. |
| Under no circumstances are builds and milestones to be used as a Under no circumstances are builds and milestones to be used as a |
| substitute for doing proper official Releases. Proper Release substitute for doing proper official Releases. Proper Release |
| management and reviews is a key aspect of Eclipse Quality. management and reviews is a key aspect of Eclipse Quality. |
| 6.5 Grievance Handling 6.5 Grievance Handling |
| When a Member has a concern about a Project, the Member will raise tha | When a Member has a concern about a Project, the Member will raise |
| concern with the Project's Leadership. If the Member is not satisfied | that concern with the Project's Leadership. If the Member is not |
| with the result, the Member can raise the concern with the parent | satisfied with the result, the Member can raise the concern with the |
| Project's Leadership. The Member can continue appeals up the Project | parent Project's Leadership. The Member can continue appeals up the |
| Leadership Chain and, if still not satisfied, thence to the EMO, then | Project Leadership Chain and, if still not satisfied, thence to the |
| the Executive Director, and finally to the Board. All appeals and | EMO, then the Executive Director, and finally to the Board. All appeal |
| discussions will abide by the Guiding Principles of being open, | and discussions will abide by the Guiding Principles of being open, |
| transparent, and public. transparent, and public. |
| Member concerns may include: Member concerns may include: |
| |
| Out of Scope. It is alleged that a Project is exceeding its Out of Scope. It is alleged that a Project is exceeding its |
| approved scope. approved scope. |
| Inconsistent with Purposes. It is alleged that a Project is Inconsistent with Purposes. It is alleged that a Project is |
| inconsistent with the Roadmap and/or Purposes. inconsistent with the Roadmap and/or Purposes. |
| Dysfunctional. It is alleged that a Project is not Dysfunctional. It is alleged that a Project is not |
| functioning correctly or is in violation of one or more requirements o functioning correctly or is in violation of one or more requirements o |
| the Development Process. the Development Process. |
| Contributor Appeal. It is alleged that a Contributor who Contributor Appeal. It is alleged that a Contributor who |
| desires to be a Committer is not being treated fairly. desires to be a Committer is not being treated fairly. |
| Invalid Veto. It is alleged that a -1 vote on a Review is Invalid Veto. It is alleged that a -1 vote on a Review is |
| not in the interests of the Project and/or of Eclipse. not in the interests of the Project and/or of Eclipse. |
| |
| A variety of grievance resolutions are available to the EMO up to, and | A variety of grievance resolutions are available to the EMO up to, |
| including, rebooting or restarting a project with new Committers and | and including, rebooting or restarting a project with new Committers |
| leadership. | and leadership. |
| 7. Precedence 7. Precedence |
| In the event of a conflict between this document and a Board-approved | In the event of a conflict between this document and a |
| project charter, the most recently approved document will take | Board-approved project charter, the most recently approved document |
| precedence. | will take precedence. |
| 8. Revisions 8. Revisions |
| As specified in the Bylaws, the EMO is responsible for maintaining thi | As specified in the Bylaws, the EMO is responsible for maintaining |
| document and all changes must be approved by the Board. | this document and all changes must be approved by the Board. |
| Due to the continued evolution of the Eclipse technology, the Due to the continued evolution of the Eclipse technology, the |
| Eclipse community, and the software marketplace, it is expected that Eclipse community, and the software marketplace, it is expected that |
| the Development Process (this document) will be reviewed and revised o the Development Process (this document) will be reviewed and revised o |
| at least an annual basis. The timeline for that review should be chose at least an annual basis. The timeline for that review should be chose |
| so as to incorporate the lessons of the previous annual coordinate so as to incorporate the lessons of the previous annual coordinate |
| release and to be applied to the next annual coordinated release. release and to be applied to the next annual coordinated release. |
| The EMO is further responsible for ensuring that all plans, The EMO is further responsible for ensuring that all plans, |
| documents and reports produced in accordance with this Development documents and reports produced in accordance with this Development |
| Process be made available to the Membership at Large via an appropriat Process be made available to the Membership at Large via an appropriat |
| mechanism in a timely, effective manner. mechanism in a timely, effective manner. |
| 8.1 Revision 2.4 | 8.1 Revision 2.5 |
| This document was approved by the Eclipse Foundation Board of Director | This document was approved by the Eclipse Foundation Board of |
| in its meeting on August 20, 2008. It replaces all previous versions. | Directors in its meeting on May 19/2010. It takes effect (replacing al |
| | previous versions) on August 1/2010. |
| > |
| > |
| > |
| > |
| > See also |
| > |
| > PDF version of this |
| > document |
| > Previous version of this document |
| > Changes made since the previous version of this |
| > document |
| > |
| > This document with |
| > comments |
| > ' ?> |
| > |
| > |
| |
| |
| |
| |
| |