PvXwiki:Test Before Voting

This is a proposed vetting policy to replace PvXwiki:Build vetting procedure. It is still open for discussion and improvements.

Ideology
Perhaps one of the worst problems that caused the builds section of GuildWiki to fail is lack of testing before voting. In many cases, people will not test builds before voting. Some builds look good on paper but don't work at all in practice, and some are the other way around. Also, many people in GuildWiki simply looked for the negative points in the build, unintentionally ignoring the positive points, and unfavor the build (then go on complaining that people make dumb builds these days ^_^). A possible solution to that is to Test Before Voting. The point is to make sure the build works, not to get it favored.

Build Masters

 * When the build is being tested, the tag should include what areas of the game it is for: GvG, HA, TA/RA, AB/CM, HB, or PvE. Each one of these sections will have a group of "Build Masters." (TA and RA are considered one section, as is AB/CM, and all PvE aspects.)


 * The Build Masters should have the title of their area (e.g., Champ 1 for GvG Build Master, Rank 3 for HA Build Master, Glad 1 for TA/RA Build Master, etc.), as well as a fair amount of experience in the Builds section, and must be appointed by an administrator.
 * The Build Master candidate must, in the Administrators' opinion, have been active in the Builds section, have been fair, and generally a well-received member of PvX wiki, as well as meeting the requirements.
 * This means that just because you have R3, or Glad 1, doesn't mean that you can become a Build Master.


 * The Build Master's main job is to make sure all votes on a build are eligible before slapping "unfavored" or "favored" on it. They may erase or cross out votes that are considered illegible. Due to this reason, crossing of votes by anyone other than an admin or build master is not permitted.


 * Since these requirements are relatively low for experienced PvPers, many people will be able to become Build Masters and build vetting will be relatively quick.


 * Administrators may demote Build Masters if he/she is thought to be unfair.


 * Administrators have the same privileges as Build Masters, of course, but hopefully they are mature enough to not judge builds in an aspect of the game that they are not experienced with.

New Builds
Build posting will generally be the same as before. When builds are created, they are in the Stubs category until the creator has decided it is ready for testing. At that time, the Untested tag will be placed on it. When the Untested tag is on it, people may begin voting on it.

People will begin discussing the build. Anyone may put up a Rate a Build at any time when the build is in "Untested."
 * Builds must be tested by voters before submitting their vote, which should give a sentence describing test results, and if voting unfavored, describe why the build does not work, and how it could be improved.
 * Once one side of the vote exceeds the other by three votes, a "build master approval" tag is slapped on it and a Build Master (see above) checks the build to make sure all votes are eligible before putting it into Favored or Unfavored.

Unfavored Builds
If a build is unfavored, it is moved into that category. Re-voting will be done once someone moves it back to "Untested," but he/she must have made positive changes to it. Voting then proceeds as usual.

Deletion of builds: Most builds will simply end up in Unfavored if it is not good or not well written. Only Build Masters, Admins, or the original author may place a deletion tag on the build, and of course only Admins can delete it. Administrators should, as usual, check that the request for deletion is valid before deleting.

Bad builds
Many people have been wondering how this policy will deal with Starburst warriors and the like. Do we have to test every single one of them? The answer is No. This is how it will work out:

The first Starburst warrior or the like can go into Untested. It will go through testing like any other build, and of course it will become unfavored, with the testing results and logic on the talk page.

A new tag will be created for this purpose: a Duplicate tag. Build Masters may place Duplicate tags, with a link to the duplicated build, on builds that are duplicates or have similar logic as another one. E.g. Minion master builds. If a Minion Master build comes in that is only 1-2 skills different from an existing one, a Duplicate tag may be placed on the build to automatically unfavor it. Of course, only duplicates may be unfavored in this way.

Here is where the trick comes in. Say we get 10 Meteor Shower/Starburst Warrior build submissions to Untested. The Build Master may simply place duplicate tags on all of them, redirecting to the first Starburst Warrior build and its talk page. Newbies who don't understand why a Starburst warrior does not work will learn the logic on the testing results on the first SB warrior's talk page. People who just are plain silly, well, their builds are efficiently and speedily unfavored. A good solution to these problems.

Generally, all we do is have to undergo testing for 1 SB warrior build to unfavor ALL W/E Mage slasher builds. That way, people really can't say that it is unfair... because the logic for the unfavoring is stated on the tested SB warrior build. It also serves as a very fast way to unfavor bad builds.

Invalid builds
e.g., impossible attribute point distribution.

If it is simply a mistake/typo, leave a note on the talk page or fix it up.

If there is something completely ridiculous, e.g. skills from 3 professions, a Build Master may place a delete tag on it.

Build Masters must check the history of the build and make sure that the build they saw was the original version of the build, and not a build that someone has vandalized by putting in dumb skills and such.

Misc
Builds will be organized the same way as the old procedure, with PvP/PvE and their respective sub-categories, and then stubs, unfavored, and archived.

As of the moment, existing builds will not be affected. Re-voting on existing builds under the new system will not be allowed, unless:
 * The metagame has changed, and/or the build's skills have been nerfed/buffed, or
 * The build has been changed/edited enough that people may vote differently.

Builds that no longer work due to meta shift may be moved to Archived. Builds that were Unfavored do not go to Archived, and stubs that have turned invaild due to skill changes will remain in stubs, until it is completed. A Build Master may solely decide whether the latter category of builds will go to Unfavored or Archived.

Conclusion
Build Masters will have a lot of power in their hands with this policy. One may think they will be unfair and such, but hopefully that will not be the case. Administrators will not just promote any rank 3 or glad 1 person. Administrators must feel that they will be able to handle the job, be fair, and be a positive and well-received member of PvX wiki.

Thinking that this will stir up more controversy? There was already enough controversy with bad votes. Almost every build recently in Guild Wiki (before deletion) was unfavored because the voters just found one thing the build sucked at and unfavored it. Since Admins have power over Build Masters, Build Masters should be just as fair as admins, or else they would be demoted. And since we can trust admins to take the position of dictators on GuildWiki, can't we trust the proposed build Masters?