User:Ifer/buildpolicy

=Build Policy=

Creation

 * 1) Build Stub initially created.
 * 2) Build Stub is worked on by author(s).
 * 3) The author adds three links to the talk pages of the builds he has voted upon. *
 * 4) Build Stub author leaves a note on talk page indicating he feels it's finished.

Nomination

 * 1) Any non-author(the nominator) visits the build stub, and the build for it's written quality and content.
 * 2) The nominator then sees if the style is correct, which is defined in the article . If this is not so, the nominator may not continue before this is amended.
 * 3) The nominator checks the votes, to see if they were made seriously, and not rushed for the sake of getting the build through the nomination process.*


 * Note that if a nominator decides not to continue and leaves a notice on the talk page, another nominator can override this and nominate the build stub anyway.

Testing

 * 1) The Untested Build is commented on and voted on. During this process the autor may refine the notes; if he decides to change the build however, he or any other contributor is allowed to call for a re-vote. In such a case, the current vote should be archived, and the voting can start fresh.
 * 2) After a minimum of four votes, the build is moved to Favored/Neutral/Unfavored. A build that has an excess of three positive votes will be favored, and a build with an excess of three negative votes will be unfavored. This will be unbalanced when the number of votes increases too much, so for every ten votes an additional excess vote will be required (though this will rarely happen)

Deletion Process before Testing is Completed

 * Any Build Stub or Untested Build will be flagged for deletion two weeks after the last modified Article or Article Talk date. At this point, it is assumed abandoned. If this is not so, a contributor may remove the tag and continue editing the page. (If no addition is made, not even an explanation of the removal, someone may revert that action.)
 * Any Build Stub/Untested Build will be deleted two weeks after the Delete tag is added.

Voting Criteria

 * The Build functions as written.
 * The Build has significant differences with other Builds.
 * The Build functions comparably to other Builds with a similar purpose and using the same Primary Profession that require a similar level of expertise to use.

Note that before voting:
 * a voter must have read all the comments.
 * he must have tried the build in-game if he is casting a positive vote, and preferably if he is castin a negative vote as well.
 * he may not personally attack the author or other voters.
 * he should take into account the criteria that define a build as good or bad, and preferably refer to the one(s) he thinks are not met.

Ifer (t/c) 13:28, 2 October 2006 (CDT)

=Discussion=

Three To One
The three to one process is not very accepted, but I feel it works well within this policy. Discuss it's usage in this policy here. If we decide not to use this, a note should be added to relevant pages that requests build authors to vote on other builds as well, with three to one as a basic guideline.

personally, I think this is great and I believe it can be used effectively here. -- Ifer (t/c) 13:28, 2 October 2006 (CDT)

Catergory Names
I have currently named the catergories I use Stubs, Untested, Favored, Neutral and Unfavored. The fourth has met some resistance, and I have an alternative: Favored, Neutral and Unfavored can be changed to Favored, Unfavored and Unfavored (Delete notice for irrelivance to the Wiki). In this case, a week should be enough time to correct the build or to sway the vote - if not, the page is deleted.

Discuss.

I personally don't care, I think either will work. -- Ifer (t/c) 13:40, 2 October 2006 (CDT)