FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux User Repository

 
 
LinkBack Thread Tools
 
Old 12-28-2009, 08:54 AM
Sebastian Nowicki
 
Default Package voting alternatives

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


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


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.
 
Old 12-28-2009, 11:16 AM
Philipp ‹berbacher
 
Default Package voting alternatives

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 <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
>
> 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.
 
Old 12-28-2009, 12:48 PM
Sebastian Nowicki
 
Default Package voting alternatives

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


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?
 
Old 12-28-2009, 12:58 PM
Philipp ‹berbacher
 
Default Package voting alternatives

Excerpts from Sebastian Nowicki's message of Mon Dec 28 14:48:59 +0100 2009:
>
> 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 <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
> >>
> >> 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?
>

Imho votes themselves are as good as it gets. This doesn't mean there
can't be improvement in that area.
Should the votes be adhered to more closely?
Are there ways to get rid of no longer relevant votes? (which are ?)
Is there a feasible way to transfer votes in case of a package rename?
Is there another way to remind the user what he has voted for?
..
just some thoughts.

Regards,
Philipp
 
Old 12-28-2009, 02:50 PM
Chris Brannon
 
Default Package voting alternatives

> 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
 
Old 12-28-2009, 08:42 PM
Aaron Schaefer
 
Default Package voting alternatives

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
 
Old 12-28-2009, 08:46 PM
Florian Friesdorf
 
Default Package voting alternatives

On Mon, Dec 28, 2009 at 01:16:56PM +0100, Philipp ‹berbacher wrote:
> Personally I think you're overcomplicating things.

I share this thought.

> 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 wish this would be different.

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

What about votes that are valid two months + a monthly voting cronjob
(the time spans are just exemplary)?

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.

--
Florian Friesdorf <flo@chaoflow.net>
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: flo@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
 
Old 12-28-2009, 10:30 PM
Philipp ‹berbacher
 
Default Package voting alternatives

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.
 
Old 12-29-2009, 10:11 AM
Sebastian Nowicki
 
Default Package voting alternatives

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.
 

Thread Tools




All times are GMT. The time now is 05:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org