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)