Patches that we write for drupal.org modules are submitted to the issue queue, and we refer to the patch’s location on drupal.org in the make file. This has made us much better contributors to other people projects as it makes being involved in the issue queue a normal part of development, and it encourages us to only patch contrib modules where it’s likely that the patch will be accepted. When a patch gets a review, we make changes, upload a newer version of the patch to drupal.org, and update our make file.
This is actually a quote from Jeff in the comments on the article Drush Make Files for Production Drupal sites, but I thought it was definitely worth highlighting on its own.
In this particular case, using make files actually codifies the decision to integrate closely with contrib modules and actively improve them / add features as needed for a particular project.
I've followed this practice for years, albeit without make files. Patches go in a "patches" directory in version control, with the patch file named with both the name of the module and the node number of the issue on Drupal.org.
An additional process is that if a patch is needed, you run it in the issue queue on Drupal.org, but you also have an internal ticket that links to that issue. You don't close the issue until the patch has been accepted into the mainline of the module. Then you can remove the patch, update the version of the module you're using, and your clients' website is one step closer to easier long term maintenance and updates.
And yes, being involved in the issue queue SHOULD be a normal part of developing Drupal websites.