Eclipse Vhant

The Bylaws of the Eclipse Foundation, define the Eclipse Foundation Development Process (EDP) as: "the document that describes how the Committers, Members, the Board of Directors, other participants in the community, and the Eclipse Management Organization (the "EMO") lead, influence, and collaborate with Eclipse Projects to achieve the Purposes", describe the maintenance of the EDP as a responsibility of the EMO and Architecture Council, and make the Eclipse Foundation Board of Directors responsible for approving changes.

The first release of the EDP was pushed to the Eclipse Foundation's servers in November 2005. Since that date, the EDP has undergone numerous updates. Development of the EDP has followed a generally closed process (notwithstanding input from the Eclipse Foundation Architecture Council); while we can argue that the process has been generally transparent, it has been neither open nor meritocratic. With this proposal, we intend to bring the development of future versions of the EDP under the EDP itself.

The Eclipse Foundation Specification Process (EFSP) extends the EDP to describe the process by which specifiations are created in open source. The EFSP was first released in 2018 and, like the EDP, has since undergone several revisions following a generally closed (selectively inclusive) process. Updates to the EFSP follow a somewhat different process form the EDP, relying on the Executive Director to convene a committee to engage in the work of gathering requirements and authoring a new draft.

We believe that using an Eclipse open source project to build the EDP and EFSP is consistent with the EDP, the Bylaws of the Eclipse Foundation, and the Eclipse Foundation's IP Policy. That is, we believe that we can operate this project in an open, transparent, and meritocratic manner as required by the EDP. More specifically, by our interpretation, there is no limitation expressed in the bylaws that prevents contributors or committers who do not represent the EMO or Architecture Council from participating in the project.

In practice, we expect that the EMO and Architecture Council will be the primary contributors to the development of the EDP. Regardless of the affiliations of the developers who contribute content, reponsibility to decide what releases of the project (if any) are adopted by the Eclipse Foundation rests with the EMO, Architecture Council, and the Board of DIrectors. That is, like any other Eclipse open source projects, the committers will decide what and when to release; but it is not necessarily the case that every release will be adopted by the Eclipse Foundation.

Likewise, the EFSP itself defines how new versions of the EFSP are created, but that definition does not prevent other contributors or committers representing other interests from participating. In practice, we expect that the EMO will be the primary contributors to the development of the EFSP, but the committee defined in by the EFSP will be the primary source of requirements and responsibile for selecting releases that will be presented to the Board of Directors for their approval and adoption by the Eclipse Foundation.

Developers who establish a pattern of contribution to this project would be good candidates to join the project as a committer, and likely also be good candidates to join the Architecture Council.