...
Some of the most useful contributions to Impala are bug reports. If you discover a bug in Impala, please open a new JIRA ticket at [the Impala JIRA tracker](http://issues.cloudera.org/browse/IMPALA) ( (after first checking to see if the bug has already been reported).
...
If you’re looking for inspiration, Impala has a [very active JIRA instance](http://issues. cloudera.org/browse/IMPALA). We have labelled some JIRA tickets with ‘[[ramp‘ramp-up-task|https://issues.cloudera.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+10141+AND+labels+%3D+ramp-up-task]]’ task’ - these are ideal for someone who is looking to learn the codebase.
...
Except for the very smallest items, it’s a very good idea to discuss your intended approach either on the JIRA or on the impala-dev@cloudera dev@impala.incubator.apache.org mailing list. You are much more likely to have your patch reviewed and committed if you’ve already got buy-in from the core Impala team before you start.
...
When you have a patch that you consider ready for submission, submit it to our code review tool called Gerrit (see [[ Using Gerrit to submit and review patches|https://github.com/cloudera/Impala/wiki/Using-Gerrit-to-submit-and-review-patches]] for patches for details). You’ll see an e-mail go out to the impala-dev@cloudera dev@impala.incubator.apache.org list.
As time permits, someone from the core team will review your patch. You will likely need to submit an updated patch with some changes - reply to all the comments in Gerrit at the same time (mark as ‘Done’ those suggestions that you’ve taken without further comment). This process can go back and forth for a while - please don’t be discouraged, you’ll see it happens with all patches!
...
We maintain a mailing list at impala-dev@cloudera dev@impala.incubator.apache.org, which is the right place for Impala development discussions. Questions about using Impala still belong on the Impala user list, which is impala-user@cloudera user@impala.incubator.apache.org.
Further reading
This presentation called ['How to Get Your PostgreSQL Patch Accepted'](http://momjian.us/main/writings/pgsql/patch.pdf) captures a lot of our requirements - particularly the focus on starting small, getting agreement, working on the design first, ensuring proper testing and committing to good comments in the code.