Re: module duplication in Drupal contrib

Thread: Re: module duplication in Drupal contrib

Search this list only Search all lists
Re: module duplication in Drupal contrib
United States	2008-03-19 17:11:07

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. For non-community use, such as for clients or other private projects, developers might create a custom module rather than using existing community code. These custom modules don't have much effect on the community because they don't reach the contrib repository. I don't support a policy that universally outlaws the creation of contrib modules that provide already existing functionality. I think some degree of overlap is to be expected and should be tolerated and in some cases embraced by the community. However, the act of contributing of a new project that provides overlapping or duplicate functionality should be one that is made deliberately, with an understanding by the contributor of why s/he is doing so. What is unhelpful to the community is contribution of "yet another module" that provides the same functionality as two or three other individual modules without a good reason, or at least an explanation on that module's project page. 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 officially accepted by the community to meet this requirement, but project description pages that read, "Because I didn't check the contrib repository" (for whatever reason) can be evaluated in part, on that statement by the project's maintainer. Best, Ezra Gildesgame
Re: module duplication in Drupal contrib
	2008-03-20 04:20:17
On Wed, 19 Mar 2008 18:11:07 -0400 "Ezra B. Gildesgame" <ezrapingv.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

[1-2]

about | contact Other archives ( Real Estate discussion Medical topics )