This HTML5 document contains 5 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Subject Item

n2:

rdfs:label

PvXwiki talk:Percentage Favored Vetting

rdfs:comment

This summary is given to supplement the description on the voting page due to it not giving it full justice. This is not meant to steer voters in any way.--Sefre Image:Sefresig.jpgTalk*Cont. 20:00, 12 May 2007 (CEST) I would agree with what Armond said earlier as a feasible solution, that most builds can be started out as new/untested, and that stubbing should only be done in a "worst-case" where someone adds a page which is clearly incomplete. To quote Armond-- "I propose to put a build in new builds first and from there, if necessary, put it into stubs or wait for nominations."

n5:wikiPageUsesTemplate

n6: n7:

n3:abstract

This summary is given to supplement the description on the voting page due to it not giving it full justice. This is not meant to steer voters in any way.--Sefre Image:Sefresig.jpgTalk*Cont. 20:00, 12 May 2007 (CEST) Since this is mostly your policy, would you mind explaining the nomination bit of it? The way I see it, few users are going to be motivated to get another user's build vetted. Some builds don't need to start out as stubs; some authors can draft a complete article on the first attempt. I'm having a little trouble connecting the dots between the nomination process, and the prevention of copycat builds being submitted. Quality control is pretty hard to argue; if we eliminate the bad builds in the nomination process, only good ones will go on to be voted upon, and this makes vetting a little redundant. So why is this part necessary? - Image:Kowal.jpg Krowman (talk • contribs) 20:19, 12 May 2007 (CEST) That was not part of the policy I worked on, I don't remember who submitted it but from what I understand a build has to be "nominated" by 2 people who explain that it isn't a already existing build or that it is not impossible to work. To be honest I never really was in favor of that additional step but there was support for it to weed out builds so I didn't do anything about it. This is not my policy, I drafted the beginning but if you look at history there were many other users who added and refined points in it. So I would question the person who had originally proposed that step.--Sefre Image:Sefresig.jpgTalk*Cont. 20:33, 12 May 2007 (CEST) I would agree with what Armond said earlier as a feasible solution, that most builds can be started out as new/untested, and that stubbing should only be done in a "worst-case" where someone adds a page which is clearly incomplete. To quote Armond-- "I propose to put a build in new builds first and from there, if necessary, put it into stubs or wait for nominations." The way I see that coming across at least, is that a build can be added as new/untested first thing, and if a user comes across and sees that it's clearly incomplete with little info, it can be either stubbed by the user who views it as incomplete OR depending on how much abuse could occur, requested to be stubbed by an admin if abuse is a problem. (some users/vandals may have different definitions of incomplete, including "I just don't like you..") If a build must be stubbed, then it would enter a grace period of ~2 weeks (number just because it seems to go across well) of requirement for improvement, and should move to a category like"Builds requiring reworking/re-evaluation" (name wouldn't be that,) the concept being that we should try to avoid stub-status being a common thing. Users should be promoted to to look here often, though incentives would probably be too far. From there on the 2 nomination votes would be fine. Basically it would just be damage control. That being said I personally find this the best policy so far. Will add more comments shortly, wanna avoid getting too long without any other feedback.. Shas'o Kauyon 20:03, 17 May 2007 (CEST) I would say that sounds like a feasible solution (even though it's kinda my own, just re-created and stuff). -- Armond WarbladeImage:Armond sig image.png{{sysop}} 20:21, 17 May 2007 (CEST) I know Armond, credit goes to you, I was just "fleshing it out" :P. Sorry if I came across as hijacking :(. One idea I had myself (I think..) that made me curious as to anyone's opinion, could it be coded to show a user's percentages of favored votes they've given versus unfavored votes, and if so, would it be ethical? It would make it easy to spot downvoter accounts, but there are also some people that honestly help out and just simply PREFER to focus on either finding good builds and praising them, OR finding bad ones and taking them apart (mutually exclusive). I just wonder if maybe being able to see that " has given 95% of his votes unfavored (with lots of votes)," and the account is a week old, it would help admins to root out downvoting accounts. Shas'o Kauyon 18:01, 18 May 2007 (CEST) Unneccesary. As a rule, people should be casting more unfavored votes than favored ones. The ration of good builds to bad builds is at least 1:5. "Downvoter accounts" weren't really a problem over on GWiki (mayybe some build authors saw them that way), and they will be less of a problem here. With more admins dedicated to just builds, and with the power to strike out inappropriate votes, I don't see this as a problem worthy of the time/effort required to record the percentage of every user's votes. - Image:Kowal.jpg Krowman (talk • contribs) 18:47, 18 May 2007 (CEST) Alrighty. Sorry, just racking my mind of things that might help, will think harder next time :p. I'm a tad over-excited over this whole thing, if it's not obvious. Shas'o Kauyon 18:59, 18 May 2007 (CEST)