Development Resources/The First 90 Days
This document is under development.
Getting started with your new Eclipse project can be a little daunting. There's a lot to learn and a lot of work to do. If you need help, or aren't sure what you need to do, get help. Ask your project mentors, or the EMO for help (start with your mentors). Your mentors are there to help (note that you can identify your project mentors directly from the project proposal; they're also listed on your project's "project information" page which is accessible form the List of Eclipse Projects.
After your project has been created via creation review, the new project lead will be sent a note from the Eclipse Management Organization (EMO) with instructions for provisioning. You will be required to provide information including the type of code repository your project will use (Git is preferred), as well as the identities of the committers on your new project. The EMO staff uses this information to create all the backend resources required by your project.
Before any code is committed into the newly provisioned source code repository, you must take an initial contribution through the Eclipse IP due diligence process. The initial contribution is the code base that you've brought to the project. You must receive explicit approval from the IP team before you commit any code into the project's repository.
To expedite the IP process, your project can take advantage of the parallel IP process. With the parallel IP process, you'll potentially be able to get your code into the project repository sooner. The idea is that you can get check-in permission while the IP due diligence process runs in parallel. Note that you still need to wait for the IP team to give you a go-ahead before you commit any code into the project's repository.
In order to take advantage of "Parallel IP", a project is required to conform to incubation branding rules. The basic idea is that you need to put certain indicators on your project landing page, downloads page, and downloads to inform the community that the project and its code are not considered mature.
Many contributions to a project must be checked by the Eclipse Intellectual Property (IP) Team prior to their inclusion by an Eclipse Project or distribution from an eclipse.org property. Contribution questionnaires (CQ) are the main interface between the Eclipse community and the Eclipse IP Team.
Third Party code
You need a contribution questionnaire (CQ) for a third-party library if you make direct use of that library. An import statement in Java source, or a bundle reference or package reference in a manifest file are examples of a direct reference. Indirect references through another project's code do not generally require a CQ.
There is a special allowance when it comes to dependencies that are used exclusively for build and test. Build and Test dependencies (which are used exclusively by your project's test code, and are not directly distributed from eclipse.org) can be lumped together into a single CQ. These dependencies do not go into the SCM and are not distributed from eclipse.org.
A solid web presence is important for every Eclipse project. The website is very often the first point of contact with the community and your project's best hope of attracting users, adopters, and contributors.
Creating a website is something that you can do while you are waiting for the IP team to complete their due diligence on your initial contribution.
The project website will be provisioned with a template site. At this point in the project's lifecycle, probably the easiest thing to do is to point the project's website (at least temporarily) to the new data-driven website. The data-driven website will, for example, automagically provide the incubation branding required to qualify for parallel IP.
Building a community is an important part of life as an Eclipse project. It is critical that you are as responsive as possible to the community during these first days of life as a project at Eclipse. Ensure that your project team is monitoring the project forums and newsgroup. Teach your project members to be polite and courteous when dealing with the community.
Get into the habit of opening bugs. Document team discussions on the project website, wiki, or mailing list. Blog, tweet, podcast. Make it easy for people to find your project, learn about what you're doing, and get involved.
This document is moderated by the EMO.