• Read the rest of the website, understand what POI is and what it does, the project vision, etc.
• Use POI a bit, look for gaps in the documentation and examples.
• Join the mailing lists and share your knowledge with others.
• Get Subversion and check out the POI source tree
• Documentation is always the best place to start contributing, maybe you found that if the documentation just told you how to do X then it would make more sense, modify the documentation.
• Contribute examples - if there's something people are often asking about on the user list which isn't covered in the documentation or current examples, try writing an example of this and uploading it as a patch.
• Get used to building POI, you'll be doing it a lot, be one with the build, know its targets, etc.
• Write Unit Tests. Great way to understand POI. Look for classes that aren't tested, or aren't tested on a public/protected method level, start there.
• Download the file format documentation from Microsoft - OLE2 Binary File Formats or OOXML XML File Formats
• Submit patches (see below) of your contributions, modifications.
• Check the bug database for simple problem reports, and write a patch to fix the problem
• Review existing patches in the bug database, and report if they still apply, if they need unit tests atc.
• Add in new features, see Bug database for suggestions.

The Nutch project also have a very useful guide on becoming a new developer in their project. While it is written for their project, a large part of it will apply to POI too. You can read it at http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer. The Apache Community Development Project also provides guidance and mentoring for new contributors.

Create patches by getting the latest sources from Subversion. Alter or add files as appropriate. Then, from the poi directiory, type svn diff > mypatch.patch. This will capture all of your changes in a patch file of the appropriate format. However, svn diff won't capture any new files you may have added. So, if you've added any files, create an archive (tar.bz2 preferred as its the smallest) in a path-preserving archive format, relative to your poi directory. You'll attach both files in the next step.

Ideally, patches should be submitted early and often. This is for two key reasons. Firstly, it's much easier to review smaller patches than large ones. This means that smaller patches are much more likely to be applied to SVN in a timely fashion. Secondly, by sending in your patches earlier rather than later, it's much easier to get feedback on your coding and direction. If you've missed an easier way to do something, or are duplicating some (probably hidden) existing code, or taking things in an unusual direction, it's best to get the feedback sooner rather than later! As such, when submitting patches to POI, as with other Apache Software Foundation projects, do please try to submit early and often, rather than "throwing a large patch over the wall" at the end.

Patches are submitted via the Bug Database. Create a new bug, set the subject to [PATCH] followed by a brief description. Explain you patch and any special instructions and submit/save it. Next, go back to the bug, and create attachements for the patch files you created. Be sure to describe not only the files purpose, but its format. (Is that ZIP or a tgz or a bz2 or what?).

Make sure your patches include the @author tag on any files you've altered or created. Make sure you've documented your changes and altered the examples/etc to reflect them. Any new additions should have unit tests. Lastly, ensure that you've provided approriate javadoc. (see Coding Standards). Patches that are of low quality may be rejected or the contributer may be asked to bring them up to spec.

If you use a unix shell, you may find the following following sequence of commands useful for building the files to attach.

The POI project will generally offer committership to contributors who send in consistently good patches over a period of several months.

The requirement for "good patches" generally means patches which can be applied to SVN with little or no changes. These patches should include unit test, and appropriate documentation. Whilst your first patch to POI may require quite a bit of work before it can be committed by an existing committer, with any luck your later patches will be applied with no / minor tweaks. Please do take note of any changes required by your earlier patches, to learn for later ones! If in doubt, ask on the dev mailing list.

The requirement for patches over several months is to ensure that committers remain with the project. It's very easy for a good developer to fire off half a dozen good patches in the couple of weeks that they're working on a POI powered project. However, if that developer then moves away, and stops contributing to POI after that spurt, then they're not a good candidate for committership. As such, we generally require people to stay around for a while, submitting patches and helping on the mailing list before considering them for committership.

Where possible, patches should be submitted early and often. For more details on this, please see the "Submitting Patches" section above.

Where possible, the existing developers will try to help and mentor new contributors. However, everyone involved in POI is a volunteer, and it may happen that your first few patches come in at a time when all the committers are very busy. Do please have patience, and remember to use the dev mailing list so that other contributors can assist you!

For more information on getting started at Apache, mentoring, and local Apache Committers near you who can offer advice, please see the Apache Community Development Project website.