On Wed, 19 Mar 2008 18:11:07 -0400 "Ezra B. Gildesgame" <ezra@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