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.