Magnus Manske wrote:
David Gerard wrote:
A previous version of the code (not the current version, I think?) loaded *all* revisions of the article being rated, and switching it on would have caused an extremely unhappy DB server and a top-50 error message pretty much instantly ;-)
I *think* I fixed this...
So how do we establish this to Brion's satisfaction?
- d.
David Gerard wrote:
Magnus Manske wrote:
David Gerard wrote:
A previous version of the code (not the current version, I think?) loaded *all* revisions of the article being rated, and switching it on would have caused an extremely unhappy DB server and a top-50 error message pretty much instantly ;-)
I *think* I fixed this...
So how do we establish this to Brion's satisfaction?
Well, we could * buy another 100 servers, set up a complete clone of ours, then simulate millions of users rating articles or * turn the darn thing on at the live wiki. We could use the German one if Brion's scared with the English one, there's way less users there, and they'll love it, as we are in a perpetual quality discussion there anyway...
*If* the servers do get sluggish from all the article rating, just turn it off again. I would fully understand if there were security concerns or we-can-never-turn-it-back issues, but a little slowness for a little time /as worst case/ is plaing it too safe IMHO. After all, it wouldn't really be wikipedia if it weren't slow, eh? ;-)
The only other way to convince Brion I can think of would be for him to look closely at the code and decide for himself if it's too risky. Me, I think it's ready. Of course, I thought the same thing about phase2 code, with all features enabled...
Magnus
There are still numerous issues with this validation feature, both internal and external, I've pointed some of these out in the past.
1. The UI sucks
When you turn on this feature, go to a random page and click the "validate" tab you're presented with this: http://kohl.wikimedia.org/~avar/tmp/revisions.png A form that, excuse me for saying so, looks like shit, and furthermore makes no sense at all, if you follow the 'See the validation statistics for "Main Page" here' link you're presented with this: http://kohl.wikimedia.org/~avar/tmp/validation.png Again, something that makes no sense at all, and it doesn't get any better when you follow the 'Show my validations' link, then you're presented with this: http://kohl.wikimedia.org/~avar/tmp/overview.png ...and those numbers are supposed to mean..? And it doesn't get any better, in fact, I've been fiddling with this thing for 20 minutes and still haven't figured out how to make it do *anything at all*, it says things like "Your ratings have been stored!" and yet it saves nothing to the validate table.
2. It's impossible to fully translate the UI Please use wfMsg() for every string that should be translated, don't hardcode messages in the code.
3. It's going to be slow
Here are some examples, with line numbers, of it making queries with no LIMIT claues where the set of return values could get very large:
82 $res = $db->select( 'validate', '*', array( 'val_page' => 0 ), 'SpecialValidate::getTopicList' );
225 $res = $db->select( 'validate', '*', array_merge( array( 'val_page' => $id ), $this->identifyUser($user) ) );
$limit here is a user supplied value with no upper limit enforced: 245 $b = array ( "ORDER BY" => "val_page,val_revision" , "OFFSET" => $offset , "LIMIT" => $limit ) ; 246 $res = $db->select( 'validate', '*', $a , 'getAllVotesList' , $b );
Ævar Arnfjörð Bjarmason wrote:
There are still numerous issues with this validation feature, both internal and external, I've pointed some of these out in the past.
- The UI sucks
The text is changeable through the normal MediaWiki way. The colors etc. are CSS.
When you turn on this feature, go to a random page and click the "validate" tab you're presented with this: http://kohl.wikimedia.org/~avar/tmp/revisions.png
Well, apart from the black buttons, which seem to come from your personal settings (?), you haven't define any topics to validate/rate, which makes it kind of hard to display a list of these... See: http://magnusmanske.de/wikipedia/rate1.png for how it would look like (again, color is CSS).
A form that, excuse me for saying so, looks like shit, and furthermore makes no sense at all, if you follow the 'See the validation statistics for "Main Page" here' link you're presented with this: http://kohl.wikimedia.org/~avar/tmp/validation.png
Again, no topics defined. No topics, no ratings. Of course the page looks rather plain.
Again, something that makes no sense at all, and it doesn't get any better when you follow the 'Show my validations' link, then you're presented with this: http://kohl.wikimedia.org/~avar/tmp/overview.png ...and those numbers are supposed to mean..?
Again...
And it doesn't get any better, in fact, I've been fiddling with this thing for 20 minutes and still haven't figured out how to make it do *anything at all*, it says things like "Your ratings have been stored!" and yet it saves nothing to the validate table.
- It's impossible to fully translate the UI
Please use wfMsg() for every string that should be translated, don't hardcode messages in the code.
Is it, keeping up the high quality of your review, in any way possible that you didn't use the latest version? Because that *does* use wfMsg throughout. The latest version is in CVS HEAD; copying it back to the 1.5 tree should do nicely.
- It's going to be slow
Here are some examples, with line numbers, of it making queries with no LIMIT claues where the set of return values could get very large:
82 $res = $db->select( 'validate', '*', array( 'val_page' => 0 ), 'SpecialValidate::getTopicList' );
You omitted: # NOTE : This query returns only the topics to vote on So, if there are, say, fifteen topics defined, it returns fifteen entries. This will, of cource, clearly overload our 100+ servers.
225 $res = $db->select( 'validate', '*', array_merge( array( 'val_page' => $id ), $this->identifyUser($user) ) );
You omitted: # NOTE : This query gets the votes for a single user on a single page. # Assuming most people will use the "merge" feature, # this will be only a single entry.
$limit here is a user supplied value with no upper limit enforced: 245 $b = array ( "ORDER BY" => "val_page,val_revision" , "OFFSET" => $offset , "LIMIT" => $limit ) ; 246 $res = $db->select( 'validate', '*', $a , 'getAllVotesList' , $b );
You omitted: # Reads a partial vote list for this user for all articles
Yes, that one could become potentially large over time, except for the LIMIT you quoted yourself. The default call (line 747) sets the limit to 25.
So, if we could please go back to the state of the feature *right now*, which is basically the same as *before WikiMania*. If there's anything to complain about, please tell me or (shock!) take a minute and fix it. It's supposed to be a collaborative effort, though this long demanded feature sure as hell hasn't see its share of it.
Magnus (state: slightly annoyed)
After reading the messages below, a couple of (really obvious) suggestions for the rating feature:
- a "No topics defined" message that appears when no topics are defined, instead of a strage things like "1-0".
- some reasonable LIMITs on queries, that became limits on the feature: a maximum number of topics, a maximum number of ratings for a single page, and so on.
Alfio
On Thu, 27 Oct 2005, Magnus Manske wrote:
Ævar Arnfjörð Bjarmason wrote:
There are still numerous issues with this validation feature, both internal and external, I've pointed some of these out in the past.
- The UI sucks
The text is changeable through the normal MediaWiki way. The colors etc. are CSS.
When you turn on this feature, go to a random page and click the "validate" tab you're presented with this: http://kohl.wikimedia.org/~avar/tmp/revisions.png
Well, apart from the black buttons, which seem to come from your personal settings (?), you haven't define any topics to validate/rate, which makes it kind of hard to display a list of these... See: http://magnusmanske.de/wikipedia/rate1.png for how it would look like (again, color is CSS).
A form that, excuse me for saying so, looks like shit, and furthermore makes no sense at all, if you follow the 'See the validation statistics for "Main Page" here' link you're presented with this: http://kohl.wikimedia.org/~avar/tmp/validation.png
Again, no topics defined. No topics, no ratings. Of course the page looks rather plain.
Again, something that makes no sense at all, and it doesn't get any better when you follow the 'Show my validations' link, then you're presented with this: http://kohl.wikimedia.org/~avar/tmp/overview.png ...and those numbers are supposed to mean..?
Again...
And it doesn't get any better, in fact, I've been fiddling with this thing for 20 minutes and still haven't figured out how to make it do *anything at all*, it says things like "Your ratings have been stored!" and yet it saves nothing to the validate table.
- It's impossible to fully translate the UI
Please use wfMsg() for every string that should be translated, don't hardcode messages in the code.
Is it, keeping up the high quality of your review, in any way possible that you didn't use the latest version? Because that *does* use wfMsg throughout. The latest version is in CVS HEAD; copying it back to the 1.5 tree should do nicely.
- It's going to be slow
Here are some examples, with line numbers, of it making queries with no LIMIT claues where the set of return values could get very large:
82 $res = $db->select( 'validate', '*', array( 'val_page' => 0 ), 'SpecialValidate::getTopicList' );
You omitted: # NOTE : This query returns only the topics to vote on So, if there are, say, fifteen topics defined, it returns fifteen entries. This will, of cource, clearly overload our 100+ servers.
225 $res = $db->select( 'validate', '*', array_merge( array( 'val_page' => $id ), $this->identifyUser($user) ) );
You omitted: # NOTE : This query gets the votes for a single user on a single page. # Assuming most people will use the "merge" feature, # this will be only a single entry.
$limit here is a user supplied value with no upper limit enforced: 245 $b = array ( "ORDER BY" => "val_page,val_revision" , "OFFSET" => $offset , "LIMIT" => $limit ) ; 246 $res = $db->select( 'validate', '*', $a , 'getAllVotesList' , $b );
You omitted: # Reads a partial vote list for this user for all articles
Yes, that one could become potentially large over time, except for the LIMIT you quoted yourself. The default call (line 747) sets the limit to 25.
So, if we could please go back to the state of the feature *right now*, which is basically the same as *before WikiMania*. If there's anything to complain about, please tell me or (shock!) take a minute and fix it. It's supposed to be a collaborative effort, though this long demanded feature sure as hell hasn't see its share of it.
Magnus (state: slightly annoyed)
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Alfio Puglisi wrote:
After reading the messages below, a couple of (really obvious) suggestions for the rating feature:
- a "No topics defined" message that appears when no topics are
defined, instead of a strage things like "1-0".
Sure, I can do that, not that it would be a problem on wikipedia - we already have topic lists on meta for en and de waiting to implemented, once the feature is activated.
- some reasonable LIMITs on queries, that became limits on the
feature: a maximum number of topics, a maximum number of ratings for a single page, and so on.
I'm not sure I follow here. Topics will be decided upon by careful consensus, as it is hard to change them "after the fact" (that is, after people rated them). That, and that alone, will determine the number of topics. Personally, I expect that number to stay below 20.
And what about a "maximum number of ratings for a single page"? Like, only five people can rate a version of a page? Or one person can only rate five versions of a page? Sorry, I don't understand.
Magnus
P.S.: I think I actually found a *real* bug; it seems anyone can change the list of topics. I'll have to restrict that to sysops.
On Sat, 29 Oct 2005, Magnus Manske wrote:
Alfio Puglisi wrote:
- some reasonable LIMITs on queries, that became limits on the feature: a
maximum number of topics, a maximum number of ratings for a single page, and so on.
I'm not sure I follow here. Topics will be decided upon by careful consensus, as it is hard to change them "after the fact" (that is, after people rated them). That, and that alone, will determine the number of topics. Personally, I expect that number to stay below 20.
Sure, but better enforce it with some hard limit - say maximum 50 topics or whatever.
And what about a "maximum number of ratings for a single page"?
That was for a specific db query that I didn't really understand, so scrap it.
Alfio
Alfio Puglisi wrote:
On Sat, 29 Oct 2005, Magnus Manske wrote:
Alfio Puglisi wrote:
- some reasonable LIMITs on queries, that became limits on the
feature: a maximum number of topics, a maximum number of ratings for a single page, and so on.
I'm not sure I follow here. Topics will be decided upon by careful consensus, as it is hard to change them "after the fact" (that is, after people rated them). That, and that alone, will determine the number of topics. Personally, I expect that number to stay below 20.
Sure, but better enforce it with some hard limit - say maximum 50 topics or whatever.
Done. Set it to 25 by deafult, can be overridden in LocalSettings. I also added an error message if there are no topics defined, pointing you to the page where you can set them up.
And what about a "maximum number of ratings for a single page"?
That was for a specific db query that I didn't really understand, so scrap it.
Finally! Proof that one doesn't need Perl or C to obfuscate code - I can do it with SQL as well ;-)
Magnus
wikitech-l@lists.wikimedia.org