[development] Consolidating duplicate contrib modules for D7

[Sam Tresler]

I think this is a fairly accurate assessment, however, I am not  
convinced that there isn't one other alternative long-term solution we  
could consider.  Personally, I'd like to see us develop a cultural  
feature in the community where we incorporate into 'the Drupal way'  
collaboration instead of division.  (No I'm not saying we don't do  
this already, I'm saying we could do more).  It's almost always easier  
to whip out a quick custom module to scratch your own itch than it is  
to collaborate with an existing module owner to patch their code  
inorder to abstract it.  But the end result is frequently better for  
both parties and thus should be preferred.


1) Don't Hack Core.
2) Meld modules instead of splintering.
3) Code is gold.

etc. etc.


On Dec 4, 2009, at 2:04 PM, Steven Peck wrote:

> Differences occur because
> - development happened in a similar time frame.
> - developers do not play well with each other.
> - developer B has contempt for developer A's code
> - and is not courteous in discussions of said codes weakness so does
> their own project.
> - modules seem the same but use wildly differing methods to achieve
> their results.
>
>
> The problem with the 'have the doc team do it' pretends we have
> assigned people that will magically carry this out.
> - They will install various modules on clean test sites.
> - They will have use cases which will allow the evaluation of the
> modules in questions
> - They assume the module contributor in question is responsive and
> that duplication is the result of 'just happened' instead of hostility
> between developers.
> - The modules are actually similar enough in function to be  
> accurately compared.
> - Users will magically find the module comparison page and it will be
> up to date.
>
> Not really going to happen.
>
> The best long term suggestion is to have the maintainers clearly
> document any differences on their project page (preferably the ones
> who are second should do this by default).  People (devs) who have a
> need for a module and had to evaluate could submit an issue with a
> request to have an updated 'difference' description added.  Suggested
> sample text would probably help.  A module maintainer is not
> necessarily willing to go download a similar  module if theirs already
> fills their needs.
>
> The ones that are not used die out as tracked on the usage page.
>
> I would suggest a linked article on how to evaluate a project for use
> (and suggest how to get description updates) linked to the top of the
> Projects page description would be more useful.
>
> sepeck
>
>
> On Thu, Dec 3, 2009 at 3:36 PM, nan wich <nan_wich at bellsouth.net>  
> wrote:
>> Shai Gluskin wrote:
>>> Asking the docs team to write module comparison pieces is a good  
>>> thing too
>>
>> NO!!!  The comparison pieces should be written by the module  
>> developers or
>> one of their advanced users.
>>
>>
>> Nancy E. Wichmann, PMP
>>
>> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin  
>> L. King,
>> Jr.
>>
>>