Currently there are 319 Modules in tree 4.7.0 (735 cvs) and 50 Themes (103 cvs).

Although there is the great browse by category-tab, nonexperienced users of Drupal are often asking: "Which module should I use? CCK or flexinode? Should I use images through "upload and a-hrefing" or image.module or whatever else?
And sometimes I'm confused by the categorisation, too. E.g. there are 3 taxonomy related categories: Category, Taxonomy and Term.
So, I most often browse modules by date, which is only working, if you have stored the most modules in brain.

I would like to have a staging like:
- core (the framework)
- contribute (which is the new one)
- user contribute
- cvs
- sandbox

The contributed-modules should be well reviewed and choosen. Collecting installation-information through the drupal.module would be helpfull, but cause it "also enables users to log in using a Drupal ID" it's often disabled. By default it's disabled, so the data is not representive.

Now my questions:
Is there any job I can do?
Are there other users feeling like me?

Comments

FabriceV’s picture

Dear Mr.
Voting module can be applied to module projects. A general recommandation can be made to all users of each module to vote against multiple fields (feature, ergonomy, stability, compability) and the module can be list accordingly.
Sincerely.

robclay’s picture

That would be good, but the problem is for the web builders that wonder which module to use. You want to feel comfortable that you are using a module that will continue to be supported. Like in the first post... CCK vs Flexinode... If you don't know any of the history, and did a search, you would see that flexinode has a lot more posts, etc. Therefore it must be the one that everyone is using... Yet we know that flexinode will be phased out soon.

It seems that the core developers would need to help someone choose the correct module.

killes@www.drop.org’s picture

The problem is time. It would not be terribly hard to set up an additional category, the problem is to review all those modules. Also, you'd need to review every change that the author commits after the initial review.

I think we simply don't have the ressources to do this.
--
Drupal services
My Drupal services

narres’s picture

Hi Gerhard ,

if there is some help needed: I would do it. I' allready doing some similar with my unsuccessfull Themes ;)

Thomas Narres
Keep the sunny side up

Thomas Narres
Keep the sunny side up

killes@www.drop.org’s picture

What would be needed are 5-10 people who are able and willing to review additional modules for security holes, etc.
--
Drupal services
My Drupal services

FabriceV’s picture

Dear Mr,
I have done recently a presentation of all chat modules in french to the the french drupal site. The presentation is not so much technical but allow beginners (I am one) to understand the characteristics and usage of each module. In addition, I have added comments on the usage of chat compare to voice communication, bandwith load...
I know it is already possible to publish to book. However, a more voluntary approach is possibly more efficient. e.g. publish a message allowing "week collaborative writing contest". Decide of a theme (chat modules, access modules...) focusing on description and usage. See the result, and decide latter to add an other topic if the result is good. It a community writing not a personnal responsability.
I am a sport coach. Think to a passionate of alpine skiing... He love skiing but the coach often needs to stimulate him to train strength, endurance... despite he knows the interest of training... Replace skiing by Drupal, and training by writing !:-)...
Finnally, for all those who do not write well english, it will be more easier to publish if you know that during a short period of time, everyone work and rewrite your work, complete it, spell it...

Sincerely.

narres’s picture

Do we really need to review all modules? In my opinion: No!

Cause there are a lot of modules (since yesterday 12 modules are updated and one is new for the 4.7.0 branch) it would be really a "mission impossible - part 4".
As I spoke from the new contribute-section I didn't mean to review here all modules. There are only a few with common interest (my example list):
- Content Construction Kit (CCK)
- Image
- RobotsTxt
- Taxonomy Access Control
- TinyMCE WYSIWYG Editor
- Views
maybe
- Actions
- Buddylist
- Events
- Node (key)words
- Organic groups
- Page title
too. It's possible that this is not complete, but I'm sure that there are only a dozen modules to be reviewed are left, if Drupal users post their modules of common (global) interest.

Thomas Narres
Keep the sunny side up

Thomas Narres
Keep the sunny side up

sepeck’s picture

But see, that's your list and frankly I don't use nor would I ever use most of those and at this point never buddylist and most unlikely TinyMCE. If I recall, you are missing several of the most popular downloads too.

That's why if you are going ot do it, you have to review all of them. If you want some sort of 'stamp of approval' then you got to do them all and frankly we've never had the people willing, much less able to do that. It's not a new idea.

My suggestion for an alernative and lower threshhold achievable approach is site recipes. If we could get more people contributing to site recipes then people would have various 'types' of sites and starting points for them with suggested modules right there.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

narres’s picture

That's why it's my example list and not my official recommendation.
The goal was not, that I will write a official list. The goal is to show that, when enough members are commiting their choice, you will get a representative average of used modules.
From this list you are able to build a "What the user wants" e.g.:
- Image handling
- Forum
- (...)
or what a developer thinks that a user needs, but he doesn't ;)

Site recipes is hard to hold on an actual state (some information is already obsolete e.g. flexinode -> CCK). In fact you will need only 2 clicks to find this page, but it's very hidden on the pages (http://drupal.org/ -> http://drupal.org/handbooks -> http://drupal.org/handbook/site-recipes), so a non well oriented user will not find it.

As there is module related information already collected from:
- admin/settings/drupal (Send system information)
- Download statistics
- Core plans and roadmap
- (...)
are there any ideas where I can help?

Sometimes this discussions makes me think: Drupal is a "developers playground" and not a "ready to use webapplication".

Thomas Narres
Keep the sunny side up!

Thomas Narres
Keep the sunny side up

sepeck’s picture

Do we really need to review all modules? In my opinion: No!

In my opinion, if we review some, we review all. Why setup a completely seperate system to review 'the chosen few' when your list doesn't even list the most popular downloads? I realize that it was an 'example', but even as an example my response was an 'example' of exactly the response that has happened by others when someone came up with a list before.

Then we have people clamoring about a whole new tier of 'insiders'. Killes already indicated he thought a group of 10-15 people could probably do it if they committed themself to do it. Why not see if you could find 10-15 people and start? You can start reviewing without a system in place. If such a group started up and was able to produce results then it would be seen as viable and incorported into Drupal.org. So, any idea for you, start a group on http://groups.drupal.org for this purpose. Get some people to start working on it and trying to define your criterea for judging modules. Good security coding standards, good use of SQL, quality of code, performance. Then start putting together the data and information together.

This is not a new discussion, it occurs every few months and the answer is, no one new steps up to help do/produce the work. See the dev list archives if you don't believe me. So folks would be thrilled if some new folks stepped up and were willing to help out. You should go thourgh the dev mail list archives in the last year as there are a variety of interesting discussions there for you on this.

The last I remember anyone checking, there were less then 100 reporting sites from the new (4.7) reporting feature. It's new and not advertised heavily at this point. We'll have to see if someone can run the numbers again to see if the reporting numbers has changed.

Site-recipes was setup because people wanted recipes and how to's. Some people claimed that if such existed they would be more then happy to show everyone how it was done and contribute. So far, those people have vanished and not contributed what was promised. So you see, ideas are interesting, but work is more useful. Site recipes could easily solve as a how to. I can also easily move it somewhere else. Do you think it would be better in the installation and configuration section of the handbook? If you say yes, I will move it immediatly. Well, cck isn't done yet and flexinode still works just fine. The nice thing about recipes though, is that it's about ingredients, if you can help people put together combinations of modules to 'do things' and see the posibilities then they learn how to use the tools.

I am not a developer. Please don't assume that 'developers' are incapable of understanding different view points and are some monolithic group. It's kind of odd that you have already defined this group as less then capable of seeing a complete system and unwilling to consider 'end users' when many of them do this all the time. There is a diverse group of people active and contributing and we want more, you want to do something different, then you need to help solve the issues that people have raised.

Out of curiosity, what do you mean when you say user? What a 'user' of Drupal is to most of the development comunity is the 'site-admin' who sets up and or maintains the installation. Not the sites end users. Drupal is not an out of the box solution, it's a kit/framework that lets you build a site you want/need. That you can do this without coding (which I do) is a tribute to the capabilitiesof Drupal, that you can do so much more if you code is what makes it a framework.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

narres’s picture

There are several opinions what Drupal is: "Content management framework" or a "Content management system"?
Cause a content management framework is an application programming interface for creating a customized content management system, I think the best definition for Drupal would be a "Web Application Framework" with a huge library of third party modules.

People are confused what Drupal is:
http://techrepublic.com.com/5100-10877_11-6091589.html
http://www.forrester.com/Research/Document/Excerpt/0,7211,39747,00.html
http://www.businessblogconsulting.com/2004/09/drupal_blog_pub.html
http://weblogs.about.com/od/softwareplatformreviews/gr/drupalreview.htm
(...)
What I read from these studies is that Drupal is "a cms only a geek could love".

As I found at http://knaddison.com/Drupal-Installed-Now-What-An-Introduction the most downloaded: http://drupal.org/node/46109 list makes three importand points of interest:
- Image related
- Generic Node Type related (CCK, Flexinode)
- WYSIWYG-Editor

The main contras I've found (related to Drupal):
- Needs above average technical knowledge to install.
- Basic set up is 'bare bones' and needs more development.
- Not all available modules work well across themes and versions.

There are several list:
Nick Lewis: 10 Drupal Modules You Can't Live Without
(...)

But I found nothing about a working group for sorting modules due to their function.

So I think a working group would be the best continue this thread.

Thomas Narres
Keep the sunny side up

Thomas Narres
Keep the sunny side up

sepeck’s picture

See my comments on Nick Lewis' list for our discussion. Top 10 lists vary depending on focus so I think those types of lists would serve as an entry point to site setups and such. Of course, once we got lists, people would want recipes. :D

Yep, there is confusion about what specifically Drupal is. I don't actually see that as a problem myself becuase it's flexible and evolving still so depending on your skill set, it's different. If you are like me, it's a CMS framework (no programming needed beyond a little themeing). If you are a developers then it can be a base api framework for you to start with 80% of your work done and code the rest to make your site special.

Drupal's starting audience was technical. It still really is. There are people working to make it easier to install (installer system, site profiles) but it's not notepad and your html web pages. You in general have to have a passing familiarity with some concepts (Web server, database, scripting) to really use Drupal.

Even out of the box with no coding, you need to be willing to learn this somewhat. There is layout, menu's, categorization of your information, how to display it..... Some other CMS's template some of this stuff for you but the downside to that is it's harder to break out of the prefab stuff to your own. Drupal starts with the tools so new people end up with a 'now what' at the welcome page. It assumes nothing. So at this point there is a more up front learning curve to start. So I agree, higher technical starting point or willingness to learn currently.

On the dev list stuff, there have been mention of a gold standard contrib repository and what it would take, some download statistics, etc. So far, no one has stepped up to lead such an effort, so if you can show it's viable, best of luck. It may be an avenue for people interested in contributing to help out and extend drupal.org further.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide