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

On 28/12/2009, at 5:40 PM, Ray Rashif wrote:

2009/12/28 Philipp Überbacher :

...

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 :)

In all seriousness, it would to an extent. Votes could be made more significant than downloads, and downloads could be time-scaled more severely than votes, etc. The downloads of a frequently updated package as opposed to an infrequently updated package can be normalized. It is a very good point though. The question is, would this system be more accurate than plain votes, and would it be worth implementing it? There will never ever be a flawless algorithm, we just need one that's the most suitable. Perhaps I'm over-complicating things and a voting system is enough. After all TUs make the final decision about which packages get into community.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, Dec 28, 2009 at 06:52, Malte Rabenseifner wrote:

wine-wc3 (http://aur.archlinux.org/packages.php?ID=27444) is an unmaintained duplicate of wine-wc (http://aur.archlinux.org/packages.php?ID=27298).

--

Malte Rabenseifner malte@zearan.de Germany

Deleted, thank you. -- Ranguvar [Devin Cofer] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iQIcBAEBCgAGBQJLONUqAAoJEHdXKOHe3MUTiWsP/RLyAmB96enwYCYDq8rbrZt7 y3JQomNgpTLHxiEosAF5aC6uNQb+euX8qRCSRgSbY+yd5fX/yJF72TKN/Z/vyM85 AgGtz+iFZD4WXT5Lp91/70Y0NhaOVUZ8kSaO4NikzU4Lwhq8yGkS+Ol4VBUD4Zor +yKWB2lajpi70YZaCEuvlZxM88ub9OHAIbb6XEMCh64LF4hrqCr32KeNZEsoupVM 4pQtAJpA1zCIT4/MwydsakhjddmJhFnllzrIAxYZ9+xJyqopYMMfX7qYSfWxipO1 eNr9DLenTwnmID6KslDryBZrZ5DF/UtBp5/XHdfd5ACx8JxT1NCcP/X0SvEMwd5e tEIEtTLnnOgLPXThLkGvmUzPS2dIf9+yC6FDqsrmlb0gHOVDCS6Nk+snF1uVnSuW QmVndf0mTU8b8ajrk+JCZdqp7gtXkFZpaude3yzmZp8w2wqG9DpzGr4ebqJa7LTJ 3tdchNn6HQw4/KAmcb3ap/VglBTDTfr1xT9tvmZLKcgtr8+zFjgjSbIzBVBFFlw1 3JKOd3lTTOwm1EVVPLxGhL7jrWbOl9O6hMU8jhHo0gkXDWjVQ1IMEqm9FrnN6Asa QmYfebQLw6czybYJfH7we2yKFAwNlP84d/YDpKSuvvjNkfYMq54bZI0Q8qTy/Piu jMAp2JLmLkj5TAbbv5iz =NxPO -----END PGP SIGNATURE-----

On 28/12/2009, at 8:16 PM, Philipp Überbacher wrote:

Excerpts from Sebastian Nowicki's message of Mon Dec 28 10:54:14 +0100 2009:

...

On 28/12/2009, at 5:40 PM, Ray Rashif wrote:

...

2009/12/28 Philipp Überbacher :

...

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 :)

In all seriousness, it would to an extent. Votes could be made more significant than downloads, and downloads could be time-scaled more severely than votes, etc. The downloads of a frequently updated package as opposed to an infrequently updated package can be normalized. It is a very good point though. The question is, would this system be more accurate than plain votes, and would it be worth implementing it?

There will never ever be a flawless algorithm, we just need one that's the most suitable. Perhaps I'm over-complicating things and a voting system is enough. After all TUs make the final decision about which packages get into community.

Personally I think you're overcomplicating things. To me it seems the votes don't matter anyway. There are guidelines for the number of needed votes afaik but from my limited experience packages only get into community when a TU is interested in them, in which case the votecount doesn't matter at all.

I agree. So it seems votes are fine the way they are then?

Personally I think you're overcomplicating things. To me it seems the votes don't matter anyway. There are guidelines for the number of needed votes afaik but from my limited experience packages only get into community when a TU is interested in them, in which case the votecount doesn't matter at all.

A package must be popular in order to enter [community], where *popular* is defined as >= 10 votes on the AUR or >= 1% usage according to pkgstats. There are some exceptions to that rule: i18n packages, drivers, and accessibility packages. Generally speaking, numbers are necessary. A popular package isn't guaranteed to enter [community], depending on the interest and discretion of TUs. We do need to be able to measure usage somehow, be it votes, download counts, pkgstats, or what have you. As someone else mentioned in this thread, none of these is really perfect. -- Chris

On 29/12/2009, at 5:42 AM, Aaron Schaefer wrote:

Man, this thread really drums up some nitpicks of mine regarding the current, somewhat arbitrary, ways of establishing package usage & popularity. I won't rehash my old arguments here, but if you're looking for a "better" statistical way of ranking popularity using a voting system, you might want to take a look at a Wilson score confidence intervals:

http://www.evanmiller.org/how-not-to-sort-by-average-rating.html

You'd probably need to compare something like downloads to votes since we don't really have/need up and down votes, but it could make sorting by statistical popularity a bit more accurate.

-- Aaron "ElasticDog" Schaefer

I think this might be one of those algorithms I was looking for. Thanks! On 29/12/2009, at 5:46 AM, Florian Friesdorf wrote:

I think the general idea that people express their support through a vote is good. I often install a package just to test it and to realize that I don't need it. Don't see why this should increase the popularity, one could argue it should decrease...

With the "hybrid" idea, as already stated, the significance of downloads could be much lower than that of votes, meaning that a single download would make a very small difference, and would soon be (almost) forgotten due to it being scaled by time. On 29/12/2009, at 7:30 AM, Philipp Überbacher wrote:

Excerpts from Florian Friesdorf's message of Mon Dec 28 22:46:38 +0100 2009:

...

On Mon, Dec 28, 2009 at 01:16:56PM +0100, Philipp Überbacher wrote:

Further I'd like to see a list of all packages I voted for, so far I was not able to get this - might be my lack of knowledge.

Me neither. you can kind of see this for the packages you maintain in aur. You get a list where you can see the voted and notify status for each. Having something like this for the aur webinterface search, or more easily available through a link on your 'aur home' page would be nice. Same for notify. I guess this only needs coding.

I actually want to expand upon the notification idea with "AUR2," it will likely require its own notification management interface, but that's another topic ;). Showing packages you voted for would be trivial in "AUR2," not sure about AUR. I imagine it wouldn't be that hard.

Excerpts from Florian Friesdorf's message of Mon Dec 28 22:46:38 +0100 2009:

On Mon, Dec 28, 2009 at 01:16:56PM +0100, Philipp Überbacher wrote:

Further I'd like to see a list of all packages I voted for, so far I was not able to get this - might be my lack of knowledge.

Me neither. you can kind of see this for the packages you maintain in aur. You get a list where you can see the voted and notify status for each. Having something like this for the aur webinterface search, or more easily available through a link on your 'aur home' page would be nice. Same for notify. I guess this only needs coding.

2009/12/27 Jeff Horelick :

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