Blue check.png

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 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 {{Untested-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, there should be a short period of discussion to decide what to do with the build. Based on the outcome of this disscussion one of two things should happen:
  1. If the build is considered to be part of the current Heroes' Ascent/Guild versus Guild meta game, it is moved to the Meta category by changing the tag to {{Meta-Build|Type 1|Type 2|...}}. Meta builds do not get vetted
  2. Every other build is moved to the Testing category by changing the tag to {{Untested-Testing|Type 1|Type 2|...}}, and vetting can begin.


To rate a build, click the 'Rate' tab at the top of it's page. You can then give a rating on a scale of 0 (hopeless) to 5 (excellent) for each of the following 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 score high in innovation.

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. Likewise, a rating of e.g. Zero in Effectiveness and 5 in Universality is considered contradictory.
  • 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 admissible 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 is no longer counting towards the overall score, but 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.

  • Working-Great (4.75 – 5.0):
The build works great. Great idea, a lot of potential, easy to use and it will really make a worthy contribution to our database.
  • Working-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.

Meta Builds

If a build is being seen in the current meta (specifically HA/GvG) 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 only 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.

  • Meta builds only need the meta tag: {{Meta-Build|type1|type2|...}}
  • 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.
  • If someone tags a build that isn't a HA or GvG build with the meta tag and it has less than 5 votes or did not get above a "Trash" rating, you should replace the meta template with the "Untested" or "Trash" template (as appropriate). 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 does get 5 or more votes anyway, the parameter |rating=x| (where x is either Good or Great) can be added to also add the build to that vetting category. It will simultaneously occupy both the Meta and Good/Great category.

Meta builds should include an additional section on their respective article page called "Frequency" (and not called anything else, as this section will be linked to). This should give an indication of how commonly run the build is, and link to any alternative builds, as well as reason why it is run more/less than that build. An example of how this section might look is:

*This build is seen about X% as much as an [[Build:Y/Z Build name|Y/Z Build name]], this is because this build:
**Has less healing
**Slower and fewer Increased run speed skills
**Less effective against other builds in the meta.

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 be tagged with:

  • {{Archived-Build|category=Meta|type1=...|type2=...|reason1=...|reason2=...}}

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.