[development] re CVS requirements

[Jamie Holly]

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 at davereid.net <mailto:dave at davereid.net>
>
>
> On Wed, Oct 28, 2009 at 12:29 PM, Jeff Greenberg <jeff at ayendesigns.com 
> <mailto:jeff at 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."
>
>