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.

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@gmail.com>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.
>
>


--
Alexander Lam

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

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. Perhaps the fix for that
is to reset the votes on all packages every 6 months or something?

As far as actual voting though, i think be best option might be a sliding
vote scale, possibly like the vote at the Vim website for Vim scripts. Offer
3 "vote options" like: "Great package." "Meh." "Rubbish." and that'll likely
give the best idea of package usage/quality.

2009/12/26 Sebastian Nowicki <sebnow@gmail.com>

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

2009/12/27 Jeff Horelick <jdhore1@gmail.com>:
> As far as actual voting though, i think be best option might be a sliding
> vote scale, possibly like the vote at the Vim website for Vim scripts. Offer
> 3 "vote options" like: "Great package." "Meh." "Rubbish." and that'll likely
> give the best idea of package usage/quality.

Relative voting instead of absolute values? Could work..

The best way is of course a system like pkgstats, but that opens the
whole privacy issue etc....

DistroWatch uses a hit per day system. What about a dowload per month
counter then ?
If you like a package, you'll probably update it regularly. If you
don't like it, then the next month, your vote for this package would
be "deleted".

2009/12/27 Phillip Smith <arch-general@fukawi2.nl>:
> 2009/12/27 Jeff Horelick <jdhore1@gmail.com>:
>> As far as actual voting though, i think be best option might be a sliding
>> vote scale, possibly like the vote at the Vim website for Vim scripts. Offer
>> 3 "vote options" like: "Great package." "Meh." "Rubbish." and that'll likely
>> give the best idea of package usage/quality.
>
> Relative voting instead of absolute values? Could work..
>
> The best way is of course a system like pkgstats, but that opens the
> whole privacy issue etc....
>

> Perhaps the fix for that
> is to reset the votes on all packages every 6 months or something?

That's not good. If users forget to vote, the stats are of no use.
After 6 months, the only number still updating and voting may just be
1/10.

> Offer
> 3 "vote options" like: "Great package." "Meh." "Rubbish." and that'll likely
> give the best idea of package usage/quality.

Packages should be judged by what kind of software they
contain/provide, not "packaging quality". The purpose is to get
popular/useful software to the user, regardless of the quality of the
packaging itself. Even if it's a bad package but of good software,
more votes will make sure that it gets noticed and the right person
maintains it.

Often times, and this I can only guess, someone may be annoyed by a
failed/bad build and would refrain from voting just because of that.

The solution to this is to educate ourselves

> If you like a package, you'll probably update it regularly.

Also not a very good assumption. Remember that a lot of users run an
AUR client, so updates happen whether or not they like it (as long as
they have it installed).

/endquotes

The current mechanism works fine, except for the "package quality vs
software quality" thing.


--
GPG/PGP ID: B42DDCAD

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@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.

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

2009/12/28 Philipp Überbacher <hollunder@lavabit.com>:
> 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.

The math will take care of that


--
GPG/PGP ID: B42DDCAD