PvXwiki:Percentage Favored Vetting

This is a proposed vetting policy to replace PvXwiki:Build vetting procedure. This is a collaboration of many ideas that have floated around the wiki. It is still open for discussion and improvements.

New builds
New builds may be posted on any new page on the Build namespace, so long as they follow the naming policy. They must begin as Build Stubs via the template. Builds remain in Stubs until at least 2 unbiased users nominate the build. Nominators are expected to ensure that the build is of reasonable quality, that there are no extremely similar build already in existence, and that the page itself is of decent quality as well as complete. When determining the quality of the build, nominators should generally give the build the benefit of the doubt, and only builds with blatant problems or that are copies of other builds should be marked for deletion. Build stubs that do not fulfill these prerequisites should be marked for deletion. Nominators should be expected to act as mentors if the build author is unfamiliar with the build submission process. This will also create a team of people responsible for the build article, and should reduce issues of build ownership.

Once a build has acquired the requisite number of nominations, it is then added to Category:New builds via. This template will remain until the build has acquired at least 5 votes spanning a period of at least 2 weeks. After a build has received the necessary number of votes over a sufficient length of time, a new template will be added categorizing the build based on the number of people voting favored.

Discussion and voting

 * The new vetting policy would consist of percent of favored versus unfavored votes rather then simply the number of votes. Once multiple votes have been added the latest voter must then change the percent displayed on both the rate-a-build section and the build article.
 * A vote must consist of detailed reasoning or a mention of agreement with a previous voter. Votes submitted without explanation will be struck out.
 * A vote that is obviously inaccurate will be struck out. Obviously inaccurate is defined as reasoning that is inapplicable to a particular build, reasoning based on facts explained on the build page, or ones that are simply uninformed.
 * Authors and major contributers of a given build are not allowed to vote on their own builds, since they are assumed to be in support of any builds they submit and do not constitute an unbiased vote.
 * Only Administrators have the authority to strike out a vote, and it is the responsibility of other users to bring a seemingly incorrect, or otherwise flawed vote to an Administrators attention. A vote is struck out by adding and tags around the vote, name, and timestamp. An Administrator should strike out a vote only after hearing both sides of the argument. For example, not everyone agrees on what constitutes sound reasoning, and Administrators should not make that distinction without hearing both arguments. If an Administrator's action seems biased another, unbiased Administrator, not previously involved in the conflict may be contacted. However, votes given without any comment at all (simply signed with a name and a date) can be struck out by any user. No other votes may be struck out by normal users.
 * Special administrators (moderators) may be created to help gauge increased flows of input once this wiki has become popular. These moderators would not have the powers of full administrators but would be assigned to police new builds. A build moderator may not act on personal opinions when dealing with conflicts and may be over ruled by a other administrator if they show bias. Build Moderators would be the first to report to with a build issue.
 * The template on build articles would show the percent of voters who found the build to be viable, along with the total number of voters.

Organization
There are five categories that builds will be placed into after receiving the minimum number of votes. This categorization is based on the percentage of favored votes that the build receives. The categories are as follows:


 * Builds with 0%-19% approval ratings
 * Builds with 20%-39% approval ratings
 * Builds with 40%-59% approval ratings
 * Builds with 60%-79% approval ratings
 * Builds with 80%-100% approval ratings

Builds that fall into the lowest category will be deleted after a grace period as per PvXwiki:Build Deletion. The author(s) or other users may archive it in their user space if they wish to save it. These builds may be resubmitted after improvements have been made or extenuating circumstances, such as an update makes a build more viable.

Re-voting
Re-Voting is governed by a separate policy, PvXwiki:Notify Build Testers.

Deletion of builds
Deletion of builds should occur as per PvXwiki:Build Deletion.

Current builds
All non-stub builds in existence when this policy is put into effect will be moved to New Builds.

Script
It has been suggested that a willing person should be found who knows or can learn how to create a extension for media-wiki to incorporate into the build section. Such as a third tab (Build/Discussion/Vote) that would automatically tally up the votes and create the proper percentage.