Technology

This is a landing page for the Technology Project.

Useful Links

• Eclipse Technology Project Category
• Project Reviews
• Presentation: Technology/Ten Eclipse Projects You Haven't Heard Enough About

What do we expect from Technology Projects

Committer Elections

The trust of the existing committers is key. The fact that someone has been nominated on and vote for by the existing committers is a strong endorsement. But there is a fly in the ointment: many Eclipse projects are lacking sufficient diversity. Historically, a big part of the reason why we have pushed so hard for demonstrable contributions prior to a vote was to mitigate the risk that someone was being added to an Eclipse project simply because they've been hired or transferred at the company driving an Eclipse project. Such scenarios fly in the face of the meritocracy that we are trying to create within Eclipse projects.

The Technology PMC requires that all committer nominations include specific rationalization of the merit of the individual. At a minimum, we expect that all committer nominations include a list of bugs (including ids) that the candidate has contributed patches to, and that those patches have been accepted (committed) by an existing committer. Other acceptable types of rationalization evidence include, but are not limited to:

• Specific project mailing list participation examples (for example, cases where the nominee has made specific architectural, design, or implementation contributions).
• Unique enhancement requests entered into Bugzilla that become committed features (whether implemented by the nominee or not).
• Newsgroup postings that demonstrate a depth of understanding about the project beyond the typical user.
• Demonstrable previous and ongoing participation in the case of a mature project being moved to Eclipse.

No one of these things is necessary or sufficient; nominees must exhibit a "body of work" to justify committer status. While support from the existing committers is obviously necessary, it is not sufficient by itself.

What does the Technology Project Management Committee (PMC) Do?

We don't do any regular calls. Most of our interaction is through the technology-pmc mailing list as this provides a totally open transparent record of our interactions. We schedule calls only on an as-needed basis to discuss topics that are either too difficult or too sensitive to discuss via email. The minutes for all calls are posted on the website. We only schedule face-to-face meetings when it is convenient for all members (i.e. no extra travel).

Approve Intellectual Property (IP) Contribution Questionnaires (CQ)

When projects take contributions and make use of third-party libraries, they are required to enter a CQ. A CQ will not be processed by the IP team until it has been approved by the PMC. When we are informed of a new CQ (via email), we do the following:

• An initial license check
• Check that code provided by an Eclipse committer conforms to the Eclipse IP Policy (the short version of the guidelines for developers is helpful in this regard).
  • In particular, we check that the code has proper copyright and license notices.
• Try to reduce bloat, challenge the submitter to use alternative similar technology already available.

Approve New Committers

When a project's committer election has completed, we give the final approval.

Find New Projects

We identify new project opportunities and invite interesting work to become Eclipse Technology Projects.

Help New Projects with their Proposals

All new Eclipse projects start with a proposal. We guide new projects get through the proposal process by (a) helping them assemble the proposal document, and (b) attend the creation review call with them. As part of assembling the proposal document, we will aid a new project in identifying Architecture Council mentors and "Interested Parties".

Help Projects Develop a Community

Most of the work here falls more into the category of "teaching a committer to fish". We don't develop the community for a project, we encourage the project to do the sorts of things that need to be done to develop a community. We will blog or deliver presentations about a project when an opportunity presents itself.

As part of this effort, we encourage projects to actively participate in the Eclipse community. This involves aggregating blogs on Planet Eclipse, forging links with other projects, and leveraging existing technology (rather than inventing new).

Review Projects on an Ongoing Basis

We periodically review projects to ensure that they're doing the right sorts of things to progress. We ensure, for example, that projects are making reasonable effort to develop community. We ensure that they're following the Eclipse IP Policy. Project Reviews are documented.

Help Technology Projects to Stop being Technology Projects

Some Technology projects just go on forever. And this fine for projects of a research nature. However, over time, projects will mature and a more appropriate permanent home may need to be identified (e.g. a different top-level project). Alternatively, some projects run their course and reach a natural end. We help these projects terminate as gracefully as possible.