* Of course you are not obligated to respond at all or in a timely manner, but if you do, it's a real treat for the person filing an issue.
* Respect the other person's abilities and skills. When troubleshooting, use language that recognizes the abilities of the other person. For example, instead of "Did you read the documentation?" say "Can you double-check the documentation, especially the section on ____?"
* Keep issues open until the person who filed the issue feels like their problem is resolved. Of course, if the person does not respond for a long time, then there's no harm in closing the issue.
* Get invested in the user's use case. Perhaps this is a "won't fix" scenario, but to truly understand that the issue is out of scope, you should understand exactly what the user needs, up to and including suggesting an alternative solution that is not your software. Sometimes when doing this you realize that in fact the user was correct and their problem is in the scope of your software.
* Be ready to embrace humility. It is common for a user to stop by and drop a piece of information that makes you realize you made a design choice long ago that would be costly to change, both in time and emotionally. At this point you have two choices: humbly admit that you made a mistake and that your software has a limitation due to the mistake, or, humbly admit that you made a mistake and that you'll be working on fixing this mistake in the next major version bump.
* Don't leave code rotting in the main development branch for a long time. Release that code!
* When someone submits a patch, don't nitpick the code conventions. How hard is it to change tabs to spaces and rename a few variables? If the idea behind the code is sound, just merge it and fix the conventions yourself. Style conventions are arbitrary and meaningless. Reduce the friction here for people who bother to look at your source code.
* When you feel you do not have the resources to continue maintaining one of your projects, but users are still filing issues and sending patches, try to hand off the maintainer hat to someone competent. Keep the project alive!
* If your software has a bug, but it's the fault of one of your dependencies, keep a bug report open in your bug tracker too, with a link to the dependency's open bug. Your dependencies' bugs are your bugs too.
I'm sure there are more; that's just what I thought of off the top of my head.