[development] module duplication in Drupal contrib

[Ivan Sergio Borgonovo]

On Wed, 19 Mar 2008 18:11:07 -0400
"Ezra B. Gildesgame" <ezra at pingv.com> wrote:

>   Ivan Sergio Borgonovo wrote:
> > ...it took less to write code than understand what the module
> > really did or compare it with modules with similar functionality.
> > ...
> > With smaller modules sometimes choosing
> > takes more than writing.

> And isn't taking the time to evaluate existing functionality  
> fundamental to participating effectively in an open source
> project? I'd argue that someone who is universally unable to so is
> likely to hinder more than help the community effort.

Could be... but what about writing a module that requires more effort
to understand what it does than writing another?

> I propose that if a project is potentially a duplicate of another  
> module, that an explanation of any differences and the reason for  
> creating a separate module be required in that module's project  
> description. This explanation does not necessarily have to be  

Yeah... and who's going to check?
You'd say "the community"... but well isn't it exactly the thing we
would like to avoid? That people spend a lot of time looking through
duplicates? duplicating their works to find duplicates?

Larry was pointing out one problem of writing duplicates... waste of
resources... but well first you'd be able to find if there is a
duplicate module, then you've to evaluate it (compare it with more
than one module), then you've to see if you can contribute[1] to the
one you think is most similar to your needs.

If you give easy tools to developers to help people spot duplicates
and give tools to people to add metadata to projects... you'll avoid
some work duplication and make it easier to compare modules.

A thing that I think could be implemented easily would be to increase
the level of the module taxonomy. There are categories that contains
too many modules, once you read the whole list just to take out a
couple of candidates you're tired enough.

Another thing could be to put some metadata in the .info file.

Relationship between modules as seen on drupalmodules.com is a good
idea too.

Project pages may start to contain a feature list (mandatory? this
shouldn't stop dev to contribute).

People should be able to add info to module docs easier but with some
QA... this could be related on how you manage RTBC.

The module SE should be improved.

The policy: we will kill duplicate modules won't work... you're still
putting too much work on the team that manage the cvs to decide if a
module is duplicated.
Just writing it somewhere doesn't help too much too.

Suppose you find something that is reasonably easy to tweak than
rewriting from scratch, but doesn't do exactly what you need.
Would it help to add to each module page a quick guideline on how to
contribute?
I'd say that writing in each module page "if you want to contribute
just place a patch in the issue queue" could help.
If no one reply... you still have what you need and you may go
further contacting the maintainers or asking to become the new
maintainer.
But sometimes the simplest advices are the most useful.


[1] this depends on many factors: quality of code, people,
documentation, responsiveness of the original dev, "burocracy"
involved for a maintainer change....

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it