This Project Needs You

Any open-source project lives, or dies, by its users, contributors and committers. The more people who get involved, the bigger the momentum and the chance of success higher. If it becomes suitably stable, popular and used then there's a better chance of making it to Eclipse.org, but we're at the start of a long journey.

How can I help?

There's a lot of different ways of helping the project. For example, we need:

• Ideas/Issues. Anyone can raise an issue with an idea for some functionality or (when there's suitable code available) bugs. However, don't let the lack of a feature complete IDE stop you from raising ideas; it might be a while before we get to them, but an idea shared might be something that another person can implement
• Documentation. Wikis are collaborative editable documents, and there may well be pieces of information that aren't here yet. Feel free to add pages as appropriate.
• Testing. Testing, finding and reporting bugs are as much of a benefit to a project as code, typically in edge cases that weren't seen at the time. Of course, that requires:
• Code. The majority of the code will be done in Java (since that's what most Eclipse plugins are implemented in) but it's possible that there will be other non-Java elements (makefiles, provisions for GNUStep etc)

I want to help, what should I do?

1. First, join the developer group mailing list. All discussions should be held there; plus, it's archived, so you can go back and see previous discussions. Even if you're not doing code aspects, it's a good place to announce your presence and meet the others.
2. Second, get a recent copy of Eclipse. Given that 3.5 is out in 2009 and 3.6 in 2010, it's quite likely that ObjectivEClipse is going to require at least 3.5+, maybe 3.6. Until 3.5 goes final, use the milestone candidates, because we'll be basing off CDT 6.0 at a minimum
3. Third, check out the project from the source. An anonymous checkout will let you play with the code locally.
4. Fourth, raise issues. A quick glance of already submitted items will help save work in the long run, but it's better that two people report the same item than no-one does
5. Fifth, feel free to submit code patches. It's best to raise an issue which explains what the patch is for; and we should strive to have tests for changed code as well. It can then be committed and folded back into the code base for others to play around with. Please note that in order to get code under the EPL, we ask that you follow the Contribution Questionnaire first.