Re: Re: Re: Gathering module usage statistics

If I know that Excel::Template, for instance, was downloaded 1500 times in the past month, but Graph::Template was only downloaded 3 times, I know where I'll be putting the few hours I have.

The problem here is that you don't know why Graph::Template was only downloaded 3 times. Speaking purely hypothetically, maybe people looked at the documentation of Graph::Template, decided it sucked, and moved on to something else. But the people looking at Excel::Template (which targets an almost completely different format, and thus likely has a different userbase) thought it was pretty good as it is and use it all the time. In that case, you'd probably want to put more effort into fixing Graph::Template.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Comment on Re: Re: Re: Gathering module usage statistics Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: Gathering module usage statistics by dragonchild (Archbishop) on May 04, 2004 at 20:02 UTC
That's one way to look at it. Here's another: I once was a participant in a seminar on testing strategies. The speaker was discussing various ways of allocating testing time. He touched on one strategy which basically went like this: 90% of all usage of Quicken will be in the ledger. 90% of all user perception of our product will be based on the performance of the ledger. Maybe we should focus a larger proportion of our testing of Quicken on the ledger. This isn't to say that the other 90% of the code shouldn't be tested. But, that which has a greater proportion in consumer perception should be more heavily tested. This has a direct correlation to open-source development. If a module isn't being downloaded, I should not spend my extremely small amount of time on it. Instead, I should focus where I get the greater bang for the buck. Yes, Graph::Template may have all sorts of reasons why it isn't being downloaded. But, the fact is that it's not being downloaded (in your example). So, until it is, or I have more free time, it's not a priority. It's basic triage of development time. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Gathering module usage statistics
by dragonchild (Archbishop) on May 04, 2004 at 20:02 UTC

I once was a participant in a seminar on testing strategies. The speaker was discussing various ways of allocating testing time. He touched on one strategy which basically went like this:

90% of all usage of Quicken will be in the ledger.
90% of all user perception of our product will be based on the performance of the ledger.
Maybe we should focus a larger proportion of our testing of Quicken on the ledger.

This isn't to say that the other 90% of the code shouldn't be tested. But, that which has a greater proportion in consumer perception should be more heavily tested.

This has a direct correlation to open-source development. If a module isn't being downloaded, I should not spend my extremely small amount of time on it. Instead, I should focus where I get the greater bang for the buck.

Yes, Graph::Template may have all sorts of reasons why it isn't being downloaded. But, the fact is that it's not being downloaded (in your example). So, until it is, or I have more free time, it's not a priority.

It's basic triage of development time.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]