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