Making your contrib modules more admin-friendly

SESSION OVERVIEW
Site Admins, how many times have you downloaded a contrib module that sounds promising from it’s initial description, only to find out that you have to do this, that, and the other thing before it’ll even fire up for a basic analysis?

Module Developers, how many issues in your issue queue do you find yourself responding to with, “Well, didn’t you read the README.txt file and follow my twelve installation steps before posting an ‘it doesn’t work’ complaint?

What if we could have modules that did all the configuration and setup for us? Upload the module, check the ‘on’ box, and have a fully functioning module with no extra effort on our behalf? PHP can do it, so why can’t our modules take a few extra steps and auto-configure themselves with a usable yet conservative set of defaults, but still allow the site administrator(s) to configure it to their liking? It turns out that we can, but nobody really gives it much thought before releasing their new baby module to the world. I’d like for us to change that line of thinking, and as a community, re-evaluate how our modules are initially perceived by the world at large.

I’m asking module creators or maintainers who’ve got way too many issues filed against their contrib, along with the point-n-click site admins who might have a couple of ideas on what they’d like to see in self-configuring module to join me for a popcorn-style session on what we can do to prepare a module for flight before releasing it to the community. I have a few ideas to share, a couple of rare yet important code examples to show that make a few of these steps easier, and I’d like to get some feedback from all of you on how to improve the knowledge base of our community’s module contributors in this regard.

AGENDA
* Our contrib modules are getting sexier from a user’s UI perspective, but what about the site administrators?
* You have a problem, and downloaded and installed ‘the solution’, but it doesn’t work like you expected. Why?
* Installing and uninstalling most modules is a PITA for site admins, but the tide is changing as the Drupal versions go up.
* How to get a developer to write more code than they ‘have to’:
* * Modules can be sexy to use, but if they think for us during the setup process, more people might use them, leading to a greater degree of fame for their creators!
* * Are there ways to combat this phenomenon amongst the module contributors without causing alienation or a defeatist attitude?