View source for 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 [mailto:emo@eclipse.org 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 [http://www.eclipse.org/projects/listofprojects.php List of Eclipse Projects].

==Getting Started==

Please see [[Development Resources/HOWTO/Starting A New Project|Starting A New Project]].

==Provisioning==

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.

==Committing Code==

Before ''any'' code is committed into the newly provisioned source code repository, you must take an [[Development Resources/Initial Contribution|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.

===Parallel IP===

To expedite the IP process, your project can take advantage of the [[Development Resources/HOWTO/Parallel IP Process|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. 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 [[Development Resources/HOWTO/Conforming Incubation Branding|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.

Note that the end result of the IP team's due diligence may require that some or all of the code or library under consideration be removed from your project (approximately 5% of third party libraries are ultimately rejected by the IP team; 25-30% of all reviews require some modification, e.g. removal of files). Be prepared for this. When code or a library is rejected by the IP team, it must be removed from all means of distribution at Eclipse; this includes the project's source code repositories, downloads server, and website. Webmaster can help with the mechanical process of removing the rejected code, but the impact of the removal of that code on the balance of the code will be the project's responsibility to bear.

===Tracking Contributions===

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. [[Development Resources/Contribution Questionnaire|Contribution questionnaires]] (CQ) are the main interface between the Eclipse community and the Eclipse IP Team.

===Third Party code===

You need a [[Development Resources/Contribution Questionnaire|contribution questionnaire]] (CQ) for a
[http://eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf 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. A separate CQ is required for each dependency of a third-party dependency (i.e. the transitive closure of dependencies for a third-party library must be represented by CQs). Indirect references through another ''Eclipse'' 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. [[Development Resources/IP/Test and Build Dependencies|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.

===Images, Icons, and other Non-Code Artifacts===

Images, icons, property files, configuration files, documents and other artifacts are intellectual property and are subject to the IP process. Don't forget these when you're assembling your initial contribution.

==Project Website==

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 [[Development Resources/Data Driven Project Website|data-driven website]]. The data-driven website will, for example, automagically provide the incubation branding required to qualify for parallel IP.

==Community==

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.''