I actually did some thinking about this stuff the other night and figured I would just throw this idea out there. What if a system was developed that monitored modules based upon the issue queue activity and usage statistics. A formula is derived to determine when a module seems to be abandoned. Once that criteria is met there is a notice on the module's page that the module is not currently maintained, maybe even with a link to a form or something "if you are interested in maintaining this module, click here". A reporting mechanism could also be devised for modules that have gone so long without a maintainer, then someone with the proper permissions could evaluate the need and usage of that module as well as the condition of the issue queue and make a determination if it should just be removed or not. Basically what this could do is make new module submissions more lenient. If John Doe comes up with a module and decides to include it on DO then he can get his account and add it. If 6 months down the road the issue queue has X number of open issues and John Doe hasn't even touched any of them then the module can be marked as "needs maintainer". Another 6 months down the road if there is no maintainer, nothing being fixed in the issue queue and the usage of that module is near 0 then one of the higher powers can go ahead and just remove it from DO. IMHO this would also help encourage more to help maintain modules. Right now the module's page is either edited to say it needs a maintainer or the current maintainer emails the mailing lists looking for someone. If there was an alert on the module designed so that it really stands out, then that might encourage Visitor X, who happens to need that module, to say "hey this could be my chance to give back a little". There could even be a list of unmaintained modules people could easily look at and see if they wanted to pick up anything. Like I said, I was just throwing this idea around in my mind and thought I would share it with everyone to see what they think. Jamie Holly Dave Reid wrote:

For reference, the application was http://drupal.org/node/578596.

And the point that could have been better made is that should we allow each tiny module to add SimpleNews subscription forms to a single module's code? Or should there maybe be a sub-module of SimpleNews that allows users to add subscription checkboxes to any form or page and would be infinately more useful to the community?

Also the module provided for review was sloppy, and limited to only one newsletter, and as someone pointed out, didn't even work. But again, that never made it into the review.

Also please see my earlier points about community needing to get involved with reviews. You can point out things that went wrong all day, but until you provide reasonable and actionable solutions, nothing is going to help.

Dave Reid dave@davereid.net <mailto:dave@davereid.net>

On Wed, Oct 28, 2009 at 12:29 PM, Jeff Greenberg <jeff@ayendesigns.com <mailto:jeff@ayendesigns.com>> wrote:

So, here's another example (I think) of what I would consider CVS censorship. I've spent a couple hours already today trying to get a simplenews subscription checkbox onto the Ubercart checkout. Found the function in simplenews, but it has a parm that I can't find the source of, etc. Busy work that I don't need.

I find an entry at Ubercart after much searching, for a module that was developed -just for this- requirement. It adds a simplenews newsletter subscription pane to the checkout process.

Here is the author's explanation of why it's listed there and not at drupal.org <http://drupal.org>:

"I think the module was a bit too simple to put on the main Drupal site (my application for a CVS account was rejected Smiling so I'll put it here instead."

Heck, there are many still on 5.x, or on the current release with large issue queues, which look interesting that I've stumbled across...

...which is the result of too many modules and too many people scratching their own itch for their own little use-cases instead of joining forces on making the existing a better product for all. sun

An overabundance of modules with overlapping functionalities is not a CVS problem, it's a module/project parsing and rating problem, something that DrupalModules.com helps address and what the D.o redesign is also intended to address.

A friendly policy would be to first make it easy peasy to get people involved and excited about contributing their own itch they scratched, and then get them involved in collaborations and consolidations. After all, much of what ends up being overlapping functionality is because the developer had a project that needed X and did not have the time or resources to try to get Y to change to solve his/her use case. I feel we should let that developer serve his/her client and contribute what was done, and let improvements and consolidations happen within the community.

I disagree. - We want healthy stuff in contrib, because everything else is cruft. - We want working stuff in contrib, because users already have very hard times to find proper, working stuff. - We want to encourage people to join forces with others, because that is what the overall success of the Drupal community and the Drupal product boils down to. sun

On 10/28/2009 02:21 PM, Jeff Greenberg wrote:

So what is the mechanism for joining forces and beefing up an initial pre-release module before the module is even listed? Where is the community location to do that? In the past the stronger parts of the development community have been small enough and tight-knit enough to collaborate in IRC and through this list. As drupal grows and our interests and backgrounds diverge, this just isnt the case anymore. I agree we should allow people to contribute these modules no matter how trivial or poorly written. These modules would serve as a place to begin cooporative efforts and provide all the mechanisms we would be reinventing in a GDO group or elsewhere (issue lists, releases, VCS, etc).

I also agree that we dont want normal folks stumbling over these modules because they provide little value to most people and add a lot of distraction from the real valuable modules (views, cck, image*, token, pathauto, ubercart, etc) that everyone needs but has trouble finding because there is already too much cruft displayed by default. Id like to suggest implementing either a "featured" flag and defaulting the normal modules pages to that flag or allowing developer a self imposed "hide by default" flag. Alternatively we could let users filter by the number of installations reported and defualt the project page to a reasonable number like 50. Its ok to make harder things slightly harder and easy things easy. You shouldn't expect the same experience as a module developer looking for a project might implement some esoteric checkbox as you should as a normal admin user trying to ad images to your nodes. Lets assume the modyule developer will know how to change the "flag" or the "number of installations" cut off or just search for the thing. -mf

On Oct 28, 2009, at Wed 10/28/09 1:13pm, Daniel F. Kudwien wrote:

I disagree.

- We want healthy stuff in contrib, because everything else is cruft.

This relates to finding, not contributing.

- We want working stuff in contrib, because users already have very hard times to find proper, working stuff.

Again, this relates to finding, not contributing.

- We want to encourage people to join forces with others, because that is what the overall success of the Drupal community and the Drupal product boils down to.

And you get people to join forces by empowering them, not telling them they're too late to just do it, now they have to please the status quo. L