We'd love to have your help in making HHVM better. Before jumping into the code, please familiarize yourself with our coding conventions. We're also working on a Hacker's Guide to HHVM. It's still very incomplete, but if there's a specific topic you'd like to see addressed sooner rather than later, let us know. For documentation and any other problems, please open an issue, or better yet, fork us and send a pull request. Join us on Freenode in #hhvm for general discussion, or #hhvm-dev for development-oriented discussion.
If you want to help but don't know where to start, try fixing some of the "probably easy" issues; add a test to hphp/test/slow/something_appropriate, and run it with hphp/test/run.
All the open issues tagged PHP5 incompatibility are real issues reported by the community in existing PHP code and frameworks that could use some attention.
The code of conduct is described in CODE_OF_CONDUCT.md
Before changes can be accepted a Contributor Licensing Agreement must be completed. You will be prompted to accept the CLA when you submit your first pull request. If you prefer a hard copy, you can print the pdf, sign it, scan it, and send it to cla@fb.com.
Please add appropriate test cases as you make changes, and make sure that they pass locally before submitting your pull request; see here for more information. All the tests are run via Phabricator, however testing locally greatly speeds up the process of accepting your changes.
We maintain up to three stable branches at once (the current release plus two LTS branches). To get a fix into one of those branches, first get accepted into master, as described above. Fixes are merged into master and then merged backwards into stable releases as appropriate.
Then, submit another PR against the relevant stable branch(es) cherry-picking your change into that branch, with any changes needed to properly backport. Make sure to explain in the PR summary why the change should be considered for inclusion in the stable branch -- basically, make the case for why the issue the change is fixing is worse than the possible risk of what the change might break (and thus what we will be responsible for debugging, fixing, and maintaining).