Not to kiss butt, but a project is as good as it's management. We got some really motivated, passionate people here, and it's awesome to see something so successful.
I love modules on drupal, I think sometimes the amount of them can be confusing.
- Do we need to have 3 different modules that do the same thing? If so, let's at least make it apparent that this module does the same thing/or is similar to another module. Name and category alone isn't doing the trick, it's pretty crowded in there
- I feel good that developers are forking and similar modules, it's one of the cool things about open source. But I think we should be wary:
- some of these modules can hit dead ends.
- it splits the progress/development/focus/support.
- It is especially hurtful for future modules which are dependent on dead, forked projects.
- forks encourage different approaches, the one that stands the test of time should be the one with focus directed to it. I believe the community does it's part, but I think the site needs to let the dead-ware sink.
So basically, I'm saying that we should place emphasis on drupal.org simpler by having fewer ambiguous/extra modules, and focusing more developer power into a single project. Things are pretty liberal around here, there are guildelines. How about some emphasis/motivation in the community to merging the best of both projects/modules and encouraging people to convert to one (for webmasters and modules relying on dead-forked projects)?
- We should emphasize activity/development in the modules section. I think the activity of a module is a very important thing. I think should find a technical/literal way to describe what the module does. Any technical writers around?
- Perhaps we should make it so inactive modules are greyed out in the module section, as to encourage to adoption of more stable projects.
- Perhaps after a certain amount of inactivity/lack of response in support, it can slowly fade into a "legacy" class if it's not widely adopted.
- Call homes
- Speaking about adoption, how about about some anonymous/call-home options in drupal versions so we can have a peak at what modules are being used? Voluntarily of course.
- Perhaps we can have error reporting/bug requests through the admin system? If a lot of drupals send home a certain error (along with their specs), it can then send create a ticket that needs to be addressed. Perhaps a rudimentary version of this would be neat in the beta/alphas/development versions? Also voluntarily
- If not, how about drupal creating a detailed error report on production sites so we can easily point out problems and post it on forums/send through e-mails? Perhaps the error report can include the line number, but also the lines of code surrounding it? The specs/setup? Detailed enough to give community helpers enough info to give a response.
These sound like big projects, but I think enabling the rudimentary aspects of them would be nice. I think of the module section like an apple tree. Modules are cool when they are being actively developed, and we need to help people choose the healthiest apples, while not inhibiting the desires of people who have legitimate reasons to fork.
Comments
everything here is already underway...
almost everything you suggest is already underway:
agreed, forked modules are usually a pain, and we attempt to discourage needless forks already.
project quality metrics: http://groups.drupal.org/node/3314
phone-home to drupal.org: http://drupal.org/node/128827
...
if you care about this stuff, please get involved in helping to generate and/or test patches for the project.module (which is what drives the modules area on drupal.org). see http://groups.drupal.org/node/3686 for details on how you can help.
thanks,
-derek
___________________
3281d Consulting