re CVS requirements

[Jeff Greenberg-3]

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:

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

[davereid]

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@...

On Wed, Oct 28, 2009 at 12:29 PM, Jeff Greenberg <jeff@...> 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:

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

[Jeff Greenberg-3]

David, points taken. Every case is different. With this one, having a
[selfish?] need, my take would be that optimally, if a few people would
benefit from adding the subscription to the order process, it would be
easier for me/us to improve the module than for each of us to have to
write one for our own use. I understand that we don't want to release
modules that are anything but high quality, but isn't that what dev is
for? To take a good idea and do what's needed to make it ready for prime
time?


Dave Reid wrote:

>
> 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.
Jeff

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

[Laura Scott-2]

It seems the actionable solution is to allow people to contribute what  
they're doing, and let the consolidation happen in the community,  
rather than what some people might feel is a "bow down to Zod" kind of  
gatekeeping.

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.

Laura

On Oct 28, 2009, at Wed 10/28/09 11:53am, 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@...
>
>
> On Wed, Oct 28, 2009 at 12:29 PM, Jeff Greenberg  
> <jeff@...> 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
> :
>
> "I think the module was a bit too simple to put on the main Drupal  
> site (my application for a CVS account was rejected <smile.png> so  
> I'll put it here instead."
>
>

[Jeff Greenberg-3]

Jamie Holly wrote:

> 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.
I think that's a great idea. 'Needs maintainer' and/or 'Abandoned' etc.
could be subscription items too. It would be a nice list to receive.
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...I would
guess there are folks out there with some time available who haven't had
the chance/luck/misfortune to stumble upon them.

[Daniel F. Kudwien]

> 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

[Daniel F. Kudwien]

> 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

[Jeff Greenberg-3]

> 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
>
>  

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? Also, with it not being listed as a
module -until- all that is done, is the reward working on it for 2, 3, 4
months and then seeing someone else list their module which does the
same thing 5 days before yours is 'satisfactory' ?

[Michael Favia-2]

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

[Laura Scott-2]

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

[Jeff Greenberg-3]

Michael Favia wrote:

> 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).
Maybe there needs to be a project/Modules/development that's arranged
sort of the same, until the module is ready for beta (dev)?