Community

Users: Contributing To A Project

How To Behave Practical advice on how to ask questions, report bugs, and be generally successful in your interactions with an Open Source Project.

Reporting Bugs. All Eclipse projects use Bugzilla to track bugs and features. Please read the Bug Reporting FAQ and then sign up for a bugzilla account to join in the fun.

Getting Answers.Mailing lists are for development team conversations; newsgroups and IRC are for the larger user and adopter community and thus are the correct place to ask for help.

Downloads. Get binaries from the main downloads page. Click through to the project pages for integration, milestone, and nightly builds.

Source Code. Get the source code from either SVN, or Git (each project makes their own choice).

Contribute! The best way to contribute to a project is to contribute (sorry for the recursion). Pick a bug from a project that interests you, build a fix, and contribute it to the bug as a patch. If you're not sure how to start, ask questions on the bug, or communicate with the project via their communication channel (normally a forum).

Note that the second page of the poster provides a list of approved third-party licenses.

Large Contributions. Small contributions to Eclipse projects should be made through Bugzilla, but larger contributions require a separate process. Or, if the contribution is larger still, you could start a new project.

Projects: Getting Started

Initial Contribution All Eclipse projects start with an initial contribution of code. Some contributions are big, other are small. Whatever the case, the IP Team needs to review your first drop of code before anything gets added to the repository.

Committers: Being A Committer

The Project Management elements of the Developer Portal are being moved to the new Project Management Infrastructure. All project metadata can now be edited directly on project summary/information pages. Committer elections and creation of new CQs for the IP due diligence process must still be done using the Developer Portal. We are in the process of updating documentation.

Project Metadata. Many pieces of the eclipse.org infrastructure are driven by the project metadata, thus it is important to keep the metadata current and correct. This includes basic information about projects including description, scope, and repositories; releases; reviews; and more.

New Committers

Legal Paperwork. Becoming a new committer involves some legal paperwork. Here's what and why [2]

Development Process. For the overall smooth flow of the Eclipse eco-system, committers agree to follow a few process rules. Here's what they are [3]. There's also a more humorous summary version [4].

Parallel IP Process. Many new committers join with a block of code that they'd like to include right away. The Parallel IP process is designed to speed that inclusion. Here's the what, why, and how of that process [5].

Leads: Managing A Project

IP log Your project must maintain an IP Log. This document keeps track of third-party libraries used and distributed by the project, contributions, and more. It is especially important for adopters who need to know where the intellectual property of your project comes from. You are required to provide an IP Log prior to a release review. We encourage you to keep your IP log current rather than rushing at the end. The automatic IP log extracts most information from bugzilla and IPzilla, but it requires you to use the 'iplog+' flag.

Project Plan The project plan is how projects communicate their future intent to the rest of the Eclipse community.

Builds You have some options with regard to how you build your Eclipse project for distribution.

Hudson Some information about Hudson-based builds, including requesting a new job.

Code quality analysis

Sonar is available for Eclipse projects to track and improve the quality of their code.

Reviews Reviews are undertaken a key points in the life of a project. Project leads should coordinate reviews with their PMC and the EMO.

Manage Project Metadata, Bugzilla Components, etc. Project metadata feeds the project summary pages and other Eclipse tools. In the metadata, you specify important information like release dates, project plans, and description. Use the "Eclipse Projects" section on the portal to specify project metadata. The "tools for all committers" link provides access to Bugzilla components.

Releases. Of course the whole point of an Eclipse project is to release code to the community. At the same time, the Eclipse community relies on a well-defined release review process. It's relatively simple, but it does require planning ahead to schedule the necessary legal and community reviews.

Press Releases. The Eclipse Foundation's marketing department would like to help you put out your project-related press releases; the guidelines are simple enough [6].

Creating and Managing Mailing Lists and Newsgroups Newsgroups are used by most projects to communicate with their community. Mailing lists tend to be used for communication amongst project developers (committers and contributors). Contact Webmaster to create and manage newsgroups and mailing lists.

Team calls You can request a dedicated Asterisk conference call line for your project.

Logos & Trademarks. Documents about the Eclipse logos and trademarks [10][11]. The Eclipse Foundation owns the trademarks on all the Eclipse Project names. The Foundation holds these trademarks on behalf of, and for the benefit of, the projects.