Blue check

This page is an official policy on PvXwiki.

It has wide acceptance among editors and is considered a standard that all users should follow.



This policy describes the rating procedure used on PvXwiki to judge the quality of a build. In short, each user can give his opinion on a build by rating it along several criteria and writing a short review. From these votes, an overall rating is calculated which determines in which category of quality the build will be stored on PvXwiki, and if it is worth adding to our database at all.

The only cases where voting doesn't occur on a build is if it is considered to be part of the current Heroes' Ascent, Guild versus Guild or Speed clear meta game.

Further extensions and fine-tuning might be added following community discussion.

New builds[]

  • All new build articles submitted to PvXwiki should be stored in the Build Stubs category. This is accomplished by placing the {{build-stub}} tag at the top of the build page.
  • As soon as an article is finished, it can be moved to the Trial category by changing the tag to:
{{Real-Vetting|rating=Trial|Type 1|Type 2|...}}.
At this point community discussion on the build should start, improvements and additions can be made and the types of gameplay the build is adapted for are laid down.
  • Finally, after the final adjustments have been made, move the build to the Testing category by changing 'rating=Trial' to 'rating=Testing'.


To rate a build, you must be logged into an account and click the 'Rate' link in the build categorization tag at the top of it's page. You can then give a rating on a scale of 0 (hopeless) to 5 (excellent) for Effectiveness and Universality. You can also provide a checkmark if the build meets the Innovation criteria.

This criterion describes how effectively the build does what it was designed for. That is, how much damage does a spiker build deal, a healer build heal or a protector build prevent? How good is the chance to get through the specified area with a running build or to reach and defeat the specified foes with a farming build?
Note that this criterion is not efficiency. It describes only the performance of the build, and does not compare this to the player's effort required to use it or to acquire the needed skills and items.
This criterion describes how flexible the build is when used in a situation slightly different from what the build was designed for. This includes the ability to change strategy in case a foe shows unexpected actions, in case an ally does not perform as expected, or when used in a different location than originally intended.
This criterion describes how useful the idea behind this build is. Does it use an unexpected (and thus less likely to be countered) approach for dealing with a known task or even act as a precursor for dealing with a previously unconsidered task? To what extent is it expected to become a prototype for a new class of builds? Should the build do any of these well, it should be marked as innovative.

Users are strongly discouraged from vetting builds based solely on the idea that teammates will perform optimally and/or opponents will perform sub-optimally. Users are also discouraged from voting on builds which utilize game mechanics and/or exploit playstyles with which the user may not be intimately familiar with.

Vote Removal[]

In addition, a reason for the vote must be given in the 'Comments' box. Please observe the following guidelines concerning votes and their reasons.

  • A vote must constitute an objective judgment of the build's qualities. It must not be biased by sympathy or any other prejudice regarding the author. This applies in particular to votes given by authors themselves or their friends. Votes that deliberately overshoot in favoring or unfavoring a build in order to 'compensate' another vote are not acceptable either.
  • A vote may not be submitted by a sock puppet. Users who didn't edit a single page on the wiki yet are in general suspected to be sock puppets and their votes are subject to removal.
  • A vote, including the comment, must be self-consistent. That is, the ratings and the comment may not contradict each other. The comment should explain all ratings instead.
  • A vote may not constitute vandalism or violate NPA. It may not be overly rude, attack the author or in another way disrupt the wiki.
  • A vote must be based on facts. Votes that are entirely based on a false premise, flagrantly misrepresent a build's ability or demonstrate a minimal understanding of in-game mechanics are considered invalid.
  • A build that works but is clearly inferior to another build should get a lower rating than this other build. However, the rating should still be higher than for a build that doesn't work at all. Only builds that serve the same purpose may be compared in that way.
  • The weighting of the ratings on the different criteria is defined by this policy. Voters who don't agree with the current weighting should address that on the policy's talk page. It is not acceptable to give false ratings on individual criteria in order to circumvent the weighting scheme.

If a user feels that an unwarranted rating has been given to a build, he or she may contact the voter in question and ask them to explain or elaborate their rating on the build's discussion page. Note that all discussion about votes and their reasons takes place on the build's discussion page, not on the voter's talk page. However, a short message on the voter's talk page in order to draw his attention on the discussion is acceptable. Please respect NPA at all times.

A vote that seriously violates the above rules may be brought to admin attention and, if that is deemed appropriate, will be stricken. The administrator striking the vote will give a reason explaining in which way the vote was violating this policy. In general he will also inform the voter about the removal of the vote. Excepting cases of sockpuppetry and/or vandalism, administrators are expected not to remove votes from builds they have created, and should allow another less biased administrator to make a determination on whether or not a vote should be removed.

Each user has the opportunity to change his/her vote any time as the work on the build progresses. This includes the submission of a new vote after a vote was stricken. Note however that the re-submission of the same vote without any further explanation is violating 1RV.

Apply Common Sense When Voting[]

When rating, apply common sense and be reasonable. Don't rate builds based on trivial or easily amenable premises. For instance, If a PvP build listed as using a Superior Rune, but it could still function using Minor Runes, don't use "Rune suicide" as the sole basis of giving the build a low score. Instead, remove the Superior Rune and make a note of your having done so on the talk page (it is recommended that you do so, though it is not strictly necessary). This extends to votes based on the use of a minor skill (e.g. don't give a build a poor rating because you'd prefer a different primer hex which could be easily added).

Votes violating this common sense rule (or common sense in general) may result in a ban of length determined by the administrative team for stupidity and blatant disregard for policy.


On the rate page of a build, a list of all existing votes on this build is displayed, including the voter's user name, ratings, and the reason given.

For determining the overall rating of a build, the ratings of all criteria are combined with the following weighting:

  • Effectiveness: 80%
  • Universality: 20%
  • Innovation: 0%

Note that the innovation rating no longer counts towards the overall score, but exists merely for the reader's information.

To determine the total score of the build, the ratings given by all voters are averaged. As soon as at least 5 people have voted on a build, the build is assigned a category.


Depending on the total rating by all voters, builds are sorted in the following categories after a minimum of 5 votes.

  • Great (4.75 – 5.0):
The build works great. Great idea, a lot of potential and it will really make a worthy contribution to our database.
  • Good (3.75 – <4.75):
The build works well. The idea has potential, it has a meaning, shows some strength and is worth being added to our build database.
  • Trash (0 – <3.75):
The build has not shown any particularly good ideas, has no potential, is a copy of another build or just a garbage post. It will be deleted after a grace period of 2 weeks.

Change the rating in the Real-Vetting tag to the above option that matches the overall rating the build received.

Provisional Vetting[]

Some builds do not get much attention in the Testing phase, even though they are deemed to work well by some users (who have voted accordingly). If a build has been in testing for 2 weeks, has 2-4 votes and would not be in the Trash category at its current rating, it is eligible for a Provisional rating:

  • The thresholds are the same as for fully vetted builds.
  • A discussion may be warranted before applying a provisional rating to the build.

Change the rating to Good or Great as appropriate, and add the provisional status like so: {{Real-Vetting|status=provisional|rating=X|Type1|etc.}}

Builds with a provisional rating will keep it until they reach 5 votes, at which point the provisional status should be removed. As with fully vetted builds, any rating that would change the rating category should be reflected in the tag (change the rating parameter to Great/Good as needed). If a provisional or 2-week old testing build's rating falls into the range of Trash builds, change the rating to Trash and remove the provisional status (if present).

Provisional status should not be placed on builds with Meta status (see next section for details on Meta builds).

Meta Builds[]

If a build is being seen in the current meta for GvG, HA or SC then it can bypass the vetting system, and be tagged "Meta". This shows that the build in question is being used currently as it is one of the more effective builds in the current meta.

Builds that are not HA/GvG/SC can only be tagged as "Meta" if it passes vetting with a rating of "Good" or "Great", and are clearly commonly run. Such a build should be easily verified by going to the appropriate location and observing what builds are run.

Add the meta status like so: {{Real-Vetting|status=meta|rating=X|Type1|etc.}}

  • If someone tags a build to be in the meta game which you feel currently isn't, feel free to bring a point up on the Build's discussion page to discuss whether the tag should remain or be removed. Remember to not break 1RV.
  • Testing, Good and Great are the only valid ratings for builds tagged as meta. Any build that isn't of a gametype that allows it to skip vetting is further restricted to just Good and Great.
    • Meta status should be removed from builds with any disallowed ratings.
    • Avoid breaking 1RV; if you get into a revert war, bring it up on the Admin noticeboard and an available admin will intervene.
  • If a meta build that skipped vetting does get 5 or more votes anyway, update the rating appropriately. It will simultaneously occupy both the Meta and Good/Great categories. While it has less than 5 votes, it will simultaneously occupy the Testing and Meta categories.

Policing Meta Builds[]

Due to the nature of the meta builds category, some people might use this as a means to bypass the vetting system, as such there will be community appointed "Caretakers" of the category. These people will get final say on whether something is meta, or should be put through the vetting system.

Meta shifts[]

Due to the nature of Guild Wars, skills will get changed. This may have an impact on how well something works, and as such shift the meta. If a build that was considered meta suddenly falls out of favour, it should have its rating changed to "Archived" or "Testing", depending on whether it could remain as a fringe build.

Additional Information[]

For additional information regarding both the process of creating/vetting a build under the Real Vetting system, as well as additional policy aspects, see PvXwiki:Editing Builds.

Note that exceptionally bad builds might be subject to more speedy deletion according to the Build Deletion policy.