I have seen this used (doesn't even Yahoo use this?) Anyways I guess the important thing is to think about the audience you are trying to get to report bugs.
What is important to get anything fixed? The initial Report and then Feedback! What slows down fixes: Bug reports without Feedback (as you are likely to waste a lot of time) So how to best get it this worked out? 1) Get people that actually care to have this bug fixed. 2) Have a method to contact the person for additional feedback. 3) Make the people think before they report if this really is a bug 4) Atleast some level of competence The down side of course is that registering might turn off some people. But those do not fall in 1), so we can maybe live without their reports to begin with? So the downside is actually its upside! It ensures that you get the type of person that fit 1) and enables 2). Since you have to provide your email address you also might take more care as to your quality. This is just a mind thing and obviously you can register using any email address that you normally do not use at all. But I think requiring registration still helps a bit with 3). So for 1) - 3) registration will help. For 4) ... well registration is not much of a test :-) But 2,5 out of 4 is quite good :-) Obviously the people that fit 1) potentially might also have an interest in manipulating the votes. This also helps stop multiple votes (does not make it impossible though) Best regards, Lukas Smith [EMAIL PROTECTED] _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] _______________________________ > -----Original Message----- > From: Manuel Lemos [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 06, 2002 11:20 PM > To: [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] Re: new bug viewing/editing form > > Hello, > > Melvyn Sopacua wrote: > > > > Manuel Lemos said at 22:18 6-1-2002: > > > > >- Assuming that the number of votes may influence in the priority that > > >developers will give to fix each bug, it seems easy to mislead > > >developers because somebody that realizes that may submit a bunch of > > >votes just to make it outstand in the pending bug queue. I suggest that > > >you adopt an authentication scheme like bugzilla, that requires > > >submitters to subscribe confirming the subscriptions by e-mail. This > > >way, multiple votes from the same subscriber would only count as one. > > > > If you go down that road, instead of assuming mature users, and kicking > > out the occasional kid, you'll end up with a lot of maintenance in the > > the subscriber database, deleting numerous hotmail accounts. > > I think that bug reporters and people that know and understand the point > of the bug database are mature users. > > Bugzilla implements that kind of authentication to avoid reports from > faked people that do not intend to provide feedback later. > > > > > Floods can be easily detected, and bugs which outstand tremendously can > > be investigated. > > The problem to avoid here are not exactly floods, but the occasional > user that in the hope of having his reports addressed with greater > priority would submit say like 12 votes. How would you tell if those > votes would be from the same user or not? > > > > > There's also a much easier authentication for votes, which separates > > humans from bots, described here: > > http://www.webtechniques.com/archives/2001/12/perl/ > > Interesting. This would be better than it is now, despite it would not > avoid the problem. > > Regards, > Manuel Lemos > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
