Help answer some quick questions?

On the front page, there's always (I think...) a sticky post aboute the latest security updates of core. There are download links there. Right now, that's at http://drupal.org/drupal-6.6 . The download links in the upper right corner on the front page go to that page, not to either of those you mentioned.

--
Hilde Austlid, Drupalchick

The way it currently works, the only audience as such for these is the project maintainer, and most people who want to help out with support requests do so in the forums or on irc. Similarly it's very hard to get patches reviewed for contributed modules as well (not even that easy for core). Bugs, tasks and feature requests are more likely to be looked at by other developers (who may have found a bug and be looking for a fix for it) - depends on which module it is usually.

People post bug reports which should really have been support requests, and vice versa. The main problem is people post issues without ever checking to see if someone's already opened an issue - which means we get many thousands of duplicates causing a lot of frustrated users and duplication of work.

I'd personally really like to see this change so that projects get a community of people around them, asking and answering each others support requests, and reviewing bug reports and patches - this is only feasible for more popular modules, but we have some very popular modules with large user bases, so it ought to be feasible. Some things which might help with that would be displaying recently 'fixed' support requests and bug reports somewhere - ideally when posting a new issue - or even better - a 'similar issues' search while you type yours in - see http://drupal.org/node/19386.

The 'projects as organic groups' idea is also a step towards this.

In terms of my own usage, I only ever click on 'view open issues', and usually only if I'm checking out a new module and want to see how buggy it is. Generally I browse directly to drupal.org/project/issues/$project - which saves a few clicks. Having a few issues listed on project pages I think would help both insiders and outsiders when viewing these pages.

Look at the usage statistics and you'll see a relatively small number dominating.

But highlighting these is something the newcomer gets pretty quickly anyway.

I think having good functionality categories, and then highlighting the more-respected solutions between the competing modules within that feature space would make a huge difference, for example karma of the developers from people voting on their various modules, not just rating that module. If I see Moshe's name on a module when there's four others that do close to the same thing I'll try that first, even if only ten sites have ever installed it. But it's taken me months of hanging out here to get a feel for those things, and that's the curve we're trying to shorten.

Another key problem for the noob, and one much harder to solve, is their not understanding the relationship between Drupal's technical capabilities and their desired use-case functionality.

For example "I want to build a paid member site for real estate brokers, with listings, discussion forums by geography and a reference materials section" vs taxonomy, access control, navigation.

I think highlighting the site case studies, somehow getting more full-fledge site recipes, installation profiles etc will help, as will better-organized intro/overview docs.

As people have already said - there's a handful of modules which everyone should know about before they start building a Drupal site - views, cck, imagefield (requires cck), panels (requires views in 6.x), pathauto and a couple more.

It's near impossible to build a complete Drupal site without any contributed modules (very unlike wordpress and joomla which give you more up front) - and deciding if/how to use some of these will often determine the course your site takes long term - i.e. people should be introduced to them, and make a conscious decision not to use them, rather than not knowing at all.

I'd say there's probably another 30-40 on top of that which you need to at least know exist if you're building a site that does anything more than the very basics - i.e. most non-trivial Drupal sites have at least 10 contributed modules installed, many have between 20-40 or more.

Looking at http://drupal.org/project/usage - there's about 30-50 modules which go over the 4,000 sites mark - which gives them a claim to be installed on 1 in 20 Drupal sites or more. Acquia supports about 30 modules as part of their Carbon distribution on top of core - the top 30 doesn't match their list, nor mine - but in terms of numbers it feels about right for a second-tier of major projects.

Looking further down http://drupal.org/project/usage I recognise most of the modules which have over 1,000 usage for October 24th. This means I've either seen them when researching something to use, used them on a site, heard them discussed a lot, or some combination of all three over the past three years. That's about 150 modules - each of them installed on more than 1/80th of recorded Drupal installs - and some in that area I'd consider important/useful modules (services, flickr - though I've never need to use either of them) while some I've never heard of at all.

Below 1,000 installs it starts dropping very fast, and while there's some high quality ones in there, they tend to be more specific/advanced.

So, I'd say we need to highlight the top 5-10 which it's likely a lot of people would agree on. Then there's another 50 or so which might appear in 50 different Drupal user's top 10s and/or get used a lot, and people need to know where to find them. After that you're probably already quite a way in - and the issue becomes deciding between different modules which do similar things, as compared to finding 'a module to upload images' 'a module to list my blog posts' or other basic needs.