I like the idea of having a vetting team which puts together a list of recommended modules. This should be nothing more than a list. If they are stored separately or not is unimportant, the important aspect being that someone who was given the job looked at the work and endorsed it. This is not to say that modules not on the "A" list are bad, but they might take more work to install, or are less stable/tested, or are not as actively supported and developed. Most of us on this list would still download them, install them and make our own decisions. Less capable users would rightfully avoid them. I like the idea of bundles too, but only as a way of suggesting to users what works best. This should in no way be an enforced grouping and should only be an alternative way to select modules. Example: image.module and img_assist.module (4.5 versions). Both would be listed in the "A" list, and in a separate list, a bundle called "image bundle" would offer both together, as well as special instructions for getting them both up and running. This approach has several advantages. First, it takes the best parts of everybody's ideas (so far). Second, it requires very few changes to our current system. Third, we have nothing to lose. We don't lose the good modules that everyone likes, and we don't lose the wild ones which can be pretty bad and useless, but like mentioned already, play an important role in the community. In the end, it is a presentation and packaging problem. The two things which we would change to achive this are: 1) set up a vetting committee and guidelines (not too restrictive - shouldn't become a huge political thing) 2) extend our build process to offer bundle tarballs.