Excerpts from Sebastian Nowicki's message of Mon Dec 28 09:09:36 +0100 2009:
On 27/12/2009, at 3:35 PM, kludge wrote:
On 12/26/2009 10:00 PM, Sebastian Nowicki wrote:
Hi,
I believe this was discussed on aur-dev some years ago, but it seems that discussion was lost (no longer in archives). I'd like to bring up the subject again. What do you think the best way to indicate package popularity is? The two main ideas were votes (the current implementation) and a download counter. I can't really recall which one was preferred.
The issue has been raised because we're deciding which to use in "AUR2", as a patch has been submitted to implement votes.
I'd like to know if voting works, how effective it is, and how much significance it has on a TU's decision to put a package into community. Basically whether it's "broken" and needs to be "fixed" or if it's fine the way it is.
P.S. I didn't send this to aur-dev as it doesn't really concern the developers. It's an end-user feature, and mostly a feature for TUs, so I posted here.
that is (or at least has been) a much thornier question than i think you think it is.
search through this list's archives around starting around november of 2008. this might be a good starting point:
http://mailman.archlinux.org/pipermail/aur-general/2008-November/002790.html
some choice reading there!
-kludge
Thanks for the link, but that discussion seems to have a different focus. I'm not concerned with policy about the metric, I'm just looking for a more optimal solution for an indication of the usage of a package. I don't expect to be able to provide an accurate indication, just a more accurate one than through a primitive voting system. There are some valid points in there though.
On 27/12/2009, at 12:28 PM, Alexander Lam wrote:
Although I know that personally, I forget to vote often, there is a flaw with counting downloads: I try out a lot of packages and if they don't fit my needs, I don't want my vote/download counted.
On Sat, Dec 26, 2009 at 11:00 PM, Sebastian Nowicki <sebnow@gmail.com>wrote:
On 27/12/2009, at 3:37 PM, Jeff Horelick wrote:
My problem with voting is that stuff like...Say i use one of the firefox-like packages in the AUR (swiftfox, swiftweasel, firefox- beta, what have you) and I vote for it, but then I switch to Chrome/Chromium. It's unlikely that i'll ever remember to un-vote when i switch which would skew the popularity/vote rating for the firefox package.
These are some of the reasons I have been thinking of a time-scaled voting/download hybrid. Votes would be tracked as they have been, and a download counter would be introduced. However these two statistics would be affected by time in some sort of a mathematical function which would result in a "popularity" statistic. I believe there are many such functions around used for sites like Digg and Reddit. Old votes/downloads would be less significant, so issues such as switching software (firefox -> chromium for example) wouldn't be as severe.
The reason for introducing a download counter is because it would indicate how many users _continue_ to use a package. You can vote only once, and possibly forget about the vote (and hence not un-vote), but if you upgrade, this gets tracked and affects the "popularity" statistic.
If a package is extremely popular at one point, but then becomes obsolete by a "next generation" package, the popularity of the obsolete package will decrease over time, although the votes and downloads would increase slightly, if at all.
There are two major issues I have with a download counter though. One being spamming, which would only be easily avoided by banning certain IPs for an amount of time (however requiring IP tracking, which is a privacy issue). The other is having to "proxy" the download through a script to actually track the download. This shouldn't really be a problem if done right, but it can be a point of failure and adds unnecessary complexity.
I think this has another flaw: For package A there might be two releases per year, for package B 15. For package C there might be only one update per upstream release, for package D there might be 5. Assuming the user follows what's available the aforementioned differences alone make the download numbers meaningless with regards to popularity. Regards, Philipp