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 <[email protected]> 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
