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 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)

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)

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)