Barriers for Entry

Dropping barriers to open up opportunities for contribution is a critical activity for Eclipse open source projects.

Ideally, Eclipse open source project teams should be actively soliciting contribution, growing participation in the project, and otherwise being good open source citizens. Minimally, though, Eclipse project teams must engage in practices that make is so that when potential contributors do find the project, they have a fighting chance of being successful.

Making it so that people who are outside of the development team (that is, the committers) have the ability to access the most up-to-date version of the project code is an absolute requirement. To that end, committers must push content directly into designated open repositories. Eclipse project committers must never stage to a private or semi-private repository and then “periodically sync” to the open repository; employing this sort of strategy raises a significant barrier for entry that makes it impossible for anybody else to participate.

All project committers must all have equal access to all core project resources, and there must be a path to turn contributors into committers. That path must only be as challenging as necessary, and must be based entirely on an individual’s ability to implement the Eclipse Foundation Development Process, implement the Eclipse Foundation Intellectual Property Policy, and–of course–work in collaboration with the rest of the development team while contributing high quality content to the project. Nominations for a committer election must include a merit statement that includes references (links) to specific contributions that demonstrate that the individual meets the criteria. To be clear, committer status must never be based on employment status.

Project repositories must have certain documentation. All members of the various communities that grow around your project expect to find a README file in the repository root with information about the project. We require that all projects have a CONTRIBUTING file that describes how to contribute to the project (e.g., what branches are active, how to build, that an ECA is required by contributors, etc.). It’s also become standard to expect that Git repositories a LICENSE file in the root that contains the full text of the project license. There’s more information in the handbook.

Your project should be buildable. If the means of building the project code is not obvious, the README or CONTRIBUTING file should provide the information.