One of the biggest tasks when building a Drupal site is selecting, configuring, and integrating contrib modules into your site. For almost everything you need to do "there's a module for that", but whether you should be using that module is an entirely different question.

For every new module I choose for a site, I go through some quick steps and questions (mostly unconsciously now) to determine whether I should risk a module.

1. Most recent release - While this may not be a good guide of whether the module is stable or not, it tends to provide a pretty good guide of how actively maintained it is. The first thing I do, before even reading through the description is check the latest release. If the project doesn't have a release in over a year this usually isn't a good sign.

2. Issue queue - The second thing I do is check the issue queue. I expect the average module to have about half a page to a page of open tickets. I'm mostly concerned here with whether or not a maintainer is actually responding to tickets and active with the project. If simple tickets with patches have been sitting open for several months with no response from a maintainer, this is a very bad sign. For larger modules you can probably expect several pages of issues. In all honesty, my only concern here is that tickets are being addressed by maintainers.

3. Usage stats - Every project page on Drupal has a link to "usage statistics". The more users a module has the better bug tested it is, in general.

4. Documentation - Is the project description useful? How about the README? Whether you read the docs or not, knowing they exist is important. In my experience a project with no readme and poor documentation is generally very lacking in other areas too.

5. Post install troubles - Any trouble figuring out how to use the module after you've enabled it? Even after you read the README? Probably a sign that you may have problems integrating and configuring the module with your site.

6. Code structure - I almost always take a peek at the code of every module I use on a site these days. If you're not a developer yourself this won't mean as much to you. But taking a quick scan through the code can set off alarms bells pretty quickly.

You'll likely run into modules that fail in every one of these areas. It might be a good idea to take a pass on it and try to find similar functionality elsewhere. If it's a module that's important enough to your site ask to become a co-maintainer. Just please don't create a second identical module on drupal.org because you thought you could do a better job.

There are also a few other tools that can aid in selecting modules such as http://drupalmodules.com which lets you rate and comment on modules you've used.

As a developer, for me choosing a module comes down to three main questions:

1. How responsive is the maintainer / How active is the development?
2. How important is it for me to have this functionality?
3. Do I have time to take the module on and clean it up myself?

Less important functionality simply gets axed if the module isn't up to par. But ultimately a lot of the selection process just comes down to experience as well as asking others what modules have worked for them.

For every site I maintain I keep a running list as to which ones are likely to cause problems. This helps to identify problems when "unexplained" things happen and also so you know which areas you should try and clean up / replace when you've got a few spare moments to work on a site.