This page is an official policy on PvXwiki.
It has wide acceptance among editors and is considered a standard that all users should follow.
Wikis are based on the theory that the product of the collaboration of a group of individuals will produce a better article than that of a single individual. This is a tried-and-true method, but one which may at first seem poorly suited to a dynamic rating system such as Real Vetting. Given the ability of users other than the the author to manipulate a build, thus effecting its ranking, it is important to distinguish when a build should be edited, by whom it can be edited, and what should be edited, in order to allow for the dynamic nature both of a Wiki and of the rating system.
Creating New Builds
Naming Your Build
In order to keep PvXwiki organized, builds shall be named in a consistent and organized fashion.
All builds will be in the build namespace - thus, the beginning of the page name must be "Build:". Afterward, the abbreviations of the primary and secondary professions will be listed, with a slash ( / ) between them, similar to how they are seen in game. (If no secondary profession is required, the word "any", in lower case, will be substituted. If you can have any primary profession use "Any" (capital "A")) Note that "Mes", a common shorthand for "Mesmer", is not acceptable (as the in-game abbreviation is simply Me), nor is simply M (which could mean Mesmer or Monk but is the abbreviation for neither).
Finally, the name of the build (in title case, unless doing so would conflict with the name of something in Guild Wars) will complete the page name. This name may not be offensive or overly verbose (such as [[Build:A/N Blossomality of Shadowing Shroudulation]]) or nonsensical (such as [[Build:A/W Shadow Spider Tiger Steel Sin]]) and will (briefly) describe the build and/or its purpose.
For ease of searching, the only symbols allowed in the name of the build are the slash ( / ), hyphen ( - ) and parentheses ( ( ) ). That said, try not to be excessive with symbols; for example, one pair of parentheses is generally more than enough.
Examples of correct build names include Build:A/W Palm Strike Spiker, Build:W/any Crippling Slash Warrior, and Build:W/E Primal Rage Axe. Unacceptable versions of these names would include Build:A/W palm strike, Build Me/Rt Power Block Mesmer, Build:ME/RT Power Leecher, and W/E Primal Rage Axe.
For team builds, the primary and secondary professions shall be substituted with "Team - ". A prime example of the correct way to do this is Build:Team - GvG Balanced. Please note the spacing around the hyphen when making a team build.
Builds Based on Leaked Skill Update info
Occasionally, skill updates get leaked out to the community, this is not intended. If you happen to obtain information about a skill update, please do not post builds using this into the Build namespace, you can however create a page in your userspace, which can be moved to the Build space once the update has occurred. Any builds based on leaked skill updates will be moved into the Authors userspace.
Builds for Both PvE and PvP
Due to the fundamental differences between PvE and PvP gameplay, you should not tag a build for both PvE and PvP use. Instead create separate articles for PvE and PvP, allowing specialized skill bars and descriptions of the build and its usage.
Builds in the Stub Category may be compared in many respects to builds in the User Space. These builds are often lacking in both content and style. The purpose of the Stubs Category, however, is not to debate content but rather to make the article presentable. As such, while content may be debated on the Talk Pages of stubs, the primary concern, as far as editing done by users other than the author, is stylistic since the function of the Stubs Category is to prepare the build for the Trial and Testing stages.
Stubbing a Build
A build may originate in Stubs if placed there by the author or may simply be deemed too "stubby", and moved from either Trial or Testing into the Stub Category. While this may seem overly subjective, the difference between a complete build and a stub is apparent to most editors.
- Fixing Red Links
- Fixing Wiki-Code/PvXCode
- Fixing Grammatical Errors (including spelling)
On GuildWiki, it was common for Build Stubs to receive little to no feedback prior to the Untested stage. This proved to be an issue at times since builds, once in Untested, could immediately be voted upon, meaning that authors commonly had their builds moved to Unfavored with little to no feedback beyond the votes themselves. The Trial Category is an attempt to address that problem. Like the Stubs Category, builds in the Trial Category are not yet ready to be voted upon. However, unlike Stubs, the decision of whether to place a build in the Trial category largely subjective and is, for the most part, left to the Author. It is in this section that the author has a chance to present his finished build to the community, prior to testing, in order to receive feedback in preparation for testing. Thus, both discussion and editing should focus primarily on content.
Moving a Build into the Trial Section
Like with Stubs, builds may originate in the Trial Section or be moved there after the Stub Phase. However, it is not vital that a build be in the Trial Phase for any length of time. As such, the Author may decide to move a build into the Trial Phase if he/she wishes for feedback or may decide to bypass the Trial Phase entirely and move straight to the Testing Phase.
- Changing Skills, Attributes, Runes, etc.
- Adding or removing content
- Adding PvX:WELL deletion tags (when called for)
Voting Occurring in the Stub and Trial Phases
While the Rate tag at the top of the page appears on any page in the "Build:" namespace, builds that have not yet reached the Testing section should not be voted upon. As such, all votes placed on builds that are either in the Stub or Trial section will be summarily deleted.
The Testing Stage, similar to GuildWiki's Untested Stage, is the time when a build is tested and voted upon. By this time, major edits to content and style should already have occurred, and much of the discussion should already have taken place. As such, most of the editing should also have already taken place since the votes will usually reiterate concepts or thoughts brought up in the Trial Stage. Most of the edits should be relatively minor changes to content, done primarily by the Author himself/herself, in response to any new discussion that takes place or in response to new concepts brought up in the course of voting.
Moving a Build into the Testing Phase
A build may originate in the Testing Section or be placed there after the Stub and/or Trial Phase. The decision of whether or not a build is ready for voting is left entirely to the Author (although, as previously mentioned in the Stubs Section, any user may determine that a build is too stubby for Testing).
Build Article Quality
If a build that is placed in the Testing phase is clearly lacking in quality be it through many spelling errors, bad grammar or lack of information, it can be moved back to Stub / Trial status depending on the quality of the write up (as mentioned above). Always ensure that when placing a build in the Testing phase that it is set out clearly and has as much information on it as possible (skill variants, options for optional slots, full usage/equipment sections etc).
Works (Good, Great)
If a build is deemed good enough to be placed in any of the two "Working" Categories, editing is likely to slow considerably or stop altogether. While discussion and voting may continue, major edits to the build should only result if an update to the game or metagame has an impact on the build. In these cases, it may become important to respond to the update by making a major edit or re-voting on the build altogether. However, barring an update, the build should remain fairly static – no major changes should be made to the version that was vetted.
Borderline builds, those found in Working/Good, are not quite good enough to be deemed "Great" but good enough to not be thrown out altogether. These may be an exception to this rule. Builds in this category are more likely to continue receiving votes, and thus content may need to be updated on a more frequent basis. However, like with the Trial Stage, most of this editing should be being done by the author or as a result of consensus on the build's talk page.
Moving a Build into the Working Section
After a build has received 5 votes, it should be manually moved into either one of the Working Sections or the Trash Section.
- Working (Great): Builds receiving an average score of 4.75-5.0 (95%-100%)
- Working (Good): Builds receiving an average score of 3.5-4.75 (70%-95%)
- Trash: Builds receiving an average score lower than 3.5 (70%)
It is the responsibility of the 5th voter to add the appropriate template. If additional voting affects the placement of the build, it is then the responsibility of each successive voter to move the build if necessary.
If, after receiving a minimum of 5 votes, a build is deemed not good enough to be workable, it is moved into the Trash Category. Similar to Working Builds, voting, discussion, and editing are likely to halt. However, since these builds in their current form are deemed unworkable, they will be deleted after a grace period (as per PvX:DELETE) if they remain static. As such, edits to builds in the Trash Category, if they do occur, are likely to be major re-vamps. In these cases, builds should be moved back to the Testing Section.
Moving a Build into the Trash Section
See "Moving a Build into the Working Section" above.
Sometimes, shifts in the metagame or updates effect the viability of Working Builds. If discussion or a re-vote establishes that a Working build is no longer viable, it should be moved into the Archive namespace, and tagged as an archived build. This section is maintained solely for historical purposes. Once in this section, builds should no longer be edited.
Archives can only take place under these circumstances:
- Nerfs to skills on the bar
- Buffs to skills on other bars that have made the build inferior
- Metagame shifts
- Remakes of the build (better versions)
Use these templates if you feel an archive should occur, while discussion is on going.
Archive vs. Delete
When an update or skill nerf happens, it will affect many builds. However, some builds should archived, while others should be trashed.
- Builds in the "Good" category should first be judged whether they have been worthy enough for archival.
- Builds in the "Great" category should be automatically archived.
Builds that are archived should stay in archives unless it is changed by skill updates or has been re-invented to fit a new purpose. If you feel a build is to be taken out of archival, then discuss it on the build's Talk page. Builds should not be taken out of archival unless a general agreement has been made by the community. Builds in archives should also not be edited unless to be taken out of archives.
If an update makes an archived build viable again, it can be suggested to be brought out of the archive. Discussion should take place on the talk page, until a decision is reached on what to do. If the build is brought out of the archive, do the following:
- Move the build back to the "Build" namespace.
- Replace the archive tag with an untested tag.
- Make any minor alterations needed.
- Request a vote wipe on the PvXwiki:Admin noticeboard, saying it's been brought out of the archive.
The User Space is a special exception. While builds in the User Space are often incomplete both in terms of style as well as content, the User Space is in many ways sacrosanct and editing a page in another user's User Space without their express permission or a valid, overriding reason should not occur.
The following is a list of all build categorization templates and the categories to which they correspond:
- Template:Build-stub - Stub
- Template:Untested-Trial - Trial
- Template:Untested-Testing - Testing
- Template:Trash-Build - Trash
- Template:Good-Build - Working (Good)
- Template:Great-Build - Working (Great)
- Template:Archived-Build - Archive
While this can be cited as policy when necessary, this policy was developed with the understanding that it could never constitute a strict, specific guideline. Grammatical errors will persist after the Stub Phase, variants might need to be added after the Testing Phase, etc.