[aur-general] Package voting alternatives
hollunder at lavabit.com
Mon Dec 28 04:29:52 EST 2009
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"
> 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
More information about the aur-general