[drupal-devel] Module management

[Jeff Robbins]

On Apr 23, 2005, at 5:53 AM, Gerhard Killesreiter wrote:
> On Fri, 22 Apr 2005, Jeff Robbins wrote:
>> On Apr 22, 2005, at 2:14 PM, Allie Micka wrote:
>>> The collection of modules wouldn't necessarily be distributed with
>>> core, but represent an array of non-overlapping functionality.  
>>> Pehaps
>>> this is achieved through votes or a certain level of maturity.  It is
>>> just starting to get to the point where the module list is getting
>>> unwieldy and it isn't clear what each is doing, so there's overlap 
>>> and
>>> inexperience.  The tier of "approved" modules would presumably not
>>> suffer this problem, so if they do include patches to core it won't 
>>> be
>>> as big of a concern.
>>
>> [stuff deleted]
>>
>> I've been thinking that it might be a good idea to enable some sort of
>> comments for the module pages. [snip] The comment system at php.net 
>> is essential for figuring
>> out tips and tricks for PHP functions and it seems like we could have
>> the same thing for modules.
>
> I consider this to be in principle a good idea. The problem is that
> people will also post support requests there and that somebody would
> need to delete those and there should be a line informing people that
> such requests would be deleted. As long as we cannot give project 
> owners
> the power to only delete comments on thier project nodes, this isn't
> really going to work.

Yes, well it should probably be moderated in one way or another. Maybe 
community moderation? And even PHP.net gets some support requests in 
the comments. But mostly it's a U.I. issue. If there's bold text at the 
top of the comment submit textarea saying "DO NOT POST SUPPORT REQUESTS 
HERE", there probably won't be too many.

I guess I'm sort of thinking of this as a mini-book for each module, 
but less page-oriented and more list oriented (meaning all on one 
page). Where users could post tips and tricks and manual-page-type 
information; short one-liners or long tutorials.

With so many of the modules defining complete API's (ecommerce, 
location, event, etc), I'm finding that I'm discovering new ways of 
using modules and perhaps others could benefit from experience. I could 
certainly post in the forums, but I doubt that new users are 
cross-referencing each module against the forums when they're trying to 
decide which modules to use.

>> Another step in this direction would be a module rating system, but
>> there are potential flaws with that - such as a high rated module that
>> *used* to be essential, but now is obsolete.
>
> If  module is really obsolete, it will be removed. The problem is that
> we currently offer downloads for at least the Drupal versions since 4.0
> if not 3.0. We maybe should limit this to 4.4 to HEAD and remove all
> projects that do not have releases for any of those versions and which
> are not developed actively anymore.

Well this becomes another discussion, but what's one person's 
"obsolete" is another person's "stable version". Another issue with 
rating systems is that they are prone to politicking and I'd hate for a 
good module to be badly rated because its developer is not a good 
marketer. Or vice versa.

> I am also very fond of the idea to categorize our modules through
> taxonomy. The problem is that Dries isn't sure that this would work 
> well
> with project module. Project.module relies on taxonomy for some other
> stuff (themes, modules, ...) and adding another vocab might break that.
> Since Dries won't let me try it on drupal.org and I don't have a
> project.module install myself it would be helpfull if somebody would
> step forward and do some tests.

Taxonomy is good. And it might work to have someone who is the Module 
Moderator and could make decisions like which modules get tagged as: 
"Gold Star", "Important", "Obsolete", "Inactive", "API",
"Headed for Core", "Piece of Crap", "Coded by Monkey", etc...

And just for reference, Mambo features an entire website dedicated to 
its modules, components, and themes:
http://mamboforge.net

To be honest, I'm not sure that it's any better than what's going on at 
Drupal.org, but it's worth seeing what the "other guys" are doing.

-Jeff