Uncyclopedia:Rating System/Archive 1

Discussion and plan for Uncyclopedia Rating System.

Welcome to Uncyc 2.0, the new paradigm shift of the future of the web. Utilizing our content-free core contempencies, we will adjust using our agile tactics to the constantly changing uncyclopedic joke market.

The concept is that we will instance a rating system in Uncyclopedia to assign a rating to each page. This is like the "validation" thing in Wikipedia which is being proposed.

Rating style plans:

• QDB style rating system. See www.bash.org. Each page is assigned a persistent score that can be upped and downed by each user once. Conceptually we start at zero, and everybody can adjust the score. The immediately obvious problem with this system is that our content is constantly changing and a persistent score may not make sense. If we do this, one idea may be to figure out a way to age our scores so they aren't consistently crap.

• 5 star style system where we maintain a running average of the score and some way to remove old scores. A possibility is that we can only use the ratings given to the last X revisions, or the last X given ratings to the page, but this can be easily abused by revising the page alot.

Layout plans:

• Additional box on the left side, somewhere.
• Next to the page title, on the top right side.
• Bottom of the page.
• User control line, (about, discussion.... watch, rating)

Coders sign here.

If you are interested in coding for this project, sign here. Requirements are php familiarity, willingness to license code under GPL, and wilingness to work with mediawiki and learn it.

PHP is my strongest language, and I can give you a resume (literally) if you want. GPL is the ONLY thing I am willing to code under (or some wannabe variant there of) and I am willing to work with mediawiki -- Village Idiot♠KUN Free Speech 02:34, 25 February 2006 (UTC)

I'm an interested. I just made this from scratch, so that might possibly give you an idea of my PHPness.—Sir Mandaliet ♠ CUN PS VFH GN (talk) 02:44, 25 February 2006 (UTC)

Count me in. --Algorithm (talk) 08:13, 25 February 2006 (UTC)

I've made MediaWiki extensions and mods before, so sure. --Sir Volte KUN Talk (+S NS CM Bur. VFP VFH) 16:28, 25 February 2006 (UTC)

I'll help. » Brig Sir Dawg | t | v | c » 21:01, 26 February 2006 (UTC)

You can talk here. Please give any suggestions you can, including alternate plans.

User control line makes the most sense, I feel. And I like stars. Like Christina Aguilera. Because stupid crap floats to the top and stays if it's a straight-point +/- system. Sir Famine, Gun ♣ Petition » 02:26, 25 February 2006 (UTC)

it could also double as the VFD. If a article recieved enough no stars then bye bye.Also can the vote template be automaticly inserted into all create discussion pages? Da, Y?YY?YYY?:-:CUN³ NotM BLK |_LG⁸+::: 07:49, 11 February 2006 (UTC)

Not only the VFD. Your mind is narrow, it could be the VFD the VFH and the VFP all at once. Anyway, has anyone ever visited HOTorNOT? I think that a rating system similar to that, where you just average people's ratings on a 1-10 scale would be useful. But I also like the straight-out +/- scale. Starting at zero of course, or whatever. We should have it start at 398... yea... Anyway, I think I'm done. God speed.   t o m p k i n s  blah. ﺞوﻦ וףה ՃՄ ண்ஸ ފއހ วอฏม +տ trade websites 02:35, 25 February 2006 (UTC)

2

Rating

***** - 10

**** - 6

*** - 2

** - 5

* - 9

---

I'm worried that an average will penalize the really interesting pages. For example, there's a page I'm too PC to mention the name of except that it starts with the letter N. One day my friend Jose convinced me to overcome my wussiness and view it, and it was teh cool. But it also hits close to home, and I can see it getting a bunch of Zeroes. In fact, I'd wager that the best pages on Uncyclopedia will have a combination of strong feelings both ways -- all 5-stars and 0-stars, nothing in between. How about this: a box that shows how many users gave each rating? (please don't hold the ugly box above against this idea, fix it!) -- Sir BobBobBob ! S ? [rox!|sux!] 02:56, 25 February 2006 (UTC)

Your chart above still gives an average score of 3.2 - not terrific, but not auto-delete either. I think that a rating system will do just that - give us some idea of where an article stands. If it's between 1 and 5, it's an article. If it's below 1, it's delete worthy, and if it's above 4, it's like Euroipods. ;) Sir Famine, Gun ♣ Petition » 03:05, 25 February 2006 (UTC)

This voting sytem will prove once and for all that that article sucked. --[[User:Nintendorulez|Nintendorulez | talk]] 20:31, 26 February 2006 (UTC)

I am excited with this suggestion, but suggest proceeding with caution. I think we should collect as much data as we can from the initial run of it and slowly tweak things before we bring it to prime time or use if for vfh/d, Perhaps we could think about only having the ratings box show up for logged in users at first. ---Rev. Isra (talk) 03:51, 25 February 2006 (UTC)

Is there any way around the problems caused by AJAX described by chronarion? It would save alot of time. For those unfamiliar with Ajax, check out Google Suggestions, which offers suggestions as you type your search in real time. Then again, the interface between javascript and PHP may not be neccessary given that this IS a wiki. But can the wiki be twisted to our wick3d will to serve our purposes for editing the DB? do we have to get into the mediawiki source for that? Furthermore, soley PHP submissions REQUIRES a page refresh, AJAX would make this run smoother, kind of like what we have on the QDB. And to the best of my knowledge, javascript itself cant interface with mySQL. -- Village Idiot♠KUN Free Speech 05:29, 25 February 2006 (UTC)

It's definitely possible that we may use AJAX. One advantage and disadvantage is that it bypasses our squids. The question remains whether this is a good or bad thing. Next, do we intergrate with mediawiki or not? MW doesn't support AJAX in any way. If we do AJAX, we need a seperated backend to process this. This might be either good or bad either way. Advantage of ajax? We can display rating updates without recaching the page, which helps lower our squid cache miss. If we have to update all the time, this may be bad for squids. It would be nice to get a few MW devs in here that know. --Chronarion 01:17, 26 February 2006 (UTC)

My alternate idea, ripped from www.everything2.com . Each registered user gets a certain number of cool points per day/week/month. At their leisure they may donate/spend 1, 2, or 3 cool points to/on a page. Perhaps we impose a limit on how many points they can spend on a given page in a months time. This provides only a positive linear progression of ratings, so maybe we can spend our points negatively? Reducing the total Cool Point Value of the article. Of course this system can also be abused. --User:TD Blabber

I disagree with the idea of directly limiting the number of articles on which a user may vote. Every once in a while, we get some smartarse who tries to pull up hundreds of the uncategorised short unwikified orphan pages only to find half of them are rubbish. The user then floods QVFD with so many links to useless garbage that bannination is too good for them and only one punishment fits if they are to be stopped. We need to be able to detect users who'd try things like this, not cover up the problem by hiding it with a maximum article/vote count. These people are trouble! --Carlb 17:48, 26 February 2006 (UTC)

To avoid rate wars

I'm for the idea of making it impossible to vote twice on the same revision. --Boy Toy bitch at me 03:11, 25 February 2006 (UTC)

I am also for this. This has to be implemented anyways, or you will get revisions at -10000000. -- Village Idiot♠KUN Free Speech 05:29, 25 February 2006 (UTC)

Going along with that, how about preventing people from voting on a page imediately after they've edited it, to make things seem more fair? -- jsonitsac talk to me crimes against humanity15:54, 25 February 2006 (UTC)

It should be possible to vote twice on the same article, but the second vote should replace the first one. That way, if an article has been revised (or a vote cast in error), the user is free to revise their opinion of the page. --Carlb 17:48, 26 February 2006 (UTC)

Agreed.   t o m p k i n s  blah. ﺞوﻦ וףה ՃՄ ண்ஸ ފއހ วอฏม +տ trade websites 18:21, 26 February 2006 (UTC)

However, in that case, an article may have a bunch of 5-star votes, then one bad edit makes it a 0-star article, while it retains its 5-star rating. To really make this work, we'll definitely need a "rating history" tied to each edit. That way when you come across a 5-star rated pile of crap, you can look back and see which edit was the last time it was rated 5-stars, and revert to that edit. Sir Famine, Gun ♣ Petition » 19:29, 26 February 2006 (UTC)

I'm not talking about voting twice on one article. I'm talking about voting once on each revision. And for that matter, I think that the ratings shouldn't change if the edit is marked as minor. Of course, that could be a pain for users whose edits are automaticly set to minor, but that would ease up on the server, me thinks. --Boy Toy bitch at me 02:47, 27 February 2006 (UTC)

Hmmmmmmm .... that's complexated. I was assuming everybody would get to vote once per day on each article ... but yeah, that's weird ... hmm ... :/

I'm thinkin maybe ... we might have to abandon the Mediawiki software entirely in order to do this right. (i.e. for it to not suck) --Nerd42eMailTalkUnMetaWPediah2g2 21:01, 28 February 2006 (UTC)

Algorithm/Dawg's proposal

• Ratings will be directly tied to the page history. Each vote will be made for a specific revision.
• The total rating for the page will be determined by averaging together each user's most recent vote.
• Administrators will have the ability to invalidate revisions. Invalid revisions will not be used when calculating the page ratings. (Preferably, this will happen automatically for rolled-back edits.)
• Ideally, votes could be displayed next to the revisions in the page history (though I'm not sure how feasible this would be).

At any rate, I'm entirely willing to start looking into coding this thing. --Algorithm (talk) 08:13, 25 February 2006 (UTC)

I agree with the proposal, as invalidating revisions can be used for vandaliZm, seeing as there is no point in penalizing a page because of idiots. as for the fourth idea... MediaWiki is open source right? (Not so much as code access, because unless they used PHPBlender to compile the stuff which wouldnt run online anyways, but more for code access RIGHTS), theres no reason this can't be done. Presuming, that is, that the developers of MediaWiki put some kind of decent API together to control the thing. Otherwise this will be... annoying... but as for the coding, would it not be better to start a topic in the Forums that Algorithm put up yesterday to get some planning done first? Experience in a professional development environment tells me that jumping head first into this is a bad idea. Maybe thats what you meant when you said start looking into coding... -- Village Idiot♠KUN Free Speech 15:30, 25 February 2006 (UTC)

How does an edit affect a page's score? Does it blank it? Does it remain the same, but everone can re-vote? The reason that I ask is that I can see a couple of places for abuse:

First, if you don't keep the score between edits, all it takes is a minor edit and the score goes down/up, potentially drastically.

Second - if you've already voted, and the score is kept between versions, all you need to do is make a minor edit, and you can re-vote, ad nasuem.

In both cases, I think it makes sense to have a "last editor can't vote" rule, to make abusing the system a little harder. No sense in being able to vote on your own changes - of course you think they are good, or you shouldn't have made them - the whole point is for other users to vote on your edits. Sir Famine, Gun ♣ Petition » 18:37, 25 February 2006 (UTC)

The second case is the one being proposed. However, since only the most recent vote of any user is counted, I don't think there'll be much ballot-stuffing. --Algorithm (talk) 22:15, 25 February 2006 (UTC)

I LIKE this proposal.

• It would help deciding if a past major revision was teh crap compared to the page before revision.
• More important: should not implement a new rating just on any old edit. I, like some others, make a gob-load of edits when writing an article and sometimes go back and tweak it weeks or months later. It would be senseless to have these minor edits result in a new rating. We already have a checkbox for "minor revision", how about one for "new rating"? In the case where someone makes a whopping big change that warrants a new start, they would check the box and only then would the rating history bifurcate, with the old rating applying to the article before the revision and a new rating started for the new revision.
• I so like the word "bifurcate" -- it's so woody. Gorn. Gorn orff to bifurcate.----OEJ 19:27, 25 February 2006 (UTC)

Database Layout

The way I see it, we'll need two DB tables to make this system work.

Vote: vote_id -- Unique id for votes vote_user -- User id vote_page -- Page id vote_rev -- Revision id vote_val -- Value of vote vote_timestamp

Score: score_id -- Unique id for scores score_page -- Page id score_rev -- Revision id (if this is the overall page score, this should be 0 or NULL) score_avg -- Average score score_valid -- Boolean score_count -- Number of votes (or the number of each type of vote, in a binary array)

Alternatively, we could make use of the pre-existing but currently unused validation table, but I think that's just asking for trouble.

The tricky part using this layout is calculating averages, since only each user's most recent valid vote should be counted. Is there a simple way in MySQL to return only one row per user, or will we have to filter them after being returned? --Algorithm (talk) 02:32, 27 February 2006 (UTC)

To answer your question: Yes. Beyond that, we'll need to log the IP used for the vote so vote stuffing will be more difficult (or only allow logged in users to vote). This will add some query complexity, but nothing too extreme. » Brig Sir Dawg | t | v | c » 02:14, 1 March 2006 (UTC)

Villahj Ideeut's proposal(s)

I have a few modifications to make to Algorithms plan, as well as some code of proof for averages.

• score_page and score_rev merged to score_revpage. vote_page and vote_rev merged to vote_revpage
• pagerev of type varchar... will have a format of something like: Revision@Page
• score_id removed. redundant, as all scores should be unique anyways, there should be no more than one score for a given revision.

On a new vote, updates are as follows (Variables to be determined at time of writing left as elipses): Notice: $newVote is in this example an object (or an array, I dont give a damn) with the given fields for vote table as members. Errors will not be checked for for the sake of brevity. The code is also not commented (against my standards, yes, but I don't have all day for a quick snippet)

$mysqlLink = mysql_connect(...);
mysql_select_db(...);
$result = mysql_query("SELECT * FROM `votetable` WHERE vote_revavg=".$newVote->revavg.";");
$newSumArray = Array();
While($row = mysql_fetch_assoc($Result) {
//Note: We may need to cast $row["vote_val"] to an int depending on how we handle the DB.
    array_push($newSumArray, $row["vote_val"]);
}
$newAverage = array_sum($newSumArray)/count($newSumArray);

As for one row per user, we will only have one for each revision anyways, no multiple votes per person. -- Village Idiot♠KUN Free Speech 03:37, 28 February 2006 (UTC)

I'm afraid I don't understand your code. What do you mean by vote_revavg? You haven't defined it in your definition.

Also, I really don't agree with your proposed changes. Without an individual field for the page id, it will be more difficult to get all records for any specific page (necessary to calculate averages). And, if the page and revision are stored separately, then an id field is necessary (since neither field will be guaranteed unique). --Algorithm (talk) 04:25, 28 February 2006 (UTC)

The code is for an average of one particular revision. I did not know that we wanted a total page average as well, ok so readjustment:

revavg is a mistype, I meant revpage. Apologies.

• ids are kept, but vote ids are not unique and correspond to the score field they are for.
• The Mysql query changes to "SELECT * FROM `votetable` WHERE vote_rev='whateverRev' AND vote_page='WhateverPage'"
• mySQL for getting a total average: "SELET * FROM `votetable` WHERE id='IDOfScoreEntryItRelatesTo' AND vote_page='WhateverPage'
• The above should work, there are pretty hastily done, but the idea is clear for the averages.

-- Village Idiot♠KUN Free Speech 04:34, 28 February 2006 (UTC)

There's no need to refer to the vote ids in this instance, since limiting by the page is sufficient. Additionally, I would prefer to have some method of uniquely referring to each row in the vote table, in case we have a need for it in the future.

As for your suggested methods, the revision average would work, but your overall average is counting all votes from every user, which is not what I'm proposing here. Granted, one could filter the returned table in a relatively straightforward manner, but I'm concerned that this may not be the most optimal approach to this. --Algorithm (talk) 07:33, 28 February 2006 (UTC)

How about this:

in score table, we have two new fields, score_sum and score_numvotes where score_sum is a total kept of all the votes added together BEFORE divinding to find the average, and the score_numvotes is a number of votes for that score. score_numvotes gets incremented each vote, and the users vote is added to score_sum. The average is then simply the value of all the score_sum fields for that page added together divided by all of the score_numvotes for that page added together -- Village Idiot♠KUN Free Speech 23:29, 28 February 2006 (UTC)

VI - Your code, logic, and SQL skills appear to be woefully broken. Your code above does nothing useful. » Brig Sir Dawg | t | v | c » 02:14, 1 March 2006 (UTC)

Dawg - I misunderstood what Algo meant, made a typing error, and the SQL is something I just bashed out to give an idea. Let's not start a flame fest over hasty posting in the planning phase, hm? -- Village Idiot♠KUN Free Speech 04:38, 1 March 2006 (UTC)

VI, you're still misunderstanding me. The overall score is calculated from the most recent vote of each user. Your suggestions are all calculating from every vote ever made. This is not what is being propsed here, and will not work for our purposes. --Algorithm (talk) 05:36, 1 March 2006 (UTC)

Comments on the proposed changes:

• score_page and score_rev merged to score_revpage. vote_page and vote_rev merged to vote_revpage

Bad plan - _rev and _page are foreign keys to indexes in other tables, so combining them would slow the queries down considerably.

• pagerev of type varchar... will have a format of something like: Revision@Page

See above. In fact, this is worse than the only semi-reasonable option based on your previous proposal.

• score_id removed. redundant, as all scores should be unique anyways, there should be no more than one score for a given revision.

This is a unique ID for working with the record. It's dramatically more efficient than using the _page and _rev IDs for numerous reasons that should be glaringly obvious.

» Brig Sir Dawg | t | v | c » 06:28, 1 March 2006 (UTC)

Replace VFH?

I think this could serve as a superior method of determining our featured article on the main page. Most people don't vote on the VFH page, and there are no clear rules for doing so. Maybe we could huff VFH and replace it with this. When the rating gets high enough and when there are enough votes then the article could be on a list of future Feature Articles. Maybe we can even implement this system for featured pictures.-- jsonitsac talk to me crimes against humanity20:33, 25 February 2006 (UTC)

Perhaps, but it will have to wait until we hammer out the bugs in the Rating System. While we do have coding gods working on this, (and I sacrificed a chicken) I doubt that a system which is as needfully complex as this will work perfectly the first time. In addition to VFH, a rating system will also allow us to revert unfunny edits to versions which we know are good, rather than just picking one which looks ok at first glance. Agreed, there are many possibilities. But we'll have to wait until there's a system before we'll know if it will fit those posibilities. Sir Famine, Gun ♣ Petition » 20:45, 25 February 2006 (UTC)

REPLACE VFD!

I think this could serve as a superior method of determining which articles are worthy of deletion, using a system similar to a BLAM on Newgrounds. (i.e., if an article gets voted below a specific point, it dies) As for replacing VFH, I don't know whether that's a good idea or not, but it seems to work pretty well on Newgrounds. --Nerd42eMailTalkUnMetaWPediah2g2 20:56, 28 February 2006 (UTC)

Project Management Utility

I suggest setting the project development up on something like phpCollab. the wiki is ok but when you have a long-winded discussion often involving code like the one going on with Algorithm, it gets terribly difficult to read. I can host this on my domain if need be and everyone agrees. Also Project Management Systems are pretty standard because they allow the uploading of code, patches, assignment of tasks, etc when working with more than one or two people.