FANDOM


(Rewrite to include new nomination procedure suggestion)
m
(One intermediate revision by one user not shown)
Line 2: Line 2:
 
{{unfinished|This is a currently proposed policy, per the guidelines set out in [[GuildWiki:Policy]]. If consensus is reached in the talk page, this notice can be removed and the policy category can be added.}}
 
{{unfinished|This is a currently proposed policy, per the guidelines set out in [[GuildWiki:Policy]]. If consensus is reached in the talk page, this notice can be removed and the policy category can be added.}}
   
[[Builds]] are a major part of the GuildWiki. However, builds differ from other articles, because they can rarely or never be ''objectively'' evaluated; therefore, the GuildWiki uses a vetting procedure which ensures that, even though builds can only be ''subjectively'' evaluated, good builds can be separated from those which do not work as well.
 
   
==New builds==
+
=Build Policy=
Creators of a build should follow the guidelines in [[GuildWiki:Style and formatting/Builds]] to ensure their builds conform our standards of presentation. All new builds should be placed in the category [[:Category:Build stubs|Build stubs]]. If a build is finished anyone ''apart from the original author'' can nominate the build for testing by moving it into the category [[:Category:Untested builds|Untested builds]]. It is the nominators responsibility to check that the build confirms with our standards for build presentation and is not non-sensical.
 
   
==Untested builds==
+
Creating a build and rating it is a complicated process, which consists of three parts: Creation, Nomination and Voting.
''This is the stage where most of the vetting takes place. Testers are encouraged to discuss and vote on builds (see next section for details).''
 
   
When a build is placed in the category [[:Category:Untested builds|untested builds]] a blank voting form should be added to the build's talk page (this can be done by placing <code><nowiki>{{subst:rate-a-build}}</nowiki></code> on the talk page). As soon as a build has 3 more positive votes than negative votes, it can be moved to the category [[:Category:Tested builds|tested builds]]. If it has 3 more negative votes than positive ones, it is moved to the category [[:Category:Unfavored builds|unfavored builds]].
+
==Creation==
  +
#A Build Stub is initially created.
  +
#Build Stub is worked on by author(s).
  +
#The author adds three links to the talk pages of the builds he has voted upon. [[GuildWiki Talk:Builds#Three_to_One|*]]
  +
#Build Stub author leaves a note on talk page indicating he feels it's finished.
   
*''Note that the vote of the original build submitter is not counted here (he/she is thought to be always in favor of the build). It makes counting of votes easier if the original author does not cast a vote.''
+
==Nomination==
*''Unlike other votes on the wiki, votes on builds do not have an ending date. Therefore testing of builds is continuous and builds can be moved from one to the other category if sufficient votes are cast.''
+
#Any non-author(the nominator) visits the build stub, and [[GuildWiki:Written_build_evaluation|evaluates]] the build for it's written quality and content.
  +
#The nominator then sees if the style is correct, which is defined in the article [[GuildWiki:Style_and_formatting/Builds]]. If this is not so, the nominator may not continue before this is amended.
  +
#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.[[GuildWiki Talk:Builds#Three_to_One|*]]
   
==Testing builds==
+
*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.
When testing builds, testers should try their best to look at builds unprejudiced. The usage description of the author and also the types of gameplay (GvG/Farming/etc) for which the build is intended for should be checked carefully. Testers who are not 100% sure of their vote should take the build to Guild Wars and run it before casting the vote. It is helpful to try to improve the build by suggesting changes on the talk page.
 
   
*''Do not take a negative vote for one of your builds as a personal attack on yourself. The vetting process tries to ensure the quality of builds on this wiki.''
+
==Testing==
*''Do not use personal attacks on the author while voting. It is always the build which is evaluated, not the author.''
+
#The Untested Build is commented on and [[GuildWiki:Builds#Voting_Criteria|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.
*''Testers are highly encouraged to leave a note stating the reason for their vote, especially in case of a negative vote.''
+
#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)
   
==Re-evaluating builds==
+
==Deletion Process before Testing is Completed==
Builds that have been placed in the category [[:Category:Tested builds|tested builds]] should not be changed without discussion on the talk page first (although typos, grammar mistakes and formatting can be fixed). Builds in [[:Category:Untested builds|untested builds]] and [[:Category:Unfavored builds|unfavored builds]] can be changed. If a build has been changed substantially, a new vote should be called, by archiving the old vote and putting up a new vote form. If an unfavored build has been substantially changed, it can be placed into untested again.
+
* 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.
   
==Deleting builds==
+
==Voting Criteria==
Builds that sit in the category [[:Category:Build stubs|Build stubs]] for more than 2 weeks without being nominated and without further modification of the build are deemed abandoned and are flagged for deletion. Deletion will take place if a further 2 weeks dont bring a chance of the situation.
 
   
*''To prevent a build from being deleted, either nominate it, or, if you plan to update the build, disagree with the deletion on the talk page''
+
*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.
   
==See Also==
+
Note that before voting:
*[[GuildWiki:Written build evaluation]]
+
* 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.
  +
  +
==Notes==
  +
If this policy is implemented, some more explanation and wikilinks should be added.

Revision as of 19:02, October 2, 2006


Build Policy

Creating a build and rating it is a complicated process, which consists of three parts: Creation, Nomination and Voting.

Creation

  1. A Build Stub is 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 evaluates 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 GuildWiki:Style_and_formatting/Builds. 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.

Notes

If this policy is implemented, some more explanation and wikilinks should be added.

Community content is available under CC-BY-NC-SA unless otherwise noted.