module duplication in Drupal contrib

Not entirely sure how feasible this would be but...

When I used media temple for hosting, and you had a problem,
you'd
fill in a form to get technical support, but you'd hit
submit and it'd
suggest some KB articles to look at that were 'similar'. If
none of
those really answered the problem then you could submit a
new issue.

In the same way when you submit a new module it would be
cool if d.o
somehow suggested similar modules (based on keywords maybe)
and then
rather than blindly creating a new module you'd get some
help finding
duplicates.

Side note: Not having *any* metrics for projects on d.o is a
very
serious problem.

On Thu, Mar 20, 2008 at 11:38 PM, Darrel O'Pry
<darrel.oprygmail.com> wrote:
> Some modules are sledge hammers and some are
scalpels... duplication
>  isn't bad... making core more accessible for modules
to implement
>  features should be the focus of collaboration.
>
>  Policing whether collaboration happens at the contrib
module level or
>  not is probably a tragic was of community resource and
a further attempt
>  to apply more structure to the very successful
anarchist environment
>  call cvs.drupal.org/cvs/drupal-contrib
>
>
>
>
>  On Wed, 2008-03-19 at 11:25 -0300, Greg Knaddison -
GVS wrote:
>  > Hi,
>  >
>  > "Modules that duplicate functionality
available from an existing
>  > module are damaging to the Drupal project."
>  >
>  > Please support or refute that statement and
propose strategies for
>  > managing CVS applications and/or projects on
Drupal.org in a way that
>  > will best help the Drupal project.
>  >
>  > I'm using "Drupal project" in a very
loose sense so you should infer
>  > that it includes lots of groups of people like
new users, site
>  > builders, contributors, drupal.org admins, the
security team, etc.
>  >
>  > Thanks,
>  > Greg
>  >
>
>



-- 
Regards
Steven Jones

Quoting Larry Garfield <larrygarfieldtech.com>:

> On Tuesday 25 March 2008, Steven Jones wrote:

>
> Make modules more findable, and let developers use
their judgment in a fully
> informed manner.
>

We really need hierarchal tagging of the modules. Having
more than 300 
in Content on d.o/project/Modules doesn't help me find
squat.  And what 
is the difference between ``Content'' and ``Content
display''?  A 
search form for just the project nodes would be nice, then I
could 
drill down better.

>> Side note: Not having *any* metrics for projects on
d.o is a very
>> serious problem.
>
> Better no metrics than bad metrics.  If, for instance,
we rated 
> module quality
> strictly on the number of open support requests there
were in the issue
> queue, Views would come out as a module to never ever
ever use.  That would
> also be quite wrong. 
>

I agree.  Any ratings would need to reset with each release
as well.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.
com/