On Tue, 10 Mar 2009 22:24:05 -0400 Andrew Berry <andrewberry@sentex.net> wrote:
On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
To some degree, chx and I already started that with DrupalToughLove.com.
DTL looked to be very promising. I found the reviews done to be practical in that even though they weren't my modules, they still
Jumping in here... not strictly related to these 2 posts. There are thousands modules. If you restrict your interest to 3 or 4 to evaluate a review is useful. If you can't even find the best candidates to compare, a review is like someone donating you a Ferrari and leaving it in an unknown place in Atacama. What I'd find useful would be - better categorisation system and better search system on categories - a flag to check if a module provides an API or is just an application - an activity index (average lines of code changed/time) - a issue queue index (how many issues open, how much people subscribed to them, % of issues closed) Asking developers to list similar modules is asking for good will. Asking for good will generally is not enough, rewarding good will is better. If developers could classify better their modules it would be easier to search for similar modules and developers could make easier to find their own creatures too. Coming up with a good categorisation system isn't easy. I think debtag is trying to achieve a similar target, but I don't know how successfully and how much of their efforts we could share. In each project page there is a link to statistics... but if you're comparing projects you've to open one more page for comparing and the statistics aren't synthetic enough. What I generally end up doing is open 2 to 4 categories, skim through the modules, open several other tabs, read the description of the modules I've opened, shrink the selection as much as possible... download the modules and look at the code, README etc... if really forced install the survivors. Somehow once I have few candidates even if a review of the module may be helpful the decision is going to be based on details that hardly could be expressed synthetically and are very "context" sensitive (specific to the situation I'm trying to solve). At this level you just have to hope the maintainer of the project spent some time to describe what makes its creature special to select further before testing/looking at the code. I don't think developers find very rewarding adding descriptions, maybe they would find more rewarding adding feature lists. Still developers may write modules for very different reasons. I think having a community that *may* support your module *could* be a good reason to promote the diffusion of your module... but it may not be the case... and still you may be contributing in a valuable way to drupal community. Maybe we could let people (other than the maintainers) to "categorise" the project. After all every user have to read the list of projects before choosing one, compare them etc... this efforts are collectively repeated thousands time. It's a pity they get wasted. Use cloud tagging for similarity and categories. And this is rewarding for users... they are going to search through modules more than one time... if they could tag them they would lower their efforts the next time. I hope that every module developer started as a potential module user so he searched at least once in the projects to see is something was fit for its need. Even if I'm planning to start a "duplicate" I'm interested to know other people's approach to my similar problem. I really don't see duplication as a problem. If you've bad developers... even if they could easily find similar modules they may find silly reasons to start new ones. But there may be thousands good reasons for duplication: - a maintainer is not willing to accept changes - framework modules vs. ready to use modules - deadlines - ... A successful project is not determined by "code quality" alone and not every time developers may have common interests. Determining if there is no real good reason for duplicating the functionality of a project is not an easy task. There may be time when the developer is just an asshole... in that case I doubt you can direct his efforts to a more valuable target convincing him to submit patches to another project. So the cost/missed return of one more project developed by an asshole is just the cost in searching through modules, not the sum of the cost of searching through modules and the missed contribution of one more developer to an existing project. On the other hand if you're not dealing with an asshole, he may have had his good reasons to start a new project. Consider that there are modules you could write in an hour and it may take more than an hour to search through the project list and learn how certain modules have to be used... and even when you may find one that nearly fit your needs, it may not just fit your needs as much the one you may write. Of course this is going to happen for the very simplest modules but still the effort of looking through all the list of available modules impact the community much more than having few duplicates of small modules. Lowering the cost of searching and comparing will lower the duplicates. Furthermore... how can you cheaply know if a new module is a duplicate without good search tools? Let alone evaluating if a duplicate will negatively impact the community. Every *effort* to regulate duplication of modules have to pass through better tools to search through modules. Every *effort* to regulate duplication is an *effort* and sincerely the return looks dubious. -- Ivan Sergio Borgonovo http://www.webthatworks.it