Contributing to Drupal

Since Dries blog post about Contributing back to Drupal, there's been a bunch of discussion about how Drupal companies should best do this.

I've only recently started at Zivtech, and although I've done plenty of on-the-job Drupal work, this is my first job at a true Drupal company. Zivtech's policy of giving its developers 20% time to contribute to Drupal was a big incentive for me to take the job.

I've now read some Zivtech docs for new developers regarding code procedures, and thought the following section might be interesting as an concrete example of one company's process for contributing patches back to Drupal:

Patches

When encountering a bug on a project, first steps should be ensuring you have the latest recommended version of the module and checking the module's issue queue for an existing report. The bug should be reported to the module's issue queue as well as being worked on by either you or a colleague (create an Unfuddle ticket for the issue). If you fix the bug, you are obligated to create a patch (http://drupal.org/patch/create) and submit the patch to the issue queue. Save your patch to the project's 'patches' directory (create one if none exists) with a filename which contains both the module name and the drupal.org node ID of the issue on which you submitted the patch. For example, if you patched imagefield module and submitted your patch as a bug report on drupal.org/node/415671, your patch should be saved as 'patches/imagefield-415671.patch'. In some cases you may submit your patch to a site other than drupal.org, such as ubercart.org, and can label like uc-uc67897.patch. Add your patch to the svn repository for the project. Following up on your patch in the issue queue is a process which can be ongoing (track your issues at drupal.org/project/issues/user) - you may have to answer questions about your patch or reroll it as time goes on to ensure it is eventually committed to the module.

...

Like bugs, new features or improvements should be submitted as patches to a module's issue queue. When a project's customization seems like it could be useful to many projects and have a decent chance of being committed, code that customization as a patch to the module rather than a custom module and contribute the patch. Store the new patch in the patches directory as described above.

If a module is confusing to you and lacks sufficient INSTALL.txt or README.txt file, contribute improvements to these files as patches as well. You may also add to the relevant Drupal handbook pages on the module.

If a needed change to a module cannot be reasonably contributed to Drupal as a bug fix or feature request, attempt to implement the customization in a custom module rather than hacking the module. Ask for help finding ways to do this if needed. If doing so is not possible, the customization should be avoided and the client informed that the longterm cost of doing such a customization may outweigh the benefit. If the hack is absolutely necessary, store the resulting patch in the patches folder with a descriptive filename beginning with the modified module name.

How do other Drupal shops do it? Comments and feedback welcome.