FANDOM


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

general

Instead of the old favored and unfavored, this policy would work with a lot more categories. To do this, we need a detailed list of play styles and the things they should do and a list of common problems (energy management, no long recharges, no better or similar build). For every single job a character can do, we would make a list with necessary stuff. Example:

  • Monk, Protection
    • Condition Removal (all)
    • Hex Removal (all)
    • The ability to make red bars go up in a short time (RA, TA, AB, HB, PvE)
    • The ability to force target switching by using protection skills (all)
    • Spike protection (all but RA)

Thus, if somebody would post a build with the tag {{class:Protection Monk}, people would look if that build can do everything described in the corresponding list.

In other words: every build must be assigned to at least one "play style" (if a build isn't assigned, it will be moved to "build stubs").

Voting

How to vote

  • Find a build
  • Say what's wrong with the build
  • Say if all the problems of the build (if any) are addressed
  • done, that's all

I hope that helps for everybody who might find this policy too complicated...

Character builds

All new, completed builds should go to a page similar to the current "unfavored". These build will get a "Rate a Build" template in the discussion page. This template would contain some place where you can describe your problem with that build and where you can start start a small voting procedure whether that comment is correct - whether that build indeed lacks an aspect mentioned in the list - (these voting procedure shouldn't be much of a problem in most situations).

The Rate a Build template would also have a place where you can discuss if all problems of the build are "tagged". If this is the case according to several people, the build will be declared "tested". However, instead of the correct favored and unfavored build places, there would be other build name places based on the amount of tags: a place with all builds that have are completely fine, a place with all builds that have on mayor problem(, a place with all builds that have 2 mayor problems) and all the rest.

For some problems - like energy management - it is often necessary that people test the build before making comments about it. Because of this, these specific problems will require additional voting to be accepted.

These procedures about problems may always be started, even if several people declared the build as tested. However, these build will never go back to the "unfavored" page.

Team builds

These team builds will be rated like the character builds: we would separate them into spike builds and pressure builds. Similar to the play styles, these 2 types of team builds would get an list of things they should be able to do.

The actual voting would work exactly the same way as with the character builds.

Searching

Since every build is assigned to a specific play style, you would be able to search based on these play styles. Basically, inside the article about each play style, you would find either: (a link to) all builds that share that play style OR several links to lists with all builds that share both their play style and the area they are used in.

In other words: you would be able to search builds based on classes and play styles.

Positive aspects

  • The creator of this build knows exactly what to do to improve this build
  • The list would be quite helpful for new players
  • No discrimination
  • If somebody does decide to use that character build in a team build, he can adapt more easily (for example, if he choses to pick a monk without hex removal, he might want to use an expel hexes mesmer).
  • Correct rating

The list

Some important notes about this list:

  • This list only includes types of builds that are actually used and useful in the current meta.
  • when I talk about "play style" I actually mean: "all kinds of builds that share the same purposes and things they should be able to do".
  • A build can apply to multiple play styles
  • There will be several aspects that will count for every single class
  • Builds that can only work when paired with specific other builds (like blood spikers or glass arrow rangers) don't belong here. They should be posted along with their full team build.

The list is based on classes. Keep in mind that this list is just an idea, it can be improved.

  • Warrior, damage (all)
  • Warrior, tank (pve)
  • Warrior, split (gvg)
  • Ranger (all)
  • Expertise based build: primary rangers that use their secondary for a weapon (all)
  • Monk, Healer (all)
  • Monk, Protection (all)
  • Smiter (all)
  • Necromancer, Minion Master (pve)
  • Necromancer, Degen/hex based (pvp)
  • Necromancer, Battery (all)
  • Mesmer, Domination Shutdown (all)
  • Mesmer, Degen/hex based (pvp)
  • Elementalist (all)
  • Assassin, damage (pvp)
  • Assassin, damage & surviving (pve)
  • Ritualist, Spirits based (all)
  • Ritualist, Channeling (all)
  • Ritualist, Restoration (all)
  • Dervish (all)
  • Paragon (all)

All of these would need a list with things they should be able to do or what they should have.

Other notes

  • Builds might be deleted if they have more than 2 tags. If another build is found to do the same job better, the inferior build will be deleted as per PvX:WELL.
  • Existing builds that are favored will be seen as "perfect" builds, but as mentioned: you can still start a revote if you think there's a problem. Existing builds in unfavored will stay there, unless a revote is done. Existing builds in the testing area will be voted with the new systems.
  • The only things this policy requires to work are:
    • A new template that indicated classes. This tag should be built in such a way that it can be used for searing (similar to the template that indicates which campaign is needed).
    • An updated Rate-a-Build template (like described in somewhere else in this article)
    • A template that can show what the problems are (if any).
Community content is available under CC-BY-NC-SA 2.5 unless otherwise noted.