[development] development Digest, Vol 83, Issue 34

[nan wich]

David Burns wrote:
> Once an Alpha module gains popularity and is approved as unique 
 
First, how is an "alpha" module shown? We already have users who won't touch dev versions because of the big red X on the project page. Do you propose some other designation that will also tell users not to use it?
 
As for unique, I think there is already considerable agreement that "unique" is not always good. Sometimes a "duplicate" module with [even slightly] different functionality is a least not bad.
 
Let's take an example with which I am intimately familiar: a links page module.. In my search for a good one, I found 5 on DO. I finally decided that Web Links was the closest to what I wanted. Unfortunately, it hadn't been maintained very well to that point (okay, none of them were). At that time, a new maintainer was taking over. I submitted a few patches and convinced the new owner to let me help. Maybe he shouldn't have, because I don't there is a single line of original code left; it has evolved significantly since then. Meanwhile, we added conversion features from the others to give the users the option of switching. Finally one of them became available, so I took it over, made a few fixes, then wrote another conversion and officialy killed that module. While 4 of them still show as available, theer are really  only 2 now. We also contributed a comparison page to the handbooks.
 
I don't expect all "duplicates" to follow this model, but I think it is a more sane approach to this problem. As someone said, don't make it harder to contribute modules, make it easier for the adopter to find the one that is right for him/her. And encourage those people to help the next person by contributing comparisons.

 
Nancy E. Wichmann, PMP
(781) 697-6344
 
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091118/106c228c/attachment.html