[development] Consolidating duplicate contrib modules for D7

[Jerad Bitner]

I mistook your comment about uselessness, so thanks for clarifying.

Your other comments bring up a good point too, and I wonder if there
is a metric that can be drawn from number of users/installs vs. number
of open issues vs. size of those issues (#comments) vs. ?something
else? - I'm not primarily a statistics whiz by any means, so I'm not
sure what metrics could be drawn up.

Putting actual words to the methods that we as maintainers use to
judge modules and subsequently trying to create a process or metric
based upon those words and methods would help a lot of other people
without the experience maintainers and other people who are good at
evaluating modules have.

This is really the goal here, I was just pulling the available stats
as examples or metric points to at least start somewhere, get the ball
rolling per say.

For example, there are a lot of carousel type modules out there, and
there is a decent comparison that was written up for this purpose.
http://drupal.org/node/418616

So if this type of process could be generalized a little more, even
automated to some extent as mentioned with tags and similarity and a
useful view of the different metrics we use is a worthy goal IMO.

Maybe a place in the module project page for listed features so to use
the data in comparison charts...



On Fri, Dec 4, 2009 at 3:14 PM, nan wich <nan_wich at bellsouth.net> wrote:
> Jerad Bitner wrote:
>> Saying they have no value at all is spitting in the eye of the people who
>> took the time to gather and implement them
>
>
>
> You are correct, Jerad. That is not the way I intended that to come across.
> Certainly they have value; for example, the usage stats help me decide when
> to drop a release or whether to go to a major release number or minor
> number. But as a yardstick for whether or not I should implement a module it
> is pretty meaningless. I have even been the first to implement a module
> because its project page convinced me that it solved my problem. But then, I
> also jumped in and submitted patches for the parts that didn't do what I
> wanted; eventually, the author got even with me and made me a co-maintainer.
> ;-)
>
>
>
> Issue stats are useful as well, as long as you know what you are looking
> for. For example is a module with 1000 open issues (e.g. Views) worse than
> one with no open issues? You just can't tell from that. The recent activity
> is useful on some modules, but that depends, again, on how the maintainer
> works the issue queue. I, for example, tend to work one issue at a time and
> commit the changes when it is solved. Others, such as Earl, work on several
> issues at a time and commit them all in one large chunk. Is either wrong?
> Nope, it's primarily a matter of volume and time available; I envy the
> capacity of people who can keep their focus like that.
>
>
>
> As a maintainer, I have learned how to read to issue stats and they can help
> me decide on using one module over another. But the vast majority of the
> community does not have, and probably never will have, that knowledge.
>
>
>
> I have just heard, way too many times, people coming to Drupal and saying "I
> want to install the most popular modules..." For those people, pretty much
> any metric we might display will be misused. Another message that needs to
> be repeated is "Don't let the tail wag the dog." A solution should not be
> installed until a problem has been identified. This is a big danger in any
> metrics.
>
>
>
> Nancy E. Wichmann, PMP
>
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L..
> King, Jr.
>
>



-- 
~Jerad Bitner
CTO ~ Rapid Waters Development
http://rapidwatersdev.com