1 |
Hi guys. |
2 |
|
3 |
Nice to see voting/user feedback discussed here! |
4 |
I have spent some time few month ago thinking about similar issue. I would |
5 |
like to point out this link |
6 |
http://www.its.caltech.edu/~georges/gentoo/epsp/vote0.html |
7 |
where I present a few thoughts about possible voting system. |
8 |
I should immediately note, that I was "designing" (well, "0" in the file name |
9 |
should give you an idea about its status :)) that system for a very specific |
10 |
purpose - to enhance quality control over ebuilds by allowing all users to |
11 |
cast their votes indicating ebuild stability and (optionally) popularity. |
12 |
Accumulation of additional information may provide nice statistics. However I |
13 |
would like to add one "feature request" to Rufiao's proposal. Namely the |
14 |
ability to configure what kinds of information are collected and sent |
15 |
upstream. |
16 |
|
17 |
As I see there are two possible approaches towards design of voting system: |
18 |
1. active system - passive users |
19 |
2. passive system - active users |
20 |
|
21 |
In reality any reasonable voting system should include elements of both, the |
22 |
question is more about proportions :). In that text I was leaning more |
23 |
towards second option. You will find few arguments behind my thinking. |
24 |
Nonetheless the system I was in the end describing seems to be very similar |
25 |
to the one proposed by Rufiao :), including concerns about use of ips for |
26 |
identification and requirement to register. Though overall procedure looks a |
27 |
bit simplier. |
28 |
|
29 |
Along the same lines there are two "boundary" positions WRT how much |
30 |
information is collected and processed. |
31 |
1. Collect info about individual systems in central location and use that to |
32 |
build statistics. (pretty much necessary for 1st approach) |
33 |
2. Only keep statistical info centrally and update it when user votes. May |
34 |
play well with 2nd approach if done correctly. |
35 |
|
36 |
As was pointed out second position raises abuse concerns. However I would |
37 |
still prefer such approach if some care could turn up a reasonably secure |
38 |
model. At least it would be worth to try that as a first implementation, as |
39 |
it is much easier on resources and implementation. |
40 |
|
41 |
Sorry about this rough posting, just wanted to bring up that link in case you |
42 |
will be able find anything usefull there :). I will try to get back to this |
43 |
topic and may be write something more detailed :). |
44 |
|
45 |
George |
46 |
|
47 |
|
48 |
On Sunday 16 June 2002 16:11, Rufiao wrote: |
49 |
> The abuse of this kind of system should be taken into account, since it may |
50 |
> be quite easy for someone to create a bot (or whatever) capable of feeding |
51 |
> the system with fake data, and by consequence destroy its reputation. |
52 |
> |
53 |
> However, I agree this issue should not complicate the system setup. There |
54 |
> are problems with the approach I've described, in particular for users who |
55 |
> maintain more than a couple of Gentoo boxes (it may be inconvenient even |
56 |
> for people who run more than one machine, due to the fact it's necessary to |
57 |
> have one key per machine). |
58 |
> |
59 |
> Debian's popularity-contest uses SMTP as its transport, both to avoid the |
60 |
> need for constant internet connection and to have some means to ensure the |
61 |
> identity of every contributing machine. I'm not sure SMTP can help on the |
62 |
> identification of users at all, and it may complicate the setup even more |
63 |
> for users who don't have local MTA spools set (and which want to |
64 |
> participate but don't have constant connectivity), so I've discarded it. |
65 |
> |
66 |
> Also, using the machine's IP addresses as a measure of abuse (by |
67 |
> investigating how many posts occur for a given address) may lead to bad |
68 |
> results, since some users have more than one machine under a 1:n NAT. |
69 |
> |
70 |
> In the end, it may be better to simply avoid the signup, and use some |
71 |
> 'loose' approach, which is to ask the user's e-mail to be used just in the |
72 |
> case of abuse detection (of course a 'bad' user could provide a fake e-mail |
73 |
> address, but in this case, after the detection of abuse and a unsucessful |
74 |
> attempt to contact the user, all his provided data can be set to be |
75 |
> automatically rejected by the server-side system). |
76 |
> |
77 |
> But it may happen there's a better approach for this whole problem.. Any |
78 |
> thoughts? |
79 |
> |