PvXwiki
Register
Advertisement
Blue check

This page is an official policy on PvXwiki.

It has wide acceptance among editors and is considered a standard that all users should follow.

Sometimes build pages are very similar, to the point that there is no point in maintaining two separate pages for the content, and thus should be merged. The opposite can also happen, where a single build page contains multiple concepts that would be better displayed separately. This policy outlines when merges and splits should occur, and how to go about them in an organized fashion.

Criteria for merging[]

The following critera have to apply with adequate significance:

  • The builds' mainbars are mostly the same, or one includes the other(s) entirely.
  • The builds are meant or can be used for the same purpose.
    • In some cases builds are optimized for a specific area, in which case it may be better to keep them separate from a general variant of the build. If most builds or the equipment are different or the specialized build features a thorough usage section for its special purpose the pages should be kept split.
  • The builds would be or are rated similarly for their gametypes (if different).
  • Neither build violates PvX:WELL or received a rating of Trash. In this case the offending build(s) should be deleted as per those processes, rather than merging their content onto a vetted build.
    • As a general rule of thumb, if a build isn't good enough to be vetted on its own it should not be merged onto a build that is. Merges are done solely to reduce the maintenance burden of content; they do not change the value of that content.

Process for merging[]

  • Propose merge by placing {{merge}} on one (for asymmetrical merge) or both (for symmetrical merge) builds. The tag(s) should not be removed unless discussion leads to that result, or the tags are clearly an attempt at vandalism (however, PvX:AGF applies).
  • If merge will require formatting changes to the final page, create a proposed merge draft.
    • The merge draft should be created as a subpage of the target build (the build whose ratings will be inherited) with {{Merge-Draft}} placed at the top.
    • Userspace pages should not be used for a merge draft presented to the community. Initial drafting can occur in userspace, but must be moved to buildspace before opening discussion, as other users will need to be able to edit the draft without worrying about ownership.
    • Sometimes merges will be simple enough that a draft is not necessary. In those cases simply propose the changes on one of the build talks.
  • Community discusses merge and makes edits to the draft as necessary.
    • To keep discussion all in one place, keep all discussion regarding the merge on the merge draft's talk page. If doing a simple asymmetrical merge (no separate merge draft was made) then discussion can occur on the talk page of the build that will be merged.
    • If a merge is uncontested* for 2 weeks, the merge may proceed automatically. It can proceed earlier if uncontested and supported.
  • Carry out result of discussion
    • Modify the page that will remain. An admin can merge the histories of a draft and the target build if needed.
    • Delete/Archive any extra pages.
      • Vetted build pages that are made obsolete by the merge should be archived with the reason, "Merged to <Final page>".
      • Pages that were in Testing/Trial that are made obsolete by the merge should be deleted. Their talk pages should be archived as subpages of the final build's talk page (make sure they are linked from the final build's talk for visibility).
      • Any draft page does not end up being the final page should be deleted. It's talk page (if any) should be archived similarly to Testing/Trial pages that are deleted.

Criteria for splitting[]

At least one of the following must be true:

  • Page is difficult to vet accurately.
    • Too many mainbar slots left optional
    • Too many gametypes assigned
    • Role(s) not well-defined
  • Page is confusing to navigate (may be resolvable without a split)
    • Unclear which skills are variants to mainbar skills and which are optionals
    • In team builds, unclear which bars are mandatory and which are variants; team could easily be assembled incorrectly even following instructions on page
  • Page contains unrelated skill bars
    • Such as an anti-melee farming bar on a caster-farming build's page
  • Page contains untested/previously trashed builds
    • Most relevant to vetted builds that have variants added later
    • Can be viewed as attempt to bypass the vetting system

Process for splitting[]

  • Propose split by placing {{split}} on the build. The tag should not be removed unless discussion leads to that result, or the tag is clearly an attempt at vandalism (however, PvX:AGF applies).
  • Create proposed split drafts.
    • The split drafts should be created as subpages of the build with {{Split-Draft}} placed at the top.
    • Userspace pages should not be used for a split draft presented to the community. Initial drafting can occur in userspace, but must be moved to buildspace before opening discussion, as other users will need to be able to edit the draft without worrying about ownership.
    • Sometimes splits will be simple enough that a draft is not necessary. In those cases simply propose the changes on the build talk.
  • Community discusses split and makes edits to the drafts as necessary.
    • If a split is uncontested* for 2 weeks, the merge may proceed automatically. It can proceed earlier if uncontested and supported.
  • Carry out result of discussion
    • If split is successful one split draft should be copied over the current build (to inherit its ratings). An admin can merge the histories of the pages if needed. Choose the split that matches the current votes best (any votes that do not fit will be removed).
      • If no split can reasonably inherit the votes of the base build, archive the old build with reason, "Split into <Final pages>".
    • All other successful split drafts should be moved to be base pages in the Build: namespace, and tagged as testing.
    • Unsuccessful split drafts should be deleted. If they had discussion on their talk pages, archive them as subpages of the build they were attempted to split from.

*Uncontested means that no one has raised objections at all. If discussion peters out or reaches a stalemate, that does not count as uncontested. If the discussion stalls, please contact a neutral admin to help resolve the situation.

Advertisement