ATTENTION: Anonymous editing is disabled. Only users with registered Curse accounts can edit. Please either log in or sign up.

Phase 1 of the AWS migration has been completed. If you encounter any issues, please report them through our support portal. Thank you for your patience.

PvXwiki:Build Deletion

From PvXwiki
Jump to: navigation, search
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 is designed to cover the three main reasons for which builds are deleted.

Inferior Builds

One of the major problems with any builds archive is that some builds will not be of the same caliber as the other builds. There is no point, for example, in storing a basic fire nuker build that lacks an elite but is easy to prepare (buying skills, weapons, armor, and runes) when the same site can easily store a much more powerful and focused build. This policy grew out of an attempt to maintain a high standard of excellence for the builds of this wiki.

Reviewing builds

Any build may be submitted to this wiki - that's the nature of any wiki. However, upon review, if a build is shown to be inferior to another build, it may be tagged for immediate deletion due to violation of this policy. If such a build is found, the following code should be added to the top of the page:

{{well|violates [[PvX:WELL]]|~~~~~}}

Alternatively, the following coding could be used:

{{well|inferior to (link to another build)|~~~~~}}

A vote will take place, or an Administrator will review the build in question as well as its talk page to see if it does indeed violate this policy. If it does, the build may be deleted immediately and without discussion.

Builds tagged with deletion with accordance to PvX:WELL can be found here. Builds (and other pages) tagged with deletion with other reasons can be found here.

Clearly inferior builds

A build is clearly inferior to another build if it performs less adequately under all circumstances than a comparable build. This means that the inferior build would always be worse than the other build in ways such as (but not limited to) energy management, survivability, micromanagement, vulnerabilities, and adaptability to unforeseen circumstances. These are only a few things taken into account; this policy will not try to define all the properties that make a build work better than another. The responsibility to make the decision of whether one build is superior or inferior to another will eventually fall upon the shoulders of the admin who decides whether or not to delete it. This admin will, of course, take into account the votes of the testers and look at the builds in question.

It is important to note that the key word in the paragraph above is "comparable." While an Assassin build may deal more damage than a Warrior build, that does not make the Warrior necessarily inferior. Things to take into account are the purpose of the build, the profession, and the area where the build is meant to be used. Other factors may also play a role, and these factors may not always play a role, but this policy will not attempt to define all of the possible extenuating circumstances. Rather, the decision as to whether two builds are comparable will depend primarily on the specific instance.

Similar builds

Similar builds should be merged, if possible, to save space and prevent redundancy on the wiki. If there is a question about whether any two builds should be merged, an administrator should be consulted.

Duplicated builds

Any build that is found to be a duplicate of any other build will be deleted, with its votes merged over to the original build. Any duplicated votes will be deleted. For this reason, one should not vote unfavored on a build simply because it is a duplicate build, but should instead add the following code to the top of its page:

{{Well|dupe of (link to build)|~~~~~}}

Guideline: Don't Delete Immediately

Builds Work Well was originally designed to allow Administrators to quickly remove non-functioning or inferior builds. However, while it is vital to retain this ability, it is also important that builds not be deleted too hastily. As such, this guideline seeks to merely delay deletion until the author is

  • Given a chance to complete his/her build (this usually means that builds should not be deleted as inferior while they are still stubs)
  • Given a chance to understand the reason behind deletion beyond merely the statement of "PvX:WELL."

This benefits both the community as well as the author in a variety of ways. First, it prevents builds from being deleted out of hand, and also helps to prevent theoretically valuable content from being deleted. Second, by doing this, we help improve the author's knowledge by giving him/her a chance to understand the flaws in his build rather than merely deleting it.

If the author of the build (or any other interested user) wants to save a copy of a build facing deletion to their userspace, they may. If the build is deleted before they get the chance, they may ask an admin to restore it to their userspace.

Unfavored Builds

Unfavored builds have little use to PvXwiki. That said, they are often used for inspiration for new and improved builds. In order to maintain a balance between the number of pages on the wiki and the quality of the pages, a two week grace period will be observed between the time a build is unfavored and the time it is deleted. During this time, editors may choose to take notes on the good qualities of the build, archive the build in their userspace, or call for its deletion.

Any meaningful edits during this time frame will reset the grace period. A "meaningful edit" is defined, for this purpose, as an edit that causes or leads to a cause for a re-vote on the build.

Abandoned Builds

A build in either the Build stubs or Trial Builds categories for 2 weeks without any edits will be tagged with the Abandoned Template. If a user makes a meaningful edit to a build tagged as abandoned, they should remove the tag. If the build is not edited within 2 weeks of being tagged (as monitored by Grace Expired), it will be deleted. This process gives the author of a build 4 weeks to avert deletion. Keep in mind that moving to trial from stub and testing from trial count as meaningful edits. Abandoned tags should not be placed on builds in testing.