Fwd: Re: [PHP-DEV] Re: new bug viewing/editing form
oops, forgot to cc: php-dev. - Forwarded message from Peter Lowe [EMAIL PROTECTED] - Date: Mon, 7 Jan 2002 10:20:39 +0100 From: Peter Lowe [EMAIL PROTECTED] To: Melvyn Sopacua [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: new bug viewing/editing form Reply-To: [EMAIL PROTECTED] On Jan 06, 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. Floods can be easily detected, and bugs which outstand tremendously can be investigated. There's also a much easier authentication for votes, which separates humans from bots, described here: http://www.webtechniques.com/archives/2001/12/perl/ unfortunately fairly trivial to bypass: http://www.perlmonks.org/index.pl?node_id=124732lastnode_id=15004 although the way altavista use this technique with their url submission service (http://addurl.altavista.com/sites/addurl/newurl) would be a lot more secure. - peter. Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster greeting season=newyear XML-error: undefined entity peace at line 1. /greeting -- 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] -- This is *probably* not the signature you are looking for. Move along. - End forwarded message - -- This is *probably* not the signature you are looking for. Move along. -- 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-DEV] Re: new bug viewing/editing form
Hello, Jim Winstead wrote: as threatened after i implemented bug voting, i've redesign the bug Congratulations! Voting is an excellent idea that will help developers to sort out the priorities of what bugs should be fixed first. Just a couple of comments: - Voting does not work on Opera 5.05 for Linux. When you submit the vote, it fails with the message missing parameter score. - 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. Keep up the good work, 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]
Re: [PHP-DEV] Re: new bug viewing/editing form
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. Floods can be easily detected, and bugs which outstand tremendously can be investigated. There's also a much easier authentication for votes, which separates humans from bots, described here: http://www.webtechniques.com/archives/2001/12/perl/ Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster greeting season=newyear XML-error: undefined entity peace at line 1. /greeting -- 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-DEV] Re: new bug viewing/editing form
Manuel Lemos [EMAIL PROTECTED] wrote: Jim Winstead wrote: as threatened after i implemented bug voting, i've redesign the bug Congratulations! Voting is an excellent idea that will help developers to sort out the priorities of what bugs should be fixed first. Just a couple of comments: the voting has been there for a week or so, actually. it is just hard to notice on the current page because wide comments cause it to get pushed way off to the right. - Voting does not work on Opera 5.05 for Linux. When you submit the vote, it fails with the message missing parameter score. it's a bug in opera. http://bugs.php.net/~jimw/bugs/opera-broken.php but because of the order of the fields on the new page, this bug doesn't get triggered there. - 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. i really, really do not want to force people to register and deal with all that. if abuse of the voting system becomes a problem, we'll figure out a way to deal with it at that time. (the voting does track the ip of submissions, so that is one easy filter that can be applied.) i have my doubts that the voting will really prove all that useful in cajoling developers to work on specific bugs. i suspect it will be more useful in getting users to notice bugs that have already been reported. (and it is a safety valve for preventing 'me too!' comments now that anyone will be able to add a comment to a bug.) jim -- 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]
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-DEV] Re: new bug viewing/editing form
Hello, Jim Winstead wrote: - Voting does not work on Opera 5.05 for Linux. When you submit the vote, it fails with the message missing parameter score. it's a bug in opera. http://bugs.php.net/~jimw/bugs/opera-broken.php but because of the order of the fields on the new page, this bug doesn't get triggered there. What do you mean? I just noticed that it still causes the problem above. - 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. i really, really do not want to force people to register and deal with all that. if abuse of the voting system becomes a problem, we'll figure out a way to deal with it at that time. (the voting does track the ip of submissions, so that is one easy filter that can be applied.) hummm... I was able to vote on the same bug several times in a row and it counted. Are you sure that IP filter is working? Anyway, that is easy to work around, especially because the source of the page is available, and who intends to fool the system will always find a easy way to do it. i have my doubts that the voting will really prove all that useful in cajoling developers to work on specific bugs. i suspect it will be more I think it will help the QA time to concentrate on bugs that seem more urgent, if the vote system can work reliably. 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]
RE: [PHP-DEV] Re: new bug viewing/editing form
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]
Re: [PHP-DEV] Re: new bug viewing/editing form
Hi, Bugzilla implements that kind of authentication to avoid reports from faked people that do not intend to provide feedback later. Which is what you want, for a good voting system. You want users, who took the time to search through the active database, to cast their vote, so developers get some idea of the impact of the bug. Registration is a 2-step (do + confirm) boundery that takes away a lot of the potential voters, for reasons ranging from lack of anti-paranoia medication to time constraints and Jolt overdose. 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? You wouldn't and an IP/cookie based session, would take care of most of that. If somebody actually takes to the time to use multiple IP addresses, and browsers to cast a not too suspiscious amount of votes over a lenghtly period of time, let's just reward this frustration, before the poor guy jumps off some building. No matter what procedural importance you award to the voting tool, it will be emone of the/em factors, which stimulates a (group of) developers to work on a bug. Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster greeting season=newyear XML-error: undefined entity peace at line 1. /greeting -- 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]
RE: [PHP-DEV] Re: new bug viewing/editing form
Lukas Smith said at 23:37 6-1-2002: Anyways I guess the important thing is to think about the audience you are trying to get to report bugs. That wouldn't necessarily be the same people, who you need for a vote. The audience for a vote, would be to get an indication of the affected sites (would have been wonderful to have that available during the whole exit() discussion) and to get an insight on how important your usergroup perceives the issue. For instance obsoleting mysql_db_query from the next release, would be a good test :-) This would also make descisions for a maintenance release have some more measurable criteria. That people also provide feedback, is a plus. And this can now be done, because not only the original reporter of a bug can post feedback, but anybody. That is however a seperate plus to the new bug system, besides the voting improvements. Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster greeting season=newyear XML-error: undefined entity peace at line 1. /greeting -- 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-DEV] Re: new bug viewing/editing form
Manuel Lemos [EMAIL PROTECTED] wrote: Jim Winstead wrote: - Voting does not work on Opera 5.05 for Linux. When you submit the vote, it fails with the message missing parameter score. it's a bug in opera. http://bugs.php.net/~jimw/bugs/opera-broken.php but because of the order of the fields on the new page, this bug doesn't get triggered there. What do you mean? I just noticed that it still causes the problem above. i mean there is a bug in opera that causes voting to fail on the existing bug viewing/voting/editing page (where the voting stuff is in a box that is floated to the right of the bug header). in my testing, the bug in opera is no longer triggered by the new version of this page (where the voting form is below the bug header). regardless of whether the new version triggers this bug in opera or not, it remains a bug in opera. i'm not going to spend any more of my time figuring out how to work around it. i really, really do not want to force people to register and deal with all that. if abuse of the voting system becomes a problem, we'll figure out a way to deal with it at that time. (the voting does track the ip of submissions, so that is one easy filter that can be applied.) hummm... I was able to vote on the same bug several times in a row and it counted. Are you sure that IP filter is working? there is no filter. the ip is only being tracked at this time. Anyway, that is easy to work around, especially because the source of the page is available, and who intends to fool the system will always find a easy way to do it. of course. that's why i am sticking with the path of least resistance. if the existing bug-voting system proves to not be useful (because of people stuffing the ballot box, or not voting, or whatever), we can always change it (slightly or dramatically). but until that happens, i see very little reason to change it. i have my doubts that the voting will really prove all that useful in cajoling developers to work on specific bugs. i suspect it will be more I think it will help the QA time to concentrate on bugs that seem more urgent, if the vote system can work reliably. my doubts come from a long time of watching developers of php work on what they want to work on, without a great deal of concern for what it is that users want. i don't see any reason to believe requiring people to register to vote on bugs will change that situation. jim -- 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]
