[aur-general] Package voting alternatives

[Philipp Überbacher]

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 at 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