[aur-general] Package voting alternatives

[Sebastian Nowicki]

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.