All code contributions you make to OpenOffice must be under the Apache License, version 2.0. See http://www.apache.org/licenses/ for details.
Always use extended git-style diffs
hg diff -g hg export -g
since they are the most readable, (and sensible) types of diff to read and apply.
The best hacker centric bug filing interface is here. Whack the patch there & wait for feedback.
Sometimes assigning the bug to the code owner helps accelerate the process.
We can sometimes extract the owner of a module by checking
for the ADMIN_FILE_OWNER tag; there is a little tool in
ooo-build/bin/owner <file-name> that helps you
find out who to E-mail / interact with about a given module;
it's worth assigning very specifically located bugs to that
It tends to be a good idea to work out how best to implement your fix, and/or discuss it with a developer or two before hand. Some of the best ways to do this are to post to  or lurk on IRC at irc.freenode.net on the #dev.OpenOffice.org channel. IRC is an awfully poor communication medium, but better than no communication.
See DomainDeveloper to unwind who is whom.
ooo-build patch creation
Once you have created your patch you need to add it to the apply file so it can be applied by apply.pl during build time.
Then simply re-run 'make' in the toplevel - this should incrementally apply your patch to an (untouched) build tree.
Speedy Handling of Patch Submissions
Developers are encouraged to submit their first code contributions as patches - attachments to issues of type PATCH - to IssueZilla for review and integration into the main repository. We have been criticized that submitted PATCHes are not handled in a reasonable timeframe. To support the timely work on patches we introduced the two metrics as listed below.
The consequences of insufficient responsiveness are contributor dissatisfaction, bad reputation for the project and project leads and most significantly that the developer will probably not contribute again.
The number of 5 - 15 submissions per week and a backlog of about 170 open patches seems to be within our capabilities.
Initial Response Time (IRT)
Initial Response Time (IRT) describes the time between submission and first comment or status change from someone else than the submitter for open issues of type PATCH.
Please acknowledge the submission within one of the following days and assign the issue to the developer maintaining the code in question.
Issue Inactivity Time (IIT)
Issue Inactivity Time (IIT) describes the time since the last addition of a comment or status change for open issues of type PATCH.
Let's avoid that patches linger around with unclear status for too long. The expectation of a contributor is that he will see his code reviewed and - if applicable - integrated in one of the next microreleases. So we should drive the issue towards a resolution and closure.