< note_to_self> < /note_to_self>

Obligatory note:
There is no perfect voting system, just as there is no perfect distribution, just as ...


Ebuild votes.

In general such approaches are possible:

Personally I think in favour of the second option.
First raises serious privacy concerns (it's kind of Microsoft way of doing things), and is hard to implement technically (and as such error prone). It will require a VERY large database, as votes shell better be unique. Besides it only allows for positive votes. It should be possible to implement negative votes, but non-trivial, as there is no direct correspondence (package may not be installed because it does not build or just because it was not installed :-)).

Second option should be better, the only catch - it requires active users. However I consider this to be a very reasonable requirement. Either be a silent user and accept life (err, your system) as it is, or stand up and vote.
Already existing infrastructure at bugs.gentoo.org can be used to implement voting system. Users will need to have an account to get accounted. One way would be to submit votes via bugzilla (similar to bugs/new ebuilds). Another possibility is to have a special tool or just an option to emerge (such as emerge --vote=vote package) which will mark the package as having certain vote set. Votes shell be uploaded/accounted upon the next rsync. This also requires to keep vote database, but only on active users (which is the case now anyway), so this is already better.

There is another possibility. Why not drop requirement for vote uniqueness? Users are still required to actively vote via command-line tool (or option to emerge). Votes are getting counted upon rsync. Upon EVERY rsync. And just counted - no control over who submits what.
This is certainly the easiest one to implement. It does not seem to be terribly off either:

So it looks like this will be per test/use voting rather than per user. It may actually be even more accurate, as well as simpler.

It can be supported in the following way.
On CVS every ebuild gets a companion .vote-stats file. For example app-editors/vim will contain vim-6.0-r4.ebuild vim-6.0-r4.vote-stats vim-6.0-r5.ebuild vim-6.0-r5.vote-stats (just a part of it of course). These files contain only global vote statistics, such as cumulative vote. There is no per-user database with this approach at all.
User-side portage tree will contain .vote files instead. These files will be created and updated by vote utility locally. .vote-stats will be updated from .vote files upon rsync. .vote-stats files are not checked out and reside solely on server (however I do not see why should it be outright prohibited either. People might want to look at the stats out of curiosity. Apparently the files shall not be propagated upwards :-)).

This mechanism can be further simplified by splitting rsync and vote update functionality. There can be a special tool (or emerge option) such as emerge rsync-votes which will only propagate votes upwards (remember, votes are counted EVERY time they are submitted either via rsync or rsync-votes). And rsync will only rsync (downwards flow of ebuilds only).
This seems more to be a more secure alternative technically. However these two mechanisms will provide different results and combined rsync/vote-update might be preferable. Though my estimate is that representativity (i.e. what package gets more votes) will be quite similar, only distribution (hight and shape of vote maxima) will change.

There is a significant problem inherent to "memory-less" votes. Users will be able to cast multiple votes in a very short period of time. After all, is it so hard to write something like:
while true; do emerge rsync-votes; done;?
And wait for a while :-)?

To alleviate this problem it is probably better to consider a combination of per test and per user methods. For example user may be allowed to vote only once per day (normal rsync should apparently not be inhibited). To enforce this server can accumulate ip's from which votes were cast during the day and just drop repeated incoming vote (until the list gets cleared at midnight). Alternatively it is possible to block votes if they arrive from the same ip or user as the previous vote. Effectively user will have to wait until somebody else votes, before repeating his votes. Many more are possible.

Well, counting ip's is probably not a very good idea. People with access to the range of ip's will be able to cast multiple votes per day, while people on a masqueraded LAN will not be able to vote in parallel. It still looks like everybody wishing to vote will have to register on bugs.gentoo.org and present these credentials when updating the votes (not necessarily manually, the credentials can live somewhere in config file after all).

Side-note (vote propagation):
Ebuilds have dependencies, they tend to depend on libraries. People might want to use some application but not necessarily know about all libraries it depends on. And it is just a duplicate work to look for every dependency and figure out its status and whethere a vote should be submitted for it. It makes perfect sense to automate this process. Vote utility should look for dependencies of a requested ebuild and set votes for all such packages automatically.

Another procedural note:
This is by no means a complete review of vote systems or anything pretending to be very serious. The main purpose of this write up is to solicit opinions on this subject. Comments are greatly appreciated.


Developer ratings.

Just a brief idea at this point.

It would be useful to provide developer ratings as a way to automate training and "certification". Something along the lines of what is done in slashdot. We can call it [developer] rating or karma or even entropy. Last two are not really nice as large values of both indicate bad rating even though sound cool. Well, whatever we call it, the most important part is how it works.

Choosing the amounts given or subtracted will require further investigation. I just want to introduce the outline now.

So, how to use these ratings?
When developer will vote for a package he will add not just 1 vote but the amount proportional to his rating. Thus when he reaches certain level he will be able to confirm the package on his own! While this is still not exactly a core developer omnipotence, but it gets pretty close. In addition I am sure core developers will listen to such people more carefully (this is never enforced but always happens :-)).

Every ability yields responsibility.
For certain additional feedback mechanism is necessary to keep high-rank developers from suddenly turning evil (I cant help it, this is what always gets mentioned in such situation :-)). This can be provided by a "meta-votes". Regular users (well, in fact better just anybody) can meta-vote the votes submitted by developers. This should influence developer rating but not his casted vote, so that high-rank developers would be able to force unpopular decision for a short time if they think it is necessary. If the decision holds up and users finally change their mind developers regain their points. If it turns out wrong, they loose points and cannot hold against the rest of population and thus decision gets overturned.

Again, this is not a complete vote system overview by any means. Just a rough draft. Please send in your comments.

Email me, post a message to gentoo-dev mailing list, or use my feedback form.