Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Development Process 2006 Revision

Revision as of 15:56, 27 October 2006 by Bjorn.eclipse.org (Talk | contribs) (Requirements)

Revision 2.2

This is a draft of a proposed revision of the official Development Process for all projects hosted by the Eclipse Foundation. The final result of this document is intended to replace the original 2003 Development Process. After this document is completed and accepted by the Board, the EMO will write a new set of guidelines and interpretations to replace the 2005 web pages [1].

This draft of the Development Process is posted for comments and feedback and assistance from the Eclipse community. You are invited to add your comments directly to this wiki page. Please note your comments with a purple border (use <div style="border: 2px solid #8E87EB; padding: 6px;"> ) and a signature. --Bjorn Freeman-Benson

It would be good to have a section that describes the changes compared to the current process. --Dani 08:56, 13 October 2006 (EDT)


Is there a summary of the issues motivating this revision? If so, please provide a URL. If not, this would seem like a good first step.-- Dave Bernstein
http://eclipse-projects.blogspot.com/2006/09/your-comments-on-eclipse-development.html says

"The goal of this revision is update the process-as-written to match the process-as-practiced. We've also added a new section about mentorship and a requirement that projects get a public review at least annually."

Two questions:

  • What are the significant differences between the process-as-written and the process-as-practiced?
  • Is the process-as-practiced in all respects superior to the process-as-written?
-- Dave Bernstein
I cannot speak for the entire community, but some of the differences which are readibly observable by watching the projects include: (i) no Validation phase; yes Incubation phase; (ii) sub-projects with sub-projects; (iii) Architecture Council is ineffective; (iv) Reviews are poorly attended; (v) the level of framework-ness (to coin a phrase) across projects is highly variable; etc. Whether the new process is superior to the old is up to the community to decide - I certainly hope that collectively we improve the process and I appreciate everyone who is taking the time to work towards that end. -- Bjorn Freeman-Benson

re "(i) no Validation phase; yes Incubation phase" - a project's Validation phase could be arbitrarily short, but the EMO is responsible for holding a Checkpoint review before the Implementation phase begins. Are Checkpoint reviews routinely held? How is an Incubation phase different than a Validation phase?

re "(ii) sub-projects with sub-projects" - where is this addressed in the proposed update?

re "(iii) Architecture Council is ineffective" - I'm extremely dissapointed to hear this. In what ways is this Council ineffective. What action has the EMO taken, and what has been their result? Where in the proposed update is this problem addressed?

re "(iv) Reviews are poorly attended" - Have you polled the Eclipse community to determine why this is the case? What did you learn? Where in the proposed update is this problem addressed?

re "(v) the level of framework-ness (to coin a phrase) across projects is highly variable; etc." -- If we're going to coin phrases, lets coin ones that are explicit and meaningful; I have no idea what "framework-ness" means; Can you be more explicit? Where in the proposed update is this problem addressed?

My impression is that the proposed update addresses few of what you cite as the differences between the process-as-written and the process-as-practiced, but contains lots of commentary on unrelated matters.

-- Dave Bernstein

Purpose

This document describes the Development Process for the Eclipse Foundation. In particular, it describes how the Membership at Large, the Board of Directors, other constituents of the Ecosystem, and the Eclipse Management Organization (EMO) lead, influence, and collaborate with Eclipse Projects to achieve these Eclipse purposes:

The Eclipse technology is a vendor-neutral, open development platform supplying

frameworks and exemplary, extensible tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself; Eclipse Platform tools are extensible in that their functionality is accessible via documented programmatic interfaces. The purpose of Eclipse Foundation Inc., (the “Eclipse Foundation”), is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an

open source community and an ecosystem of complementary products, capabilities, and services.

This document has five sections:

  1. Principles outlines the basic principles upon which the development process is based.
  2. Requirements describes the requirements that the Eclipse community has for its development process.
  3. Structure and Organization specifies the structure and organization of the projects and project community at Eclipse.
  4. Roadmap Process describes the manner by which the EMO will work with the projects to create the annual Eclipse Roadmap.
  5. Development Process outlines the lifecycle and processes required of all Eclipse projects.

Principles

The following describe the guiding principles used in developing this Development Process.

Open Source Rules of Engagement

  • Open - Eclipse is open to all; Eclipse provides the same opportunity to all. Everyone participates with the same rules; there are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.
  • Transparent - Project discussions, minutes, plans, deliberations, and other artifacts are open, public, and easily accessible.
  • Meritocracy - Eclipse is a meritocracy. The more you contribute the more responsibility you will earn. Leadership roles in Eclipse are also merit-based and earned by peer acclaim.
  • Permeable - Projects are open to new ideas; not just in words, but in fact. In other words, those outside the core can, and do, influence the project.
I have written more about what it means to be open and why we care in the first of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
I think what you mean by permeable should include the example you provided in your blog posting the first of a series of blog posts about the Development Process. Include the phrase "active listening for new ideas". -- Scott Lewis
The four terms you have chosen are not parallel in either syntax or semantics. There is redundancy in your definitions of "Open" and "Meritocracy". The word "Permeable" is misused; "Receptive" would be more appropriate to your definition. The definitions are all in need of serious sharpening. -- Dave Bernstein
We (the community writing this document) welcome suggestions and deltas. We are using a wiki for this conversation for the explicit purpose of inviting and examining such. We look forward to your suggestions for a seriously sharper set of definitions. -- Bjorn Freeman-Benson
I agree with Dave that "receptive" is more communicative of the intent than "permeable". I also agree that parallelism would improve things since each label should reflect a principle. How about these four principles: openness, transparency, meritocracy, and receptivity.-- Rich Main
Nicely parallel, Rich, but what's the rationale for separating openness and transparency? They are closely related, and could easily be combined.-- Dave Bernstein
Dave: I agree that the boundary is fuzzy at best. Maybe just call the first principle "Openness and Transparency" as a compromise and lump it all together?-- Rich Main

Quality Culture

In this context, quality means extensible frameworks and exemplary tools developed in an open, inclusive, and predictable process involving the entire community.

  • From the "consumption perspective," Eclipse Quality means good for users (exemplary tools - cool/compelling to use, indicative of what is possible) and ready for plug-in developers (deliver usable frameworks with platform-ready APIs).
  • From the "creation perspective," Eclipse Quality means working with an open, transparent and permeable process, open (and welcoming) to participation from technical leaders, regardless of affiliation.
  • From the "community perspective," Eclipse Quality is that the community perceives quality, i.e., if the frameworks and tools are good enough to be used, then they have sufficient quality.

The Eclipse projects are managed by different people and different organizations, most already experienced in software engineering. We want to ensure that we share the best practices of all our experts so that all projects benefit. We need to ensure that we have an "Eclipse committer community" rather than dozens of smaller "project committer communities".

I agree strongly with these last two sentences...but am wondering if best practice sharing should/could be introduced into dev process more explicitly than mentoring and review changes. Perhaps cross-project best practice sharing as metric of community development for projects eval? --Scott Lewis
I have written more about the Eclipse culture of quality in the second of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
Quality of Eclipse components is improved when developers / committers active in Eclipse projects reuse components and provide feedback on and testing for components being reused --Anurag Gupta
This definition of quality is vacuous. A more useful definition would establish explicit expectations, e.g. freedom from defects, fitness for use, well-documented interfaces, etc. --Dave Bernstein
Dave, I suspect you mean vacuous: devoid of substance and meaning. John Wiegand provided this wording but I will defend it anyway: (a) this is the Principles section and principles tend to be like corporate mission statements and (b) this Development Process document is not designed to enshrine specific quality metrics; two reasons: (b1) bring the community to consensus on which metrics and which values to include will would take longer than we want to spend on this document and (b2) the time and effort it takes to change this document is large enough that we would have to be very, very sure of the chosen metrics. To date the Eclipse community has not been that sure of any metric. -- Bjorn Freeman-Benson
Yes, vacuous is exactly what I meant -- and evidently what you seek. Your response is effectively "we don't have the time or energy to syndicate a meaningful definition of quality, so we'll propose a meaningless definition to which no one will object." The quality of Eclipse frameworks and tools is critical to the community in multiple dimensions. We should be explicit and aggressive here. --Dave Bernstein
At a minimum, this section should emphasize the high value placed on the quality and integration of the software that is delivered with Eclipse and the community's steadfast resolve to enforce high quality standards. This means that it will not necessarily be unusual for projects to be rejected or sent back to the drawing board. Those wishing to create projects at Eclipse need to understand that the community values the Eclipse brand as a whole over any individual project or member, regardless of their level of participation within the organization (see the principle of "openness" above). With this understanding in hand, the various review criteria should then specify the specific quality metrics that must be met and a process for enforcement. Hard questions will be asked and good answers will be required. I think that much of this is in place today, but it needs to be tightened up and the value proposition needs to be better communicated. --Rich Main
By the way, the statement above -- We need to ensure that we have an "Eclipse committer community" rather than dozens of smaller "project committer communities" -- clearly provides one aspect of what the architecture committee should be doing to bind together the various projects and break down silos. While one aspect of this is mentoring, another aspect is ensuring the overall quality and coherence of the various Eclipse projects. This statement also points to the value of the roadmap process, which can help to guide the architecture committee and hence the individual projects to work together to a common set of goals. --Rich Main

Collective Reputation

Having the Eclipse name on a project provides a certain "goodness" to the project. And having great and amazing projects under the Eclipse banner provides a certain "goodness" to Eclipse. Correspondingly, having a highly-visible poor, closed, and/or failing project under the Eclipse banner detracts from that reputation.

A certain number of failures are expected in any research and development effort, thus we do not let the fear of failure prevent us from accepting interesting project. However, it is in the community's best interest to have a well-defined process for identifying and dealing with failures when they occur.

I have written more about the Eclipse collective reputation in the third of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
What constructive action are you attempting to motivate on the part of the reader?--Dave Bernstein
I think that this section should be rolled into the Quality Culture section above as part of defining the value of the Eclipse brand. -- Rich Main

Eclipse Ecosystem

The Eclipse Foundation has the responsibility to ...cultivate...an ecosystem of complementary products, capabilities, and services.... It is therefore a key principle that the Eclipse Development Process ensures that the projects are managed for the benefit of both the open source community and the ecosystem members. To this end, all Eclipse projects are required to:

  • communicate their project plans in a timely, open and transparent manner;
  • create platform quality frameworks capable of supporting the building of commercial grade products on top of them;
  • ship extensible, exemplary tools which help enable a broad community of users; and
  • participate in the annual Roadmap process to ensure maximum transparency and communication with the ecosystem.
I have written more about the Eclipse ecosystem in the fourth of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
As I indicated in my other comment about the value of the Requirements Council to the roadmap process, I want to emphasize here that project "participation in the annual Roadmap process" is more than just a function of transparency and communication. The roadmap process should be informing the projects and not just vice versa. Sure, some degree of "bottom-up" requirements input will come through project channels like bugzilla. But, we need to make sure to maintain a top-down process for requirements input, as well. Especially as such a process can identify new areas of interest and project coordination and integration issues that might not be perceived at the individual project level. -- Rich Main

Three Communities

Essential to the Purposes of the Eclipse Foundation is the development of three inter-related communities around each Project:

  • Committers - a thriving, diverse and active community of committers is the key component of any Eclipse Project. Ideally, this community should be an open, transparent, inclusive, and diverse community of Committers, developers, and other non-Committer Contributors. Attracting new Contributors and Committers to an open source project is time consuming and requires active recruiting, not just passive "openness". The Project Leadership must go out of its way to encourage and nurture new Contributors. A Committer community comprised entirely, or even in the majority, from a single company will not be allowed to graduate from incubation.
I think requiring such high diversity for projects is right, but maybe implications should be more explicit/obvious...as this seems like a big change to me. Maybe a process changes summary? --Scott Lewis
I worry that we're trying to apply the right requirement at the wrong level -- it's practically impossible for a 4-5 committer project to include four or more different companies. (Think about the math here: To reduce a single company's involvement to, say 25% on a 4 person homogeneous team requires recruiting 12 new people -- 3X the original team -- or replacing 3 of the 4 existing committers with people from other companies. To start and graduate a four person team with a non-majority rule, you'd need 4 people from 4 different companies. None of this seems likely, so we either waive that requirement every time (bad for obvious reasons) or we simply add a "0" to our version numbers and nothing else changes (pointless at best). Instead, I'd propose we apply diversity requirements at the level of top-level projects for those that ship code, and have diversity requirements for sub-projects of Tools and Technology that match on average the graduated peer (sub) projects in those areas. Diversity of thought and avoidance of reliance on any one company/organization is clearly a goal, but we have to address the reality of how code donations and committer nuclei actually work in our community, or risk creating a bar no project ever meets.--Tim Wagner
Contributors are extremely valuable. That term should show up as a top-level notion. Perhaps just Committers/Contributors? The sentence ...Committers, developers, and other non-Committer Contributors... feels funny. There are committers and contributors no? --Jeff McAffer
Tim and Jeff both have good points. Probably a notion of desired diversity should take into account the size of the project and how many adopters/contributors there are outside the original company. For example, CompositeTable, a single SWT control I contributed to Nebula probably doesn't need more than 2-3 active committers, ever. I'd be happy if I could find one other. :-) But I would expect that it should show an active community providing technical support on the newsgroup and a number of adoptions outside projects I've worked on before it graduates into SWT. But probably it would be a good idea for a larger project like one of the tools subprojects or a top-level project to show committers from 2-4 companies.--David Orme
  • Users - an active and engaged user community is proof-positive that the Project's exemplary tools are useful and needed. Furthermore, a large user community is one of the key factors in creating a viable ecosystem around an Eclipse project, thus encouraging additional open source and commercial organizations to participate. Like all good things, a user community takes time and effort to bring to fruition, but once established is typically self-sustaining.
I think Users should be listed first, then Adopters, then Contributers, then Committers. The "circle" of participation, I think it was in the "Contributing to Eclipse" book, would be a good diagram to have here. --Ed Burnette
I think that diversity is essential. Visual Editor doesn't have much and now development has severely slowed now that the company supplying most committers has decided that VE isn't a priority. --David Orme
I, too, am strongly in favor of diverse project teams. However, I do not think that it is the place of the development process document to mandate a certain level of diversity. The current development process leaves room for the EMO to provide project creation guidelines. It also includes ways for members to challenge projects and for the board to deal with certain types of project failures. I think that this is sufficient and provides the board with the flexibility to create certain projects of value to the overall community that might otherwise not be executed.-- Rich Main
  • Adopters - an active and engaged adopter/plug-in developer community is only way to prove that an Eclipse project is providing extensible frameworks and extensible tools accessible via documented APIs. Reuse of the frameworks within the companies that are contributing to the project is necessary, but not sufficient to demonstrate an adopter community. Again, creating, encouraging, and nurturing an adopter community outside of the Project's developers takes time, energy, and creativity by the Project Leadership, but is essential to the Project's long-term open source success.

The Eclipse community considers the absence of any one or more of these communities as proof that the Project is not sufficiently open, transparent, permeable, and inviting, and/or that it has emphasized tools at the expense of extensible frameworks or vice versa.

I have written more about the issues around a project's communities in the fifth of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
Essentially the same comment I made above: At the level of a top-level project (or an average of tools/technology projects), I agree with this. But suppose a technology project is successful in every other way except that it cannot show an adopting company outside its own community. If you don't let it graduate, it remains a pre-1.0 technology project and sends an (explicit) signal that it is not ready for production use, thus stalling or perhaps precluding additional adoption. (My company, as a concrete example, would probably not use it in that state in shipping products, and I suspect that's a typical stance.) If you graduate it anyway, you have to waive the existence-of-an-outside-adopting-community rule and render it meaningless. I think there are both chicken and egg and granularity of application problems with this as a litmus test for graduation, even though it's a good goal for a mature project to achieve. --Tim Wagner
Tim: Your concern is very valid. This is precisely why we need to be cautious here about being overly prescriptive. We need appropriate guidelines and standards, but also built in flexibility to allow the EMO and the board to "do the right thing", as needed. Maybe simply updating the will not be allowed to graduate incubation statement to include ...without EMO and board approval would fix the problem here? -- Rich Main

Clear and Concise

It is an explicit goal of the Development Process to be as clear and concise as possible so as to help the Project teams navigate the complexities, avoid the pitfalls, and become successful as quickly as possible.

Freedom and Autonomy

This document imposes requirements and constraints on the operation of the Projects, and it does so on behalf of the larger Eclipse community. It is an explicit goal of the Development Process to provide as much freedom and autonomy to the Projects as possible while ensuring the collective qualities benefit the entire Eclipse community.

I have written more about freedom and autonomy in the sixth of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
Similarly, this document should not place undue constraints on the EMO or the board that prevent them from governing the development process as they see fit. We cannot foresee all circumstances and as such should be cautious of being overly prescriptive.-- Rich Main

Evolving

The frameworks, tools, projects, processes, community, and even the definition of Quality continues to, and will continue to, evolve. Creating rules or processes that force a static snapshot of any of these is detrimental to the health, growth, and ecosystem impact of Eclipse.

Just Enough Process

The Eclipse Development Process should be "just enough" to ensure that the community's goals (quality, openness, etc), but no more - we want to make it easy and inviting for high-quality teams to build interesting software at Eclipse. The entry bar should be "just high enough" to keep Eclipse great, but no more - we want to make it easy to experiment and explore new ideas while simultaneously supporting the ecosystem with strong releases. The entry bar should be "just high enough" to prevent Eclipse from growing too fast (because too rapid growth places too much of a strain on the mentoring capacity of the existing community) yet "just low enough" to prevent it from stagnating.

  • The processes and goals should make projects:
    • Easy to propose
    • Fairly easy to create (e.g., enter incubation)
    • Kinda hard to graduate (e.g., exit incubation)
    • Pretty tough to ship
  • The processes are designed to enhance the middle ground of continued quality growth in Eclipse projects by eliminating the two undesirable endpoints:
    • an entry bar so low that it results in a random collection of low-quality projects, and
    • an entry bar so high that an insufficient number of new projects are created.
Examples to make this notion more concrete? Metrics that the project leadership can observe to determine that the project's ready for transition? -- Anurag Gupta
I have written more about having just enough process in the seventh of a series of blog posts about the Development Process. --Bjorn Freeman-Benson
The purpose of the Eclipse Development Process is to facilitate the open, colaborative development of a quality Eclipse Platform. The above section seems like commentary aimed at sugar-coating something, but I'm not exactly sure what. What is the objective here?--Dave Bernstein

Requirements

This document and any additional criteria as established by the EMO contain requirements, recommendations, and suggestions.

RRequired - Certain responsibilities and behaviors are required of participants in Eclipse open source projects. Projects that fail to perform the required behaviors will be terminated by the EMO. In keeping with the Guiding Principles, the number of requirements must be kept to an absolute minimum.

GGuideline - Other responsibilities and behaviors are recommended best practices. Collectively, we have learned that Projects are more likely to be successful if the team members and leaders follow these recommendations. Projects are strongly encouraged to follow these recommendations, but will not be penalized by this Process if they do not.

After taking commenter's advice, I modified the text above and then moved the comments to a separate page. --Bjorn Freeman-Benson

Requirements and Guidelines

This document is entirely composed of requirements. In addition to the requirements specified in this Development Process, the EMO is instructed to clarify, expand, and extend this Process by creating a set of Eclipse Project Development Guidelines to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products and services.

The EMO is not permitted to override or ignore the requirements listed in this document without the express written endorsement of the Board of Directors.

There seems to be too much emphasis on ahead-of-time requirements that goes against the Agile grain of Eclipse development so far. Some projects have carried this to an extreme, to their detriment. "Make code not specs". --Ed Burnette
Ed: I don't understand your comment. Could you explain how this process has too much emphasis on ahead-of-time requirements? Additionally, I do not believe it is the role of the EMO or this process to insist that projects be agile. We can (and do) recommend that projects follow an agile process, but in the spirit of open source, we do not require that. --Bjorn Freeman-Benson
Ed: The requirements here more pertain to how the various projects function within the broader Eclipse development process than how they are run in and of themselves. That said, the community will expect some sort of roadmap and predictability for each project release cycle. The separate project development guidelines should enumerate best practices that seek to strike the right balance.-- Rich Main

I have written more about requirements and guidelines in the eighth of a series of blog posts about the Development Process. --Bjorn Freeman-Benson

Structure and Organization

The Eclipse Projects are organized hierarchically. The top of the hierarchy are the set of Top Level Projects. Each Top Level Project contains zero or more Projects (for linguistic clarity, Projects as often referred to as Sub-Projects). Projects may contain one or more Components. Components are not independent and are managed by the enclosing Project's leadership.

As defined by the Eclipse Bylaws - Article VII, the Eclipse Management Organization (EMO) consists of the Foundation staff and the Councils. The term EMO(ED), when discussing an approval process, refers to the subset of the EMO consisting of the Executive Director and whomever he or she may delegate that specific approval authority to.

The comments below suggest adding a hyperlink. I took their advice but I chose not to delete their comments because they are not mine to delete. --Bjorn Freeman-Benson
Add a hyperlink to Bylaws section VII. -- Anurag Gupta
Unfortunately, the Bylaws is a PDF file, so the best I can do (and have now done) is a link to the Bylaws. You'll have to get to section VII yourself. --Bjorn Freeman-Benson
Hey, Bjorn... Let me teach an old dog a new trick! --Rich Main

Thanks, Rich, I didn't know that worked.

Mitch Sonies suggested the following alternative to the project structuring: (i) Top Level Projects are domain-based, packaging/collection projects. Top Level Projects do not implement new features, they just collect, package, and release features delivered by Sub Projects. (ii) Sub Projects are feature-based. Sub Projects are easy to start, narrowly scoped to a specific feature, and architecturally curated to eliminate duplicates. (iii) Sub Projects do not expand scope to include additional features; rather the interested developers start a new Sub Project for the new feature. This requires that the overhead to start a new project be very low. (iv) Top Level Project and Sub Project are poor names because Sub Projects do not have to reside under Top Level Projects. --Bjorn Freeman-Benson for Mitch Sonies

An interesting related question here is the tradeoff between projects and components. Where do we set the boundary of what project changes need to be communicated publically to the membership at large and which do not. For example, a new project needs to go through the public review process, but a new component does not - why? What is the distinction between a project and a component? Projects have leaders and component teams have leaders, so that's not the difference. Perhaps it's about what set of a code a committer is elected to; if so, then components would not be allowed to limit itself to a subset of the project's committers. (If that was desired, the component would need to be a full-fledged project.) What is the difference between what this Development Process requires that the project teams tell the membership-at-large about (through the review process) and what is just "part of working on a project"?

--Bjorn Freeman-Benson
Re "Where do we set the boundary of what project changes need to be communicated publically to the membership at large and which do not?". Attempting to codify this is unlikely to be successful. The EMO must continuously encourage PMCs to err on the side of openness. If cumulative changes to a Project warrant increased visibility and review, the EMO should initiate a review; if necessary, the governance model should be extended to empower the EMO take such actions. --Dave Bernstein
Re: If cumulative changes to a Project warrant increased visibility and review, the EMO should initiate a review; if necessary, the governance model should be extended to empower the EMO take such actions. -- I like this idea and will add a paragraph to the process section below.--Bjorn Freeman-Benson
I believe that the development process and governance model already allow for this. But, the idea that the EMO will somehow police this as a matter of course seems unlikely. The EMO has many responsibilities and limited technical view onto the projects. Typically, the only way that the EMO would get involved would be at scheduled review points or as a result of a member complaint. From a technical standpoint, this might be another area where the Architecture Committee can add value by providing technical feedback to the roadmap process during implementation. -- Rich Main

Charter

Each Top-Level Project has a Charter which describes the purpose, Scope, and operational rules for the Top-Level Project. The Charter should refer to, and describe any refinements to, the provisions of this Development Process. The Board approves the Charter of each Top-Level Project.

Sub-Projects do not have separate Charters; Sub-Projects operate under the Charter of their parent Top-Level Project.

Scope

All Projects have a defined Scope and all initiatives within that Project are required to reside within that Scope. Initiatives and code that is found to be outside the Scope of a Project may result in the termination of the Project. The Scope of Top-Level Projects is part of the Charter, as approved by the Board of Directors of the Eclipse Foundation.

The Scope of sub-projects and components is defined by the initial project proposal as reviewed and approved by the Project Management Committee (PMC) (as further defined below) of the Project's parent Top-Level Project and the EMO. A Project's Scope must be a subset of the parent Top-Level Project's Scope.

Management

Top-Level Projects are managed by a Project Management Committee (PMC). Sub-Projects are managed by one or more Project Leaders. The Project Leaders, the Project Leaders of all the Project's parent Projects, and the PMC of the Project's Top-Level parent are referred to as the Project Leadership Chain.

PMC Leads are approved by the Board; PMC members and Project Leads are approved by the EMO(ED). The initial Project Leadership is appointed and approved in the Creation Review. Subsequently, additional Project Leadership (PMC members or Project co-Leads) must be approved unanimously by the existing Project Leadership and the Board or EMO(ED) (as appropriate). 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 (a) if there are at least two other Project Leaders, then unanimous vote of the remaining Project Leadership; or (b) unanimous vote of the Project Leadership of the parent Project.

Each Project's leadership is required to:

  • ensure that the Project is operating effectively by guiding the Project's overall direction and by removing obstacles, solving problems, and resolving conflicts
  • ensure that all Project plans, technical documents and reports are publicly available and up-to-date
  • operate using open source rules of engagement: meritocracy, transparency, and open participation. These principles work together. Anyone can participate in a Project. This open interaction, from answering questions to reporting bugs to making code contributions to creating designs, enables everyone to recognize and utilize the contributions.

Active participation in the user newsgroups and the appropriate developer mailing lists is a required responsibility of all Project Leaders and is critical to the success of the Project.

There should be some discussion here about the responsibility of the project leadership to avoid operating in a silo. Not only should a project operate effectively itself, but it should also work effectively among other projects with which it has touchpoints. Alternately, it could be listed as a responsibility of the architecture council to see to it that such channels are open. I think that is the intent of the development process, as written.-- Rich Main

Project Team

Each Project has a Development Team, led by a Project Lead. 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) for the associated Project and are expected to influence the Project's development.

Contributors who have the trust of the Project's Committers can, through election, be promoted Committer for that Project using the process as specified in the Charter of the relevant Top-Level Project. The breadth of a Committer's influence corresponds to the breadth of their contribution. A Development Team's Contributors and Committers may (and should) come from a diverse set of organizations. A Committer has write access to the source code repository for the Project and/or website and/or bug tracking system. A Committer gains voting rights allowing them to affect the future of the Project. Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse Member company or any company employing existing committers.

The nomination and election process for Committers to a Project must follow the Eclipse principles by being open and transparent.

Committer, PMC Lead, Project Lead, and Council Representative(s) are roles; an individual may take on more than one of these roles simultaneously.

Councils

The three Councils defined in Bylaws section VII are comprised of Strategic members and PMC representatives. The three Councils help guide the Projects as follows:

  • The Requirements Council is primarily responsible for the Eclipse Roadmap. There will always be more requirements than there are resources to satisfy them, thus the Requirements Council gathers, reviews, and categorizes all of these incoming requirements - from the entire Eclipse ecosystem - and proposes a coherent set of Themes and Priorities.
  • The Planning Council is responsible for establishing a coordinated Simultaneous Release (a.k.a, "the release train") that supports the Themes and Priorities in the Roadmap. The Planning Council is responsible for cross-project planning, architectural issues, user interface conflicts, and all other coordination and integration issues. The Planning Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.
  • The Architecture Council is responsible for ensuring the Principles of the Development Process through mentorship. Membership in the Architecture Council is per the Bylaws through Strategic Membership, PMCs, and by appointment. The Architecture Council will, at least annually, recommend to the EMO(ED) Eclipse Members who have sufficient experience, wisdom, and time to be appointed to the Architecture Council and serve as mentors. Appointed members of the Architecture Council are appointed to three year renewable terms.

At the October 2006 Architecture Council meeting in Esslingen, the Architecture Council rejected the idea of becoming responsible for mentoring new projects. Consequently, this process will need to include a fourth Mentors Council. The rewritten sections are below. --Bjorn Freeman-Benson for the Architecture Council

  • The Architecture Council is responsible for reviewing the architecture of the Eclipse projects.
  • The Mentors Council is responsible for ensuring the Principles of the Development Process through mentorship. Membership in the Mentors Council is identical to that of the Planning and Architecture Councils described in the Bylaws through Strategic Membership, PMCs, and by appointment. The Mentors Council will, at least annually, recommend to the EMO(ED) Eclipse Members who have sufficient experience, wisdom, and time to be appointed to the Mentors Council and serve as mentors. Appointed members of the Mentors Council are appointed to three year renewable terms.
Addressing the need for mentorship with a 4th Council would be highly inappropriate. The Requirements, Planning, and Architecture Councils all have explicit roles in the Roadmap Workflow; the proposed Mentors Council would have no such role. Unlike the other three Councils, its members would not discharge their responsibilities via intra-council deliberation and collaboration. The need to mentor new projects should instead be satified by establishing an Eclipse Coaching Squad populated by distinguished contributors chosen by the EMO. Each newly-formed Project would be assigned a Coach from this Squad. --Dave Bernstein

Dave, other than eleven different letters in the words, what is the difference between a Mentors Council and an Eclipse Coaching Squad? --Bjorn Freeman-Benson

Dave beat me to the punch on this comment! The problem with adding a fourth council for mentoring is that the current councils have a certain level of authority within the development process that really does not apply to mentoring. Adding a mentoring council just muddies the waters unnecessarily. It might be better to create a mentoring working group or some such. -- Rich Main

I answered that question in my post above, Bjorn: a Mentors Council would not be involved in the Roadmap Process as are the other three councils, and unlike the other three Councils, its members would not discharge their responsibilities via intra-council deliberation and collaboration -- they would individually engage with personnel from new projects. --Dave Bernstein

Rich, Dave: I guess I'm just not seeing the difference, although perhaps that doesn't matter - this document is not my document but rather our collective document so if your reading is the consensus, I'm fine with that. I see that this document (a) does not specify a role in the Roadmap process for the Mentors Council and (b) I do envision the Mentors Council meeting for cross-project collaboration and level setting. Add to that the fact that (c) the Architecture Council hasn't had a practical role in the Roadmap for a couple of years and I don't see the difference. But that's just me. --Bjorn Freeman-Benson

I have written more about the project-sub-project structure in the ninth of a series of blog posts about the Development Process. --Bjorn Freeman-Benson

The only clues we have as to what you think a Mentor's Council would do are
  • the statement "The Mentors Council is responsible for ensuring the Principles of the Development Process through mentorship" above
  • the phrase "mentoring new projects" above
  • your recent comment that you "...envision the Mentors Council meeting for cross-project collaboration and level setting"

Cross-project collaboration seems very different than mentoring, Bjorn; on exactly what would this proposed council collaborate? When you say "level setting", exactly what levels would this council set?

If, as you say, "the Architecture Council hasn't had a practical role in the Roadmap for a couple of years", then there are two possibilities:

  • none of the proposed Roadmap Themes and Priorities have required architectural changes, and no changes have been required to maintain long-term architectural viability
  • the Architecture Council has abdicated its responsibilities, and the EMO has been negligent in not correcting the situation

In either case, it would be suboptimal to dilute and obscure the Council concept by mis-naming a group charged with providing mentorship to new projects. Clarity and consistency is as important in organization as it is in architecture.

--Dave Bernstein

Roadmap Process

Eclipse Roadmap Process Diagram

The Roadmap describes the collective Eclipse Projects future directions and consists of two parts:

  1. Themes and Priorities from the Requirements Council
  2. Simultaneous Release Plan from the Planning Council

The Roadmap must be consistent with the Purposes as described in Bylaws section 1.1. It is developed using the prescribed roadmap process. Click on the thumbnail image at right to view a visual representation of the roadmap development process.

The Roadmap is prepared by the Councils and approved by the Board annually. A proposed Roadmap or Roadmap update is disseminated to the Membership at Large for comment and feedback in advance of its adoption. This dissemination and all discussion and debate around the Roadmap must be held in an open and transparent public forum, such as mailing lists or newsgroups.

Prior to any Board vote to approve a Roadmap or Roadmap update, every Member has the right to communicate concerns and objections to the Board.

The process of producing or updating the Roadmap is expected to be iterative. An initial set of Themes and Priorities may be infeasible to implement in the desired timeframe; subsequent consideration may reveal new implementation alternatives or critical requirements that alter the team’s perspective on priorities. The EMO orchestrates interaction among and within the Councils to drive the Roadmap to convergence.

This Development Process, the EMO, the Councils, and the Projects all acknowledge that the success of the Eclipse ecosystem is dependent on a balanced set of requirements and implementations. A Roadmap that provides too large a burden on the Projects will be rejected and ignored; similarly, a Roadmap that provides no predictable Project plans will be unhelpful to the business and technical plans being created by the ecosystem. A careful balance of demands and commitments is essential to the ongoing success of the Eclipse Projects, frameworks, and ecosystem.

The Project Leadership is expected to ensure that their Project Plans are consistent with the Roadmap, and that all plans, technical documents and reports are publicly available. To meet this requirement, each Project is expected to create a transparently available Project Plan meets the following criteria:

  1. Enumerates the areas of change in the frameworks and tools for each proposed Release
  2. Consistent with and categorized in terms of the themes and priorities of the Roadmap
  3. Identifies and accommodates cross-project dependencies
  4. Addresses requirements critical to the Ecosystem and/or the Membership at Large
  5. Advances the Project in functionality, quality, and performance

A Project may incrementally revise their Project Plan to deliver additional tasks provided:

  1. the approved Roadmap is not put in jeopardy; and
  2. the work is consistent with the Project Plan criteria (as described above)
The Roadmap Process continues to be a point of contention amongst projects and members. I think it would be best to adopt a description that everyone can accept and follow; it does not help our community to have a documented Roadmap Process that we do not actually follow. For example, what are the consequences should a Project choose to change direction mid-year and not implement features that were in the original Project Plan? In a strict reading of the above section, that action would put the approved Roadmap in jeopardy - would we actually prevent the Project from doing that work? --Bjorn Freeman-Benson
Would it help to use the individual project plans as more of the basis of the Roadmap construction effort? Maybe extract themes and priorities from these plans...along with identifying cross-project dependencies...as the primary method for Roadmap construction and iterative modification. Perhaps not -- maybe this is already what is happening in the Roadmap evelopment --Scott Lewis
Input from top level projects is one of the inputs that is currently used in determining themes and priorities. Other inputs are from strategic member companies, add-provider companies, and market research / analyst discussions. Identifying cross-project dependencies mostly happens 1:1 between two projects and sometimes via the Architecture Council and / or Planning Council if multiple projects are involved. -- Anurag Gupta
A Roadmap Process that everyone accepts and follows but is completely ineffective won't help the Eclipse Community either. No Roadmap Process can eliminate contention; contention is a given. The objective is a Roadmap Process that appropropriately balances the often conflicting goals of moving Eclipse forward, and moving individual Projects forward. --Dave Bernstein
Defining a roadmap for Eclipse-as-a-whole has the potential to make the roadmap little more than apple pieisms. I'd advocate more of a project-targeted focus, where the requirement council works individually with each top-level project in turn to refine their individual plans rather than a single uber document. This would force attention to specifics and concrete items rather than "be a great platform" or "be cool" goals that provide little in the way of specifics when a project formulates its plan. There are a few horizontal/cross-cutting concerns, but they should be born out in specifics on a per-project basis. --Tim Wagner
I agree that "be a great platform" or "be cool" goals aren't meaningful drivers for an Eclipse Roadmap, but that's no reason to forgo broad initiatives that require concerted effort among the Projects. Otherwise, Eclipse will devolve to a bag of independent efforts. --Dave Bernstein
Speaking as one who originally lobbied for the creation of the Requirements Council, I have to point out here that the purpose is to allow the broader community to help define the requirements. This input should even come from "outside" sources like NASA, JP Morgan, Cisco, and others who are key users but not foundation members. Add-in Provider members can also act as proxies for gathering requirements from valuable target markets. Such input is the lifeblood of innovation and critical to the ongoing success of Eclipse. If we simply allow the individual project plans to guide the roadmap process, then Eclipse loses this valuable and strategic requirements input.-- Rich Main
For reference, I added a link above to the roadmap process. I would like to understand specifically which part of the defined roadmap process is "a point of contention". It's hard to suggest fixes for something if you don't understand where people think that it's broken. But, I have to echo Dave's comment that contention is a given. There is a necessary give and take in the requirements and planning process. The current roadmap process is intentionally designed such that the direction of Eclipse is guided by more than just the sum of the various project vectors. Without the roadmap process at all, then who is steering the "good ship Eclipse"? -- Rich Main
The contention I was referring to above is between the Requirements Council's (RC) desire to provide direction to the Projects and the Projects' desire to do their own thing. To be blunt, at times the RC has been tempted to "tell the Platform to fix bug X" but the Platform team has no obligation to do so. -- Bjorn Freeman-Benson
Bjorn: In principle, I agree with you. Telling a project team to fix a specific bug sounds like micro-management on the surface. But, it may depend on the bug in question. For example (and this is a contrived example because I doubt that it actually happened in this case), since support for the Mac is an important strategic initiative from a requriements standpoint, directing a project to work with Apple to fix SWT issues on the Mac would not be inappropriate input for the Requirements Council to provide, IMO. In fact, it should be viewed as very constructive and valuable input to guide the project team to devote resources in ways that are meaningful to the community at large. This is part of the purpose of the Requirements Council and sometimes that may end up looking like micro-management when in actuality it is reinforcement of the "receptivity" ethic. -- Rich Main
In its enumeration of the EMO's responsibilities, section 7.1 of the Eclipse Bylaws includes

"leading the Architecture Council and the Planning Council to produce a Roadmap (as defined in the then current Eclipse Development Process) that is consistent with the Purposes (as defined in Section 1.1 above)"

The Eclipse Development Process defines 4 steps in the Roadmap Process:

1. The Purposes are established in the Bylaws. The Membership at Large approves updates to the Purposes.

2. The EMO proposes an initial Roadmap or Roadmap update consistent with the Purposes.

3. The Board of Directors approves the Roadmap.

4. With the support of EMO project management, Development Teams work to the Roadmap.

The Development Process enumerates the following criteria for each Project Plan:

• Conforms to the Architecture Plan

• Consistent with the priorities and themes of the Roadmap

• Accommodates cross-project dependencies

• Addresses requirements critical to the Ecosystem and/or the Membership at Large

• Advances the Project in functionality, quality, performance

With respect to Project flexibility and autonomy, the Development Process says:

"A Project Lead is expected to work to the Project Plan, and ensure that all plans, technical documents and reports are publicly available. A Project Lead can incrementally revise their Project Plan to deliver additional Tasks provided:

• The approved Roadmap is not put in jeopardy

• The work is consistent with the Project Plan criteria (described above)"

None of the above empowers the Requirements Counci to demand that some Project correct bug X tomorrow, but the correction of a serious defect whose existence jeopardizes the Roadmap could reasonably appear in the Council's Themes and Priorities during a Roadmap Update.

The suggestion that Projects simply do their own thing is entirely inconsistent with the current Bylaws and Development Process; had that been the desired model, both documents would have been much easier to develop and syndicate! Anyone promulating this radical a change should be proposing a new set of Bylaws and a new Development Process, not an "update" to the existing model.

--Dave Bernstein

Development Process

All Eclipse Projects, and hence all Project Proposals, must be consistent with the Purposes.

Should we state here that 'All Eclipse Projects, and hence all Project Proposals, must be consistent with the Structure and Organization'? --Scott Lewis

Projects must work within their Scope. Projects that desire to expand beyond their current Scope must seek an enlargement of their Scope using a public Review as described below.

All projects are required to report their status at least quarterly using the EMO defined status reporting procedures.

Please add a hyperlink to the status reporting procedures. -- Anurag Gupta
I have added a link to the current procedures. They are subject to change and improvement. --Bjorn Freeman-Benson
We should limit this to objective information, basically what's stored in project-info files today. There *are* other things we should demand, like a project plan that's accessible from the home page and up to date and RSS feeds for build info -- but the idea of a written quarterly "memorandum to management" seems wrong.--Tim Wagner
I agree. How about removing the "quarterly" and then leaving the details to be defined in that separate document? I.e., "All projects are required to report their status on a regular basis using the EMO defined status reporting procedures.". --Bjorn Freeman-Benson
Clearly, it is critical for the community at large to have visibility into the health and progress of the projects. As much as possible, this should be automated (e.g., Project Dash). In addition, it is critical that project deliverable timelines be communicated consistently (see for example the information that is lacking in the current project timeline) and that the project plans are kept up to date. Generally speaking, any well run projects will have all of this by default and as such a separate status report would not be needed. Lack of this kind of information would indicate an unhealthy or non-transparent project. -- Rich Main

Projects must provide advanced notification of upcoming features and frameworks via their Project Plan and the appropriate transparent communication channels.

Mentors

New Proposals are required to have at least two Mentors. The Mentors must be listed in the Proposal, along with their affiliations and their Eclipse projects. Mentors must be members of the Architecture Council. Mentors are required to monitor and advise the new Project during its Incubation Phase, but are released from that requirement once the Project graduates to the Mature Phase.

Suggest: that Mentors be listed in the Proposal, along with their affiliation, Eclipse projects, and project role --Scott Lewis

The Mentors must attend the Creation and Graduation Reviews and the Mentors must vote +1 for those Reviews to be successful. If the Mentors do not attend or do not vote positively, the Creation Review cannot be successful regardless of other feedback or votes.

Project Lifecycle

Development-process.gif

Projects go through six distinct phases. The transitions from phase to phase are open and transparent public reviews.

Pre-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 and announced to the membership by the EMO.

Proposal - The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal. Mentors for the project must be identified during this phase.

  • The Proposal phase ends with a Creation Review or a Termination Review.

Incubation - After the project has been created, the purpose of the incubation phase is to establish a fully-functioning open-source project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a phase rather than a place: new projects may be incubated under any existing Top-Level Project.

  • The Incubation phase ends with a successful Graduation Review or a Termination Review.
note: the diagram does not depict this. --Jeff McAffer
  • The Incubation phase may continue with a Continuation Review.
  • Top-Level Projects cannot be incubated and can only be created from existing Mature-phase Projects.

Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.

Mature - The project team has demonstrated that they are an open-source project with an open and transparent process; an actively involved and growing community; and Eclipse Quality technology. The project is now a mature member of the Eclipse Community. Major releases continue to go through Release Reviews.

  • Mature phase projects have Releases through a Release Review.
  • A Mature Projects may be promoted to a Top-Level Project through a Promotion Review.
  • A Mature Project that does not release in given year may continue through a Continuation Review.
  • Inactive Mature phase projects may be archived through a Termination Review.

As Dave Bernstein suggested above, we should add:

  • A Mature Project which has made sufficient cumulative changes to warrant increased visibility and review should initiate an Ongoing Review to surface these new directions to the membership-at-large. --Bjorn Freeman-Benson

Top-Level - Projects that have demonstrated the characteristics of a Top-Level Project (e.g., consistent leadership in a technical area and the recruitment of a wider developer community) can be promoted to Top-Level Project status. This promotion occurs through a Promotion Review. Upon the successful completion of a Promotion Review, the EMO(ED) may recommend that the project be promoted to the Board of Directors and ask that its Charter be reviewed and approved.

Do we need to say more about TL projects? Previously we had talked about down playing the distinction. Should we set expections as to how many TLPs there would be and why someone would want to have a TLP? (ie., what are the differences/benefits) --Jeff McAffer

Archived - Projects that become inactive, either through dwindling resources or by reaching their natural conclusion, are archived. Projects can reach their natural conclusion in a number of ways: for example, a project might become so popular that it is absorbed into one of the other major frameworks. Projects are moved to Archived status through a Termination Review.

Should it be possible for a project to come out of 'Archived' and back into 'Incubation' or 'Mature'? --Scott Lewis
Yes, if there are people to reactivate the project. --Bjorn Freeman-Benson
Hmm...how is that different than a creation review? Does it matter if the project being created repurposes some existing materials? (Trying to understand what's special about adding the new transition and another type of review to the state diagram.) --Tim Wagner
Tim, you're probably right - it should just be a Creation Review - effectively a new project with some initial code from the archives.--Bjorn Freeman-Benson
I agree that an archived project should go through a Creation Review to be reactivated. There were likely good reasons why it became archived in the first place and a full creation review provides a sufficiently high bar to prove that those reasons are no longer valid. It also ensures that the original (or updated) project goals are still consistent with the overall Eclipse goals.-- Rich Main

Reviews

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.

As suggested by Dave Bernstein above: Projects are responsible for initiating the appropriate reviews. However, if a Project does not do so and the EMO believes a Review is necessary, the EMO may initiate a Review on the Project's behalf. --Bjorn Freeman-Benson

All Projects are required to have at least one Review per year.

What review does a mature project that it not releasing yearly have? Or is there a requirement to release yearly? --Jeff McAffer
Jeff: if there is no other Review in a given year, a project must have a Continuation Review (see above). There is no requirement to release yearly. --Bjorn Freeman-Benson

For each Review, the project leadership makes a presentation to, and receives feedback from, the Eclipse membership.

A Review is a fairly comprehensive process. Gathering the material for a Review and preparing the presentation is a non-trivial effort, but the introspection offered by this exercise is useful for the Project and results are very useful for the entire Eclipse community. In addition, Reviews have a specific relationship to the requirements of the Eclipse IP Policy.

All Reviews have the same general process:

  1. The Review process begins with the Project's Leadership requesting that the PMC approve the request for review.
  2. A Review then continues with the Project's Leadership requesting that the EMO(ED) schedule the Review.
  3. No less than one week in advance of the Review conference call, and preferably at least two weeks in advance, the Project leadership provides the EMO with the archival presentation material.
    1. The presentation material always includes a summary slide presentation. The minimum contents of the presentation are proscribed by the individual Review types.
    2. The presentation material must be available in a format that anyone in the Eclipse membership can review. For example, Microsoft Powerpoint files are not an acceptable single format - such files may be one of the formats, but not the only format. Similarly for Apple Keynote files and Microsoft Word files. PDF and HTML are acceptable single formats.
    3. The presentation material must have a correct copyright statement and be licensed under the EPL.
    4. The presentation material must be archival quality. This means that the materials must comprehensible and complete on their own without requiring explanation by a human presenter.
  4. The EMO announces the Review schedule and makes the presentation materials available to the membership-at-large.

The criteria for the successful completion of each type of Review will be documented in writing by the EMO in guidelines made available via the www.eclipse.org website. Such guidelines will include, but are not limited to the following:

  1. Clear evidence that the project has vibrant committer, adopter and user communities as appropriate for the type of Review.
  2. Reasonable diversity in its committer population as appropriate for the type of Review.
  3. Documented completion of all required due diligence under the Eclipse IP Policy.
  4. Balanced progress in creating both frameworks and extensible, exemplary tools.

The Review itself:

  1. Is open for no less than one week and no more than two weeks of generally accepted business days.
  2. Begins with a 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.
  3. 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.
  4. After the conference call, the Review remains active for open and transparent discussion amongst the membership-at-large via the Project-appropriate mailing lists, newsgroups, or other designated forums.
  5. At the end of the Review period, the EMO(ED) holds a public vote.
Voting procedures must be consistent with the Eclipse Bylaws. That should guide the discussion below. -- Rich Main
    1. All Eclipse members are eligible voters. For corporate members, their vote must be cast by the delegate for that member.
    2. A successful vote requires +1s from the Project's Leadership Chain.
may need to define that more clearly. How many +1s at each level? --Jeff McAffer
    1. At least three +1s from members who are not Committers on the Project and not part of the Project's Leadership Chain.
    1. No upheld -1s. An Upheld -1 is a -1 that is followed within 24 hours by open, transparent, and public justification, and that justification is accepted by the EMO. Frivolous or unjustified -1s are ignored. Reject -1s count as 0s.
  1. The EMO(ED) approves or fails the Review based on the public vote, the scope of the Project, and the Purposes of the Eclipse Foundation as defined in the Bylaws.
Various people have different thoughts about how many +1s are needed to pass a review. We'd like your opinions right here on this wiki page. Some have said 3 +1s; some have said at least 4 +1s; etc. There has also been discussion about who can vote: Eclipse members who are not on the Project? Architecture Council members? all Eclipse members? --Bjorn Freeman-Benson
I think 3 +1s. This is a significantly higher hurdle than currently (EMO+project team only). I would leave the voting up to to entire (non-project team) membership --Scott Lewis
We might include a list of criteria for specific Review types here. Not the full list for each Review type, but the essential items that are not part of the generic list above. --Bjorn Freeman-Benson
At one point we talked about requiring some number of Architecture Council votes. In the case of a graduation review, the mentors (aka arch council members) must vote +1. Should the same be true for release reviews etc. Personally I vote +1 for having required arch council representation. --Jeff McAffer
Jeff: that is explained in the "Mentors" section [2]. Perhaps it should be moved here. --Bjorn Freeman-Benson
Re: creation reviews, William Rowe on the Apache incubation mailing list has a suggestion for Apache that perhaps we should adopt for Eclipse: creation reviews must include "a short biographical on the proposed participants. [Not a] life story, but their relationship to and history with the incoming code and/or their involvement with the area/technologies covered by the proposal. ... For OSS transitions from another home, this can often be a short 'Author of the Foo container bits, see also ralphj commits to ___ and mailing list participation on dev@example.com', or 'contributing author to spec X'. ... For Corporate contributions, this has to be more detailed. At the very least, justify the individual's participation -in the code-. .. This would serve to help keep legacy contributors connected to the effort, and explain that connection to newcomers, but justify their participation in a meritocracy. It will help the project, four years down the road, do a /whois and come up with something meaningful about any of their members." --Bjorn Freeman-Benson
Scope of projects suitable for Eclipse - Not sure if this is the best place for this comment (guess we can always move it later) - I haven't seen any discussion of the scope of projects suitable for Eclipse aside from the projects needing to support users, developers and adopters (if I have missed it please point it out so I can retract my comment). There are several prominent open source communities and I think rather than try to tackle all manner of projects Eclipse should cut out a section of projects that it will develop and work with the other communities to develop other projects not appropriate for Eclipse. Cutting out a section of projects is not meant to limit people but rather meant to maintain the Eclipse brand and avoid potentially diluting it with many projects that are unrelated in any way. (i.e. Currently most projects are related by extending the IDE of being useful tool frameworks.) --Lawrence Mandel
Lawrence: the kinds of projects suitable for Eclipse are defined in the Bylaws [3] and is referenced above in the first paragraph of the "Development Process" section [4]. --Bjorn Freeman-Benson

If any Member believes that the EMO has acted incorrectly in approving or failing a Review may appeal to the Board to review the EMO's decision.

Membership Involvement

The proper functioning of the Eclipse Development Process is contingent on the active participation of the Eclipse Members and Committers. The requirement for positive votes from Members (which includes Committers) which are not involved in the project will require each project to build relationships with other participants within the Eclipse community. The process is positive biased in that Reviews give more weight to negative votes (vetoes) as opposed to requiring a majority of positive votes to proceed.

Review vote summaries will include:

  • Number and identification of all explicit positive (+1) votes
  • Number and identification of all explicit abstentions (0)
  • Number and identification of all explicit negative (-1) votes
  • A statement that all other Eclipse members have implicitly voted positively

Grievance Handling

When a Member has a concern about a Project, the Member will raise that concern with the Project's Leadership. If the Member is not satisfied with the result, the Member can raise the concern with the parent Project's Leadership. The Member can continue appeals up the Project Leadership Chain and, if still not satisfied, thence to the EMO, then the Executive Director, and finally to the Board. All appeals and discussions will abide by the Guiding Principles of being open, transparent, and public.

Member concerns may include:

  • Out of Scope. It is alleged that a Project is exceeding its approved scope.
  • Inconsistent with Purposes. It is alleged that a Project is inconsistent with the Roadmap and/or Purposes.
  • Dysfunctional. It is alleged that a Project is not functioning correctly or is in violation of one or more requirements of the Development Process.
  • Contributor Appeal. It is alleged that a Contributor who desires to be a Committer is not being treated fairly.
  • Invalid Veto It is alleged that a -1 vote on a Review is not in the interests of the Project and/or of Eclipse.

Revisions

As specified in the Bylaws, the EMO is responsible for maintaining this document and all changes must be approved by the Board.

Due to the continued evolution of the Eclipse technology, the Eclipse community, and the software marketplace, it is expected that the Development Process (this document) will be reviewed and revised on at least an annual basis. The timeline for that review should be chosen so as to incorporate the lessons of the previous annual coordinate release and to be applied to the next annual coordinated release.

The EMO is further responsible for ensuring that all plans, documents and reports produced in accordance with this Development Process be made available to the Membership at Large via an appropriate mechanism in a timely, effective manner.

Back to the top