GuildWiki talk:Build vetting procedure

This page
I tried to write down accurately the way things are currently handled on the wiki. Note that this describes how things are done but ultimatively, we want this page also to describe how things should be done. But since exactly how they should be done is a currently ongoing debate, please refrain from major edits to this page, going in the direction of "it should be done like this" until we have agreed on a new procedure. Of course all edits regarding language, style, things I forgot about builds and such are ok. --Xeeron 06:49, 9 October 2006 (CDT)

Vetted builds
I'm not entirely sure what kind of system we should use for builds at this point, but I think one thing we could do to improve matters (both now and in the future when we have our shiny new system) is protect all vetted/approved/tested/whatever builds from edits by unregistered users. I've seen several builds that are approved (and therefore shouldn't be changed) end up being pretty drastically altered or vandalised, and generally speaking if these changes are for the worst they're by an unregistered user. Once a build is approved it shouldn't need much alteration, a low level of protection should make things a bit easier to keep track of. --NieA7 10:06, 9 October 2006 (CDT)
 * I'm against it, its unwiki like. Most grammar/spellcheck comes from anons and it's easy to revert &mdash; Skuld 10:13, 9 October 2006 (CDT)
 * I agree with Skuld. If vetting a build grants it immunity from criticism, I don't think that is very good at all. Just look at the 55/SS team. It was vetted under nearly a COMPLETELY different set of attributes and skills, but maintained the same idea. The point of it is that any build no matter how good it is always has room for improvement/constructive alteration. — Jyro X [[Image:Spiteful_Spirit.jpg|25px]] (contribs) 10:16, 9 October 2006 (CDT)
 * I'm thinking in terms of practicalities rather than politics. The B/P Tombs build is an example - from being approved it changed so much that User:Honorable Sarah had to re-write the whole thing more or less from scratch. I'd rather present consistently accurate information than consistently editable information. If a build is to be approved it should have all its spelling and grammar checked anyway, and nobody would be stopping somebody signing up for an account/mentioning the problem on the talk page. I'm not saying that it should be immune from all criticism, far from it - I don't want global protection, just protection from unregistered users. --NieA7 10:23, 9 October 2006 (CDT)
 * Everything you say does make sense and I would approve of this if it was on a typical fan site but I still think it's unwiki-like and anyone that wants to change a build so bad can still register and demolish things just as easily (or improve it). Good thing is that we can always revert it if it goes awry or clean it up if it gets too messy.[[Image:VallenIconwhitesmall.JPG]]  Vallen Frostweaver  07:37, 18 October 2006 (CDT)
 * Looks like I'm onto a loser with this one, but fair enough if you all don't like it. --NieA7 17:43, 18 October 2006 (CDT)

Archive?
On the article page it states the below:


 * Re-voting


 * 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 and put up a fresh Rate-a-Build section.

I understand this but don't know how to archive anything. No links were attached to help describe this process either so I'm looking for some direction here on how to accomplish this should the need arise. Thanks.  Vallen Frostweaver  07:40, 18 October 2006 (CDT)
 * You can either do it manually, or half-automated. If you do it manually, simply create a new page called "XYZ/archive 1" (where xyz is the name of the talk page), copy the old content there, and leave a link to the archive page on top of the talk page. For the half-automated way, you have to create the archive page in the same way and then you use Template:Archive box to insert the nice little box. Check my user talk page for an example. --Xeeron 06:25, 19 October 2006 (CDT)
 * Thanks. This helps and I think others can check this discussion page for details now.[[Image:VallenIconwhitesmall.JPG]]  Vallen Frostweaver  07:04, 19 October 2006 (CDT)

Using a variation
How is it possible that voting without testing the build counts but voting on the build with a different skill or two does NOT count?? Sorry Rapta, I reverted because I felt you winged that one. If I am incorrect, please point me to the relevant policy page. I would think the variation itself is key here. i.e. if it's just removing one skill instead of another, then that's fine. But if it's changing elites or attribute points or 5 skills, then yeah I would say that's a bad vote. --Karlos 08:06, 21 October 2006 (CDT)


 * How many skills does it take to be a "build?" Variants that differ by one skill may either be incredibly similar or remarkable different, depending on the skills being exchanged. In my opinion, a build should be minimalistic, focusing only on the core skills used; far too many build have slots filled just to put an icon in all eight slots, when only maybe five or six slots actually define what that build "does." And it varies greatly; the "build" I use for farming with my ritualist uses only four skills; the rest are just window-dressing. Yet the build I use for soloing/henching with my ranger uses all eight skills. Swapping one of the "optional" skills on my ritualist does not effectively change the build; changing one of the skills on my ranger drastically changes how she "works."


 * I hate pointing out a problem without a solution, but I"m not certain we can determine the validity of a vote based on its consideration of altered skills. I'll do a bit more thinking. &mdash; ChaoticCoyote 08:28, 21 October 2006 (CDT)


 * I agree, hence the reversion. Like I said, the exact variation that was done is actually key. --Karlos 13:26, 21 October 2006 (CDT)


 * Yes, but all that requires more consensus and even a more vigorous vetting procedure. It's simply enough to put down the rule here, and that votes are strictly based on the build mentioned. Any variants should be added on the Talk page to be approved, but not just throwing random skills at builds and vetting a build that has something completely different in mind. It just doesn't make sense to vote on a build that isn't the one that has been written, like voting Democratically even though you agree with their views; it just doesn't make any sense. Putting the foot down on bad votes would not only improve the vote quality, but also the quality of the builds on this Wiki. After all, isn't that what the point of this is? To make sure that only the valid and tested builds get through to our coveted "Tested" category. Voting on an unmentioned build variant is the same as voting for a different build. Letting a few strings loose will just lead to widespread arguments such as "My variant WAS valid because so and so" and will lead to other debates within the same article, however, in the meantime, they are actually saying they tested a different build. It's simply easier to put a variant on the talk page as a suggestion instead of a vote. Then the author can test the build with the variant, to see if it is valid or not. &mdash; Rapta  [[image:Rapta_Icon1.gif|19px]] (talk|contribs) 22:11, 21 October 2006 (CDT)


 * I think there are two different possibilities.


 * If you try the build as it is described in the article and you think another skill would be better then I think you should be able to post this in your vote.


 * If you do not have all the skills necessary to test a build as it is described, i.e. the build says to use Mantra of Inscriptions but you don't have it so you use Energy Drain or something, then I think you should make this very clear in the vote, and possibly not even vote at all. I certainly think in situations where the elite skill is not the one described in the article players will have a different experience to that intended by the author.  &lt;LordBiro&gt;/&lt;Talk&gt; 06:33, 22 October 2006 (CDT)

Inundated
My eldest daughter just pointed out that there are around 400 "untested" builds.

And with Nightfall just around the corner, we're freakin' doomed, man...

...well, okay, not doomed, but the problem is only going to get worse.

Perhaps those of us who volunteered to work on specific professions should nominate a few untested builds ("gems") (in our opinions), and a few "let's get rid of these" suggestions? Maybe two or three in the professions we volunteered for? I'd be willing to do that this morning for Ranger and Necromancer. The community could take a look at those this week, and maybe clean up some of the back-log. &mdash; ChaoticCoyote 07:32, 23 October 2006 (CDT)


 * The problem of to many untested builds has been around for a long time now. A current proposal (check Talk:Builds) is to up the number of "current featured untested builds", which would be very similar to your proposal. The only real solution is, of course, more testing of builds. --Xeeron 09:52, 23 October 2006 (CDT)

Voting criteria
N/any Dedicated Minion Master was recently voted unfavoured (then voted back into untested) on the grounds that it's a Minion Master build, and MM builds have been done already with N/Mo MM Support, N/Mo Minion Master and N/any Vampiric Equilibrium. N/Mo MM Support and N/any Vampiric Equilibrium are very specific variants of MM whereas N/Mo Minion Master is supposed to be the general, all purpose version. However, N/any Dedicated Minion Master is not suitable for merging with N/Mo Minion Master as part of the reason I created N/any Dedicated Minion Master is to show that it is far from necessary to use Monk as a secondary profession for a MM (in fact I think N/Mo Minion Master is quite a poor build all round, but I was outvoted there). Further, the N/Mo Minion Master is deeply generic whereas N/any Dedicated Minion Master presents two entirely different builds for use depending on the make-up of the rest of your party. That means we're left with a build being voted as "unviable" wholly on the grounds that we already have something that creates minions.

Either we need to alter the voting criteria so that builds can become unfavoured because they share a similar concept (in which case somebody needs to merge, for example, all the 55 builds) or those votes are invalid. Somehow Minion Mastery seems to be singled out for special abuse in this regard, but I fail to see the difference between different variations of MM and variations of Boon Prot (Mo/Me Boon Prot] and Mo/N Boon Prot are functionally identical).

As the creator of the N/any Dedicated Minion Master build page I was happy (well, happy-ish) to let the unfavoured slide, but as other people have brought it up on the talk page I thought it was worth mentioning here too. --NieA7 09:24, 23 October 2006 (CDT) I Agree as of now ~ is a vote as is I like pie~ and that is just ridiculous.-Onlyashadow, Top 100 Guild 09:56, 23 October 2006 (CDT)
 * I would tend to agree with you if there was more difference between N/any Dedicated Minion Master|your build and N/any Minion Master. But, the only difference is ONE skill. Not attributes, or anything else. I'm sorry if you created your build first and you're upset because it didn't get vetted before the other one, but that's no excuse to keep a duplicate build up in the builds section (just because mine was created first). This is a community effort. Not a place for individuals to recieve special recognition. — Jyro X [[Image:Darkgrin.jpg|25px]] 12:46, 24 October 2006 (CDT)


 * Jyro, I'm not only talking about my build, I am concerned that there's a very major flaw in the way voting works.. There are 4 - 4! - votes saying we don't need another MM build on the Dedicated page, ALL of them cast before the votes on the now approved build. I'm not saying that the Dedicated shouldn't be unfavoured (though I don't think it should be deleted, there are too many issues revolving around the talk page), I am saying that the process seems to me to have screwed up very badly here and needs clarification. If we didn't need any more MM builds the now approved one should've been deleted long ago, along with mine. If we did then the Dedicated would actually have been approved before the N/Any MM build was created (see the talk archive). What's happened has been neither balanced nor fair, two key things we should be aiming for within the builds section. --NieA7 13:03, 24 October 2006 (CDT)

There seems to be an issue with testing, and I know you don't have to test to vote but I think it should be a requirement. Far too many people are voting favored or unfavored without a single word or just a emotionicon or say that its stupid or great with out saying why. Many people even admit to not testing and say that they just don't think it'll work, but GW is a fairly complex game so even builds that looks great or terrible on paper might turn out differently in reality. I think there needs to be a more strict voting criteria than how it is now... espeically when votes are counted the same even if you spend 1-2 hours testing the build and then voting or someone who leaves a blank vote. Also I think people should be required to leave at least a coherent sentance as to why they liked the build or not on the vote. Lania Elderfire 11:36, 5 December 2006 (CST)


 * You can't make something unverifiable, such as testing the build or having a lucid and intelligent argument to back up your vote, a requirement. --Fyren 13:13, 5 December 2006 (CST)


 * I understand your concern Lania, but as Fyren says, putting restrictions on who can vote and under what circumstances would slow down the build vetting process. It's my opinion that people should be entitled to vote for or against a build for whatever reason they choose.  &lt;LordBiro&gt;/&lt;Talk&gt; 13:44, 5 December 2006 (CST)


 * would it really be that bad if the vetting process becomes slower?Lania Elderfire 10:10, 6 December 2006 (CST)


 * Perhaps not, but I do think that if someone sees a build that they think is unsuitable to go into tested they should be allowed to vote against it. Of course, there are some builds that do not look as effective as they are. For example, if the effects of expertise were still misunderstood, then looking at the skills and attributes of a Touch Ranger you would be forgiven for thinking it was rubbish. If this were the case it would be the responsibility of the build author to make this clear.


 * Basically, what I'm trying to say is, yes, I agree that sometimes it's not clear from looking at a build whether it is good or not, but no, I don't think we should change the policy to make testing mandatory. If a build is better than it appears then the reason why should be made as clear as possible.  &lt;LordBiro&gt;/&lt;Talk&gt; 11:55, 6 December 2006 (CST)


 * Not to be redundant here, but I think my build:D/E Obsidian Dervish build sort of sums up the flaws preasnt in the voting system. The large majority of the voters (especially the unfavored ones) left no specific reason for their vote, many admit to not even testing it, and some don't even leave a logical reason (one voter left the simple commet "meep meep"). Many voters appear to be voting simply on the fact that the Dervish is an inferior class when compared to the Warrior. I think something, heck, anything needs to be done to fix the policy here (look at the discussion and you'll see what I mean).Actellim 15:10, 7 February 2007 (CST)

Old subject, but I'm going to give my two cents.

If you look at Template:tested-build, you'll see that it says "This build has been successfully vetted by the GuildWiki community. The general consensus among users of GuildWiki is that this is a valid and viable build."

Now if you ask me that simply means that the build works. It doesn't say anything about "this build works but we think it shouldn't because there's a bunch of copies of it out there". Nor does it say "|]1s build 1s |_||33|2 l33t and j00 m|_|$+ |_|$3 1+". (Roughly, "This is a very good build that is highly recommended.") Perhaps we need a template for the second (Template:l33t-build), but that's not the point. The point is that what this implies is that the build has been voted that it works.

I'm going to make a couple assumptions that may or may not seem fair, but in my experience they're true for most people. Bear with me.

If a random person comes onto the wiki and sees this, they're going to think "yay I can use this on my ele!" or whatever. Now suppose that that user only knows how to look at a wiki, not how to use it (i.e. they don't look at talk pages, histories, related pages, or know how/feel obliged to edit), they'll take that template at face value. Likewise, if they see an unfavored template, they're going to take THAT at face value.

Now then, the randoms that come here are generally playing and browsing while they play (case in point: I'm trying to farm Sunreach Warmaker while typing this). If they're in a party and discussing the builds of the various people in the party, they'll probably bring this up. And from my experience a lot of random players that do that think that the wiki is the be all and end all of builds and will make a big stink about one skill that could in reality be relatively minor.

I guess what I'm trying to say (and I don't know if I'm saying it right) is that if a build works the way it's said it will, it should be approved. If two approved builds are identical in build and tactics, the newer one gets deleted; if they're alike in either but not both, the info on the newer one gets merged onto the older one. --Armond Warblade (talk) 13:36, 21 December 2006 (CST)


 * You know, even after all this time I'm kinda irritated by this (the build I put up came first, was voted unfavoured by the same people who voted favoured on the second one, and was then decried as a duplicate. Not very encouraging), but it's a general point rather than a specific gripe now. What you say makes a lot of sense and I wouldn't disagree with any of it, but personally I'd rather we did things the other way around. The builds in tested shouldn't be builds that "just work", as many builds work in as much as they're not horribly broken. What tested should be is a collection of builds that work particularly well, builds which have a singularly elegant synergy, combine skills/attributes which most people wouldn't consider putting together (I don't know who thought of the Touch Ranger, but it's that kind of concept that works pretty well is is non-obvious that I'm talking about. What with all the touchie-hate it's probably a bad example to use, but again I'm talking principles rather than specifics), or builds which verifiably fulfil a specific roll (PvP builds used by top 78.5 guilds, farming builds and so on).
 * I think we should be working from the principle that any submitted build shouldn't make it into tested. With that assumption in place it falls back on the build's authors/supporters to prove the case that it's an exceptional build, rather than a build which isn't broken. Variants of anything up to 4 skills should be merged with existing builds, providing that those existing builds are used in the same, or a very similar, way. --NieA7 04:00, 23 January 2007 (CST)

Encourage Vote Info?
So after seeing people place numbers or just a comment with no signature and so on in the voting area I got to thinking. I know we shouldn't enforce any specific vote criteria that requires signatures/explanations, etc. but what if we encouraged/suggested it? For example - this what I currently use:

==Rate-a-Build==

Please test and vote on new builds

Tested (favored):


 * 1) (your vote)

Unfavored:


 * 1) (your vote)

==Discussion==

Or at least I found it useful (taking it from Xeeron's page) and thought maybe a slight expansion to help others know what is best for voting (though not required) might help. Maybe something like this (I bolded the changes added):

==Rate-a-Build==

Please test and vote on new builds

Tested /Favored (please leave your signature or a comment & signature ):


 * 1) (your vote)

Unfavored (please leave your signature & reason) :


 * 1) (your vote)

==Discussion==

I realize it's very basic and many of us already know to do this but many users that vote on builds don't. Thus, why I was curious what others thought about this? I wouldn't start changing everything just those I saw that were new or recent.  Vallen Frostweaver  06:54, 24 October 2006 (CDT)


 * Your changes look good to me, just used them on N/E Blood Of Fire. --NieA7 08:08, 24 October 2006 (CDT)


 * And Skuld just removed it. So cute that he acts so fast. --NieA7 08:12, 24 October 2006 (CDT)


 * And now he's put them back again. --NieA7 08:20, 24 October 2006 (CDT)


 * The drama continues! &mdash; Skuld 08:21, 24 October 2006 (CDT)


 * It's more of a suspense to see what will be delete/replaced next d: -Onlyashadow, Top 100 Guild 08:26, 24 October 2006 (CDT)


 * I feel a need to document its every twist and turn... --NieA7 08:30, 24 October 2006 (CDT)


 * The Plot Thickens! I can see this becoming a paperback very soon.-Onlyashadow, Top 100 Guild 08:41, 24 October 2006 (CDT)


 * I like it. And you cant even argue that it is forcing people to leave a comment, since "please ..." is not an order. Might help getting more comments from new people. --Xeeron 10:19, 24 October 2006 (CDT)

Just took a part of the bolding out (and the second signature above), to make the lines look more slim, check the example below. --Xeeron 10:27, 24 October 2006 (CDT)

==Rate-a-Build==

Please test and vote on new builds

Tested/Favored (please leave your signature & comment):


 * 1) (your vote)

Unfavored (please leave your signature & reason):


 * 1) (your vote)

==Discussion==

turns into:

New Rate-a-Build would look like this
Please test and vote on new builds

Tested/Favored (please leave your signature & comment):


 * 1) (your vote)

Unfavored (please leave your signature & reason):


 * 1) (your vote)


 * Looks good - anybody object if Template:Rate-a-build is updated in line with this? --NieA7 11:24, 24 October 2006 (CDT)
 * Me likey. There's a template!? O.o  Dag nabbit.  Every time I think I already found a template or not in existance another one has existed forever that I didn't see before.  Well, I like it. [[Image:VallenIconwhitesmall.JPG]]  Vallen Frostweaver  12:50, 24 October 2006 (CDT)

...Why has this not been changed on the template yet? >.< That would seriously help. And it would probably reduce the number of votes that are just a signature or a single word. --Armond Warblade (talk) 21:28, 30 December 2006 (CST)
 * Well, because it's not in the policy, and one of our beloved administrators doesn't believe it matters. Regardless, tested votes don't necessarily need comments anyways. &mdash; Rapta  [[image:Rapta_Icon1.gif|19px]] (talk|contribs) 21:42, 30 December 2006 (CST)
 * And if someone wants the votes explained, all a user has to do is go to their talk page and ask them to explain. It's better to keep the actual voting section as clean and neat as possible in my honest opinion. The only reason I make a comment most of the time is if a build is especially good or really horrendous. — Jyro X [[Image:Darkgrin.jpg]] 00:42, 31 December 2006 (CST)

Featured Build changes
I agree with the limitations on the 'tested' build but disagree with the new wording for 'untested' as they can sometimes go for weeks and still have no changes or votes. I would like to have some kind of suggested day limit for 'untested' (maybe 1 week, maybe 5 days?) so we can keep the people looking at stuff and constantly are rotating our build selection. I mean, that last team build was up for 2 weeks with no changes which slows down those that only vote on the builds from the main build page.--  Vallen Frostweaver  11:48, 5 December 2006 (CST)

Build-Author Voting
This page doesn't say a thing about a build's author not being able to vote on his own build, yet we are striking out votes left and right in the Builds section because of that. Was this established somewhere else and left off this page? If not, and we're either breaking the 'Everyone can vote' rules or working off an unwritten one, could we establish it? It really throws off the vetting process if the build author can cast a vote on his/her own build, and it should be assumed that by submitting a build the author is in favour of it. Thanks in advance for any response. - Krowman  02:11, 24 December 2006 (CST)


 * Hm I've actually read the opposite on many recent build votes, saw many people say the author can vote on their own builds! Now I'm completely confused. :S Official clarification would be nice. Entropy 02:13, 24 December 2006 (CST)
 * Build talk:D/any Balthazar's Fury, Build talk:D/W Avatar of Melandru Dervish/Archive 1, Build talk:R/D Bunny Reaper demonstrate the confusion here. They all show author votes invalidated (which I support), but that policy isn't anywhere on this page. -[[Image:Spiked Eggnog.jpg|18px]] Krowman [[Image:Spiked Eggnog.jpg|18px]]  02:28, 24 December 2006 (CST)
 * This needs to be in the policy. Authors are biased and will most likely vote favored.  I think it's ok it the author votes unfavored however. --Lania Elderfire 19:52, 29 December 2006 (CST)


 * I've always thought that the creation of a build counts as support, and as such that vote is assumed (but not counted). --Armond Warblade (talk) 21:23, 30 December 2006 (CST)
 * Me too, though it definitely needs to be spelled out in policy. Wiki-policy-lawyers can otherwise talk around their self-favoring votes. See Build_talk:Rt/any_Preservation_Channeler for an example of the confusion this can cause. — HarshLanguage [[Image:qswearing_small.png|HarshLanguage]] 00:59, 1 January 2007 (CST)

I have added a new proposal to append this problem. — Jyro X 02:04, 1 January 2007 (CST)
 * Does this really require a proposal? =P I mean, basically, the change is here:
 * If disputed, revert it, but it wouldn't make sense to have an author voting on their own build anyways. Like the RFA, it is already understood that the submitter likes that person/build. &mdash; Rapta  [[image:Rapta_Icon1.gif|19px]] (talk|contribs) 23:33, 29 January 2007 (CST)

Unsigned Votes
Do unsigned votes count? It doesn't say to on the policy page, but there's been several vote strike with unsigned votes --Akmdw 19:10, 28 December 2006 (CST)
 * I've asked this before and it's all situational IMO but in most if not all cases they do (unless one user is using multiple accounts to vote several times or a build author is voting on their own build, etc.). You can look back through the history to find out who signed it though and add their signature with the unsigned template like this:




 * ...which will result in this:


 * Hope this helps.--[[Image:VallenIconwhitesmall.JPG]]  Vallen Frostweaver  07:37, 29 December 2006 (CST)
 * No, no, no! Never forget the "subst:"!
 * The code's more like this : Vallen Frostweaver
 * Except replace "time" with the time that the unsigned comment was made. &mdash; Rapta  [[image:Rapta_Icon1.gif|19px]] (talk|contribs) 21:25, 30 December 2006 (CST)
 * So what does the subst: do anyway?--[[Image:VallenIconwhitesmall.JPG]]  Vallen Frostweaver  08:19, 30 January 2007 (CST)
 * It replaces the template call with the code in the actual template itself. So instead of actually just linking to the template, it just puts in the code instead. This keeps the "What Links Here" page for the template clean of 1000 irrelevant links... — Jyro X [[Image:Darkgrin.jpg]] 14:55, 30 January 2007 (CST)
 * EDIT: I recently went on a crusade trying to replace all the template calls with subst tags instead, but a lot of them are now in pages that are protected and/or otherwise inaccessable. So it will now take an admin bot of some sort to clean up all the mistakes. Wish there was some way of automatically putting in the "subst:" tag in the template itself... — Jyro X [[Image:Darkgrin.jpg]] 14:57, 30 January 2007 (CST)

Sort of an unrelated question, but what about blank votes? Suppose some random person just leaves their signature in unfavored (to be honest I've never seen it in favored). Easy way to bring a build down. What do we do about them? --Armond Warblade (talk) 21:32, 30 December 2006 (CST)
 * Part of the problem is one of semantics. A "vote" isn't necessarily something you have to give your reasons for (in general nonwiki usage). I'd like to see reasoning required for build votes, but I understand why people don't do it and don't feel they should have to. — HarshLanguage [[Image:qswearing_small.png|HarshLanguage]] 00:56, 1 January 2007 (CST)

Suggestion/Idea on Voting
(Warning : this is a bit long. Sorry) I've seen alot of discussion and contention on build talk pages regarding votes that are deemed unfair and it occured to me that this might help. One note, I think this is actually possible at the moment that people (that is build authors) aren't as aware of it. The idea being to let the admins strike votes that fall into one of two categories. 1. Obviously, or self-admittedly, not tested. 2. Demonstrably but also unfoundedly biased. That is, for case one, if a person has voted who either admits to not using the build or due to their comments can be shown not to have tested the build (or one similar enough) their vote can be invalidated. In theory, the admins are impartial/logical enough to be able to discern the difference between an author just trying to get their build validated, versus an actual questionable build. In the second case, the author (or concerned user if that occurs) is required to show enough impartial evidence (as decided by the admin) to demonstrate that the vote is unvalid. For example, let's say I vote unfavored on a build because there's a skill in it I don't like or think poorly of (without bothering to test the build). The build author goes around and looks at comments I've made and figures out why I voted unfavored takes that evidence to an admin who can decide if its sufficient to strike my vote. What this allows, in my view, is a recourse for build authors and the community in general to balance the voting system. Currently, anyone can vote for any reason, which makes things more efficient but also more biased. I could, in theory, get a half dozen or so people I know to quickly come on and unfavor a build very shortly after its posted for any or no reason at all, which is not fair to the build author who's spent time and effort putting it together. Build author's then, need a way to come around and say, "look, I wasn't given a fair shot". This would also mean both the author and voters would need to be aware of the process (or more aware). Perhaps a note in the voting template indicating that there is a right to challenge a vote if it can be proven to be unfoundedly biased or unrealistically untested. Opinions? Lojiin 14:43, 17 January 2007 (CST)

Added a Line
Under "New Builds":
 * "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."

What does everyone think? Helps keep Unfavored and new builds under control at the same time. &mdash; Rapta   (talk|contribs) 13:37, 2 February 2007 (CST)
 * Sounds alright to me.--[[Image:VallenIconwhitesmall.JPG]]  Vallen Frostweaver  13:48, 2 February 2007 (CST)
 * /agree. -[[Image:Spiked Eggnog.jpg|19px]] Krowman [[Image:Spiked Eggnog.jpg|19px]] 13:50, 2 February 2007 (CST)
 * Sounds ok to me. Since the delete tag contains the reason the build author will be aware of where the updates can be made at.  i.e. what "normal" procedure is.  Lojiin 13:52, 2 February 2007 (CST)
 * Seems fine to me. What we really need to decide is what happens when we've got two similar builds in untested, as there doesn't seem to be a consensus about that. I think they should all stand and fall on their own merits until one is favoured or unfavoured (after which the other can be merged/deleted etc), but some contributors like putting the newer one up for deletion. --NieA7 19:15, 3 February 2007 (CST)
 * Better kept on a first vet, second merge basis. Basically, if one of the versions gets vetted, the second one that was vetted after would be merged into the first one. &mdash; Rapta  [[image:Rapta_Icon1.gif|19px]] (talk|contribs) 00:53, 4 February 2007 (CST)
 * Sounds like a plan, I never liked one untested build being deleted due to another untested build. Any suggestions as to where policy ought to be altered? I mean obviously all the builds policy needs to be altered, but it ain't gonna happen in one go, may as well try and dribble it in and hope it takes effect before the whole lot gets deleted... --NieA7 09:21, 5 February 2007 (CST)

Proposal
I've tried to set up something new and would like to hear comments. Im in a bit of a rush now, more infos later, see User:Namnatulco/bvp namnatulco 15:18, 20 February 2007 (CST)

Votes with no test
This is absurd. Can't something be done to the voting policy to require even a semblance of a test before people can vote? I just watched a solid, viable build get shot down without a single (tested) unfavoured vote. The only comments that were given were "unnecessary" because the person leaving the vote assumed that everyone had access to Nightfall (because of death leveling for pets. People without Nightfall don't have access to this option).

I brought it to an admin, and was told that nothing could be done about the votes because, according to the current vetting procedure, claims that a build is "unnecessary" are valid. If that's the case, then what the heck constitutes an invalid vote?!? Where is the line?--Token Cleric 22:36, 27 February 2007 (CST)
 * If someone can explain his vote with facts, it's valid. In your case, they are valid, because there's a guilde. If I would put all the builds that I make and that work on the wiki, I'm sure 90% of them will get unfavored. Why? Because they are obsolete. We don't need tons of monk farmers, nor tons of builds for the same purpose.
 * Oh, and, I dont see what's so Nightfall only on this? namnatulco 09:03, 28 February 2007 (CST)


 * Death leveling for most pets requires that you have a monk Hero (you must be able to make it so that they won't heal you, only rez you, which means that a henchman won't work) because most pets can't be dragged all of the way to a rez shrine. You can't use heroes unless you have Nightfall, so that technique won't work.  In addition, nothing is given in that "guide" that takes into account energy management for non-ranger primary characters.
 * But that isn't the point, here. If a build is unique (not a duplicate), effective, and fills a void in the wiki, how is "unnecessary" a reasonable vote?  There are no other X/R builds currently in the Wiki that show people a way to evolve a dire pet in a matter of 3-4 hours.  We had a page for that at one time, but that page is in the process of being deleted.
 * Also, these votes weren't supported with facts, as you describe them. If those were facts, what's to keep someone from giving unfavored votes with the reasoning "I don't think this build should exist"?--Token Cleric 13:43, 28 February 2007 (CST)


 * There is no requirement that a vote to be reasonable. As mentioned before, testing isn't a requirement, either.  Neither are verifiable.  In particular, people will never agree about whether someone's vote is "reasonable" or not.  --15:06, 28 February 2007 (CST)
 * As above, and the description states you can always lure the creature to a res shrine if you do not own Nightfall
 * Oh, ps, the build is an EXACT copy of the old section.


 * Beyond that, testing takes long, while alot of players can see very quickly wether a build works and why/why not. That's probably why testing is not required. (correct me if i'm wrong here) namnatulco 10:33, 1 March 2007 (CST)


 * In response to your request: you're wrong. On both points.  First, testing doesn't take long at all.  Generally, 20 minutes is more than enough time to see of a build works; 5-10 if it is designed for a specific purpose.  Second (and this is the more important of the two), player can't tell at a glance whether a build works or not.  There are a lot of viable builds that are inherently counter-intuitive, and without testing people would have rejected them outright (contrary to what you might think, not everyone believed back at the beginning that the 55 builds would work.  Of course, 5 minutes of seeing it in action changed their mind, but if they had voted without the testing they would have given it an Unfavoured vote).
 * Likewise, there are a lot of builds that people post because they "should" work, but actually suck. If the playtesters do as you suggest, they'll probably come to the same conclusion as the person who posted the build: "It should work."  If you go around giving favoured votes based on that, you'll end up with builds in the tested section that have never even been played.
 * You are right, however, that that the W/R build is a transfer from the old page. I wrote that one, too.  That page is being deleted due to formatting and inactivity, and I was in the process of transferring the build from that page into the standard build format so that the information won't be lost.--Token Cleric 13:01, 1 March 2007 (CST)
 * If someone used to think 55 wouldn't work, it's plain stupid. Everyone can do the calculation of (maxhp)*0,1=(max damage) and can do 2*(hp-regen)=(hp per second). Spirit bonding would be a better example. Agreed, knowledge of the games' mechanics is required, but exploiting some mechanic (like with the 55), you should at least note that on your build's page. Besides, as an autor, you can always explain to unfavored voters why they are wrong. I'm against non-tested votes, but in most obvious cases, it speeds up deletion/unfavoring. Also, could you give me an example on builds that should work? In your example, it's hard to argue against the unfavored, but if you would have a build which based on a specific tactic, you can better explain your tactic in the discussion. Normally, working builds will be favored, and not working ones will be unfavored. If an unfavored build gets improved, it goes to untested, then to favored if it's good enough.
 * An example. Say I develop a new build, say User:Namnatulco/builds (the top one). If someone would argue that it sucks, because Storm Dijnn's Haste is crap on it, and it has too much warrior counters, and shock-arrow is too low damage compared to other lightning skills, I could explain that shock arrow can be used to keep the thunderclap effect on, the haste is for flag-running, and it has lots of warrior counters because gvg has alot of warriors now (im not saying they do, the build is just something random i came up with, and dumped on my page). Then, the voter could/would see that the skills do have a use. He would next, argue that it has not enough energy management (where he has a good point). If he, in the end, is convinced, he will just strike his old vote, and vote favored instead. It's hard to come up with an example where the current system does not work correctly, in the end.
 * I support you on the fact that testing is important, but, imho, resoning is far more important. It would be better (and less of a change), to have everyone put a reson in for their vote (favored or unfavored). Things like "", "blah", "sucks", "works", "Good", or annons saying something on the lines of "OMG Best BUILD EVER blah blah" should be stroked and replaced with a reson. My proposal would be this.
 * As for testing, a pve build requires only minor testing (ie. the solo trapper, or the w/r), because the situation is always the same in pve (save for some random spawns). In pvp however, if you want to actually test a build, you'll have to put it against several different teams. A decent spike team might be able to beat a team with weaker healers, but will easily be beaten by another team. In HA, there's a pretty sizeable amount of builds which could be a possible counter. Hench the longer testing for those. Oh, and, sorry for the long story. namnatulco 11:24, 2 March 2007 (CST)

Well, you've supported my argument several times over: This last one is especially important, as it is the most un-wiki-like aspect of the policy. If people can shift the argument from the viability of the build to their perceived necessity of the build, there is nothing that can be done. No amount of convincing or testing will change their minds. It is absurd that a person can't outright delete an article from the wiki for the reason of "this page serves no purpose", but they can effectively remove a build article on the same grounds.
 * you said If someone used to think 55 wouldn't work, it's plain stupid. That doesn't change the fact that they did.  Apparently, the current vetting process does not take stupidity into account, as these people would be just as free to vote as those who do understand the builds.  That's the effect of not requiring testing.
 * You said Normally, working builds will be favored, and not working ones will be unfavored. The build that I posted works, and 2 people have already posted favored votes based on testing.  Unfortunately, that doesn't change the 6 that posted based on "this build is unnecessary."
 * You said As for testing, a pve build requires only minor testing (ie. the solo trapper, or the w/r), because the situation is always the same in pve (save for some random spawns). In pvp however, if you want to actually test a build, you'll have to put it against several different teams. I wouldn't know about the testing PvP, as I don't play PvP much. I've been told that my Tank Master build is great for PvP, but I wouldn't call it a PvP build.  In any case, we're talking about a PvE build (more of a farming build) here, and you yourself said that it shouldn't take long to test.  Why shouldn't testing be done if it is a minor as you say?
 * You said if you would have a build which based on a specific tactic, you can better explain your tactic in the discussion. This is the heart of the issue, and the main reason why I brought this up.  No amount of explaining of tactics will help if people are voting it down because they believe it isn't necessary.  As shown in my example above, the people didn't even look at the tactics; their arguments are based solely on their perception of whether it is needed on the wiki.

Regarding a "should work" build: I've seen several of them posted and eventually rejected because people actually did the testing.  The problem comes when people vote, up or down, without understanding the nuances that only testing will show.--Token Cleric 13:53, 2 March 2007 (CST)
 * At least we agree on one point: explaining your vote. Might I note that I would prefer voters to test before they vote. Again, your 55 example: if someone would say it does not work, obviously you didn't put the math in your page (or they did not read it). Then, your build hasn't been deleted, just unfavored, because it has no real purpose (says the page). IMHO it should be more of a guide with some example skills (like the old one). That's becaus you're trying to do one thing, that takes some time, and then the build is useless. It's like a guide to farming dye in pre-searing: you farm the dye, after you have enough, you head for post-searing and you sell the dyes, but you can't go back. Bad example maybe, but still.
 * Builds that work, but are useless won't/shouldn't become vetted. Unnecessary builds might then work, they do not have enough use to be vetted. That's where we have a personal page for. As for your specific build: I can't really say how unnecessary it is, because I haven't got a warrior. I can't imagine a situation where a warrior would want a pet, though.
 * On testing: most builds require time/money to get it working. If someone would test every single pve build he saw, he'd be out of money in no time. Just a sidenote. Plus: it's not my fault we have the same policy for pve AND pvp.
 * Agreed that testing is preferred, but if you can explain why /why not just as well without testing, do so. Oh, and, sorry for the late reply. namnatulco 07:09, 5 March 2007 (CST)

Split Polls
Here's a possible solution to the voting without testing issue. Simply put, split them apart. Have 2 sections for voting, 1st section is voting by observation only, and the 2nd voting by testing (requires proof (ie screenshots), and a report of where it was tested, against what, evalutation against meta, etc. A chain of unfavored observation votes should be obvious to the author that the build probably won't do well. Mixed votes (half obs fav, half obs unfav) should warrant testing, but after some further polishing based on suggestions from the community. A flurry of unfav obs votes should be an indication the build needs more work, but it shouldn't be sent to unfavored yet. Finally, the actual testing is expected to take a long time (longer than now anyways). This will help ensure only quality builds get vetted, and near-quality builds can become further polished and perfected so they too will be quality builds.

For those who can't read: --8765 01:03, 20 March 2007 (CDT)
 * 1) Provisional voting (no need to test): good voting feedback should tell testers to go ahead and try the build
 * 2) Testing voting: requires proof and details of the testing before the build is favored/unfavored