GuildWiki has been locked down: anonymous editing and account creation are disabled. Current registered users are unaffected. Leave any comments on the Community Portal.




This page documents the procedure currently used on the wiki to help those who are new to the builds process.

New builds[]

Everyone is free to create a new builds article. When using the template in GuildWiki:Style and formatting/Builds, most builds will start out in the category untested builds. Those that lack proper formating/wording will be moved into category build stubs. New builds found to have an existing version already in the unfavored builds category are subject to deletion, as new content should be placed in the unfavored version, and then being brought back to stubs or untested.

Discussion and voting[]

After the build arrives in untested builds, people will start noticing and discussing it. At one point someone will put up a Rate-a-Build section on the builds talk page. This is sometimes done right after the build is created, sometimes people wait till the first round of discussion is over. Please keep all discussions civil and avoid personal attacks.

  • To add the Rate-a-Build section, insert the text {{Subst:Rate-a-build}} on the build's talk page.

Everyone, other than the original author of the specified build or contributors that heavily modified the untested build before voting, can vote for builds. Voting after testing the build in game and leaving a detailed comment with the vote is preferred, but not needed to make the vote count. According to a vote on the builds talk page, builds are moved to tested builds if 3 more people voted favored instead of unfavored. If 3 more vote unfavored, the build is moved to unfavored builds. If you see a build which is not in the correct category, please change the build's category.

Two important notes on the votes section:

  • Do NOT strike out other people's votes or delete them for any reason. If you think a vote is objectionable in any way, report it to an admin (see GW:ADMIN for a list of admins).
  • Do NOT discuss other people's votes in the voting section. It makes the votes cluttered and unreadable. Instead, take your issues to the discussion section below or to the respective user's talk page.


Once a build is favored or unfavored, it can not be moved back into untested (exception: re-voting, see below). However it can still be moved to the other category, if enough people vote for the other category, such that this category now has 3 more people compared to the current one.


If the build has been sufficiently altered to render old votes invalid, sometimes a new vote is called. To do so, archive the old vote, put up a fresh Rate-a-Build section and move the build into untested.

Deletion of builds[]

Builds get put up for deletion if someone feels they are too close to an already existing build. Furthermore, builds get sometimes flagged for deletion if someone feels they are extremely bad. The usual wiki procedure of discussion takes place, but note that especially in the first case, deletion might be swift.

Abandoned builds[]

If a build in untested or unfavored has not seen work on it in several weeks, it might be put into Abandoned. Builds there will be deleted after a (longer) period of time if no new work on them is done.

Build categories[]

All build categories with the exception of Build stubs/Abandoned/Untested/Unfavored are reserved for builds which are also in the tested builds category. Builds in one of the beforementioned four categories should not be in any other builds category at the same time.

Archived builds[]

Builds that are no longer viable, but are kept for historical reasons are put into category archived builds.

Featured builds[]

The build portal currently has 2 featured build slots. The first, Current featured build, is reserved for tested builds. The second Featured Untested Build for immediate evaluation is for untested builds. Since there is currently no process comparable to wikipedia's featured articles, every registered user can change the featured builds. To prevent too frequent changes, users are asked only to change the featured tested build every 7 days, and the untested build upon evaluation of the previous one.