GuildWiki talk:Builds

Don't like the no deleting bit, I think an extra bit, "if the build is not seen to be seen as little value to a reader" and if it is abandonned by the author (first point aswell) &mdash; Skuld 08:25, 2 September 2006 (CDT)


 * Moving this to Builds. By definition, everything in the GuildWiki namespace pertains to things on the wiki. :) &mdash;Tanaric 15:51, 4 September 2006 (CDT)

Editor's notes
I hope you don't think it too forward of me to edit this policy to be in line, stylistically, with the rest of the build articles on the GuildWiki. This mostly involved changing "the wiki" to "GuildWiki" and changing some wordings to be more personal ("the standards of the wiki" to "our standards", etc.). I also removed the NOTOC tag, as there's no reason to prevent a TOC from displaying on a policy article.

I take a great interest in policy, as everyone knows, and I'm thrilled that somebody besides me is getting involved in writing this stuff down. I also think this article is off to a good start, and I think it will become a great policy article after some of the rest of us help contribute.

One thing I think needs to be clarified.

As soon as a build is ready to leave stub status, it is placed in the category untested builds.

When is a build ready to leave stub status? That could probably encompass a whole heading by itself!

Finally, I think the policy as proposed should be subtly changed. Votes are non-binding on GuildWiki and always have been. I don't disagree with the usage of Rate-A-Build, because I believe it provides a great summary of what the build is to a reader, but I do disagree with making the results policy. I'd like to change the "X votes" for favoring/unfavoring a build into "consensus." More specifically, I think a build needs a consensus for favoring for it to become a favored build. If the vote is 50/50, and, more importantly, the discussion is 50/50, I think the build must be marked unfavored.

&mdash;Tanaric 16:13, 4 September 2006 (CDT)
 * Consensus won't be found even on builds that you will see all over in higher-level GvG if the previous votes are an indication. I think the entire process is pretty broken, but I can't really come up with something that makes sense.  I might just still be stuck in the same mindset I was in a year ago when I was arguing against having builds at all.  --Fyren 16:37, 4 September 2006 (CDT)


 * I have been giving this some thought recently. My ideas aren't really fully thought out, so please don't presume that this is a solution or anything!


 * I was wondering, if we were to think outside of the limitations of mediawiki for a moment and outside of our current system of using categories, what would the best solution be then? I was wondering if there would be some way to "rank" builds. So every build article had a number of stars on them or something, and users come along and vote and this increases the rating of the build, or it decreases the rating of the build. Having a single row of stars wouldn't make any sense, since it's not really practical to mark builds as overall builds, there should be one row for PvE, one for PvP, perhaps other rows depending on what the build is aimed at.


 * I realise this may be a pointless thought exercise, and I'm not a huge fan of voting myself, but I just thought I'd share my half-baked idea with you all to see if you could bake the other half :)  &lt;LordBiro&gt;/&lt;Talk&gt; 16:55, 4 September 2006 (CDT)


 * Tanaric: Thanks for the correction, to my utter disappointment, many many years of learning and using English have not yet been enough to write stuff the way I want it to be written, your version is much better.
 * For me the difference between a stubbed build and an untested build is formal (are the headings right, is the skill bar working without red links, is something written under 'usage') everything relating to "does the article work in the wiki as an article is supposed to work her" whereas the difference between untested and tested is down to "does the build work like an build is supposed to work in guildwars". So far there have been very few problems with getting articles from stub to untested, thx to the syntax help most people get it right when creating the article and in case they dont, it is usually corrected very fast. Most builds stuck in stubs are abandoned by the original author before the idea of the build was fully written down.
 * I wont be opposed to writing in more general form about finding an concensus (if people are worried about overly tying our hands by writing it into a policy article), but the number of votes needed should be written down somewhere (unless the voting procedure is completely abandoned). There have been several and repeated problems which all did arise from the fact that there was no such exact number written down and people disagreed over the amount of votes needed/felt treated unfairly.


 * Fyren: I agree that the vote process is not perfect. However it is far better compared to what we had before and I have yet to hear a better proposal (exception, see below). I feel that the number of visits on the build page show that they are a popular and demanded feature of the wiki and unless I see some better way to organise them, I will defend the voting process.


 * Biro: That is a very nice idea (reminds me of the way posts/users are ranked on many message boards). However there are 2 drawbacks. The first being that I have no idea how to implement that in an automatised way (maybe someone else can help here), but doing it by hand would definitly impossible. The second is that a ranking with stars according to categories would help a lot to make the vetting process more detailed, but it would still have the same basic problem: It would still be people judging builds along their subjective views, therefore necessarily people disagreeing as well. --Xeeron 18:20, 4 September 2006 (CDT)


 * Xeeron: I appreciate your kind comments on my edits. There were a couple more I'd like to reword to better fit native English, but I was hesitant to edit too heavily at once. Since I appear to have your blessing now, I'll do so when time permits.


 * I honestly don't see a good wiki solution for builds, besides total anarchy, which would be basically unusable. I think our current system works well, but I think our current solution is fairly unwiki&mdash;it is essentially a moderation board of ~6 hardcore editors that choose which builds become favored.


 * I think Biro's method is probably the ideal way of doing builds. Unfortunately, that is impossible within the wiki structure, which means it's impossible to host here. Honestly, I think the best solution is to have a sister site that deals exclusively with builds&mdash;the software for Biro's solution wouldn't be hard to whip up from scratch. I'd even be willing to host and implement it, if it meant that GuildWiki no longer hosted builds.


 * &mdash;Tanaric 18:31, 4 September 2006 (CDT)


 * Ooh, a challenge says me! Rating-star-generator proof-of-concept: http://www.t29.dk/~nica/gold.php (Not really useful for anything in practice, unless a seperate box is built that hosts non-wiki code, but I figured it would be fun to do.) --Bishop 15:27, 5 September 2006 (CDT)


 * Just a short note: While there are 2 testers, who do a lot of testing between them (Rapta and Skuld), it would be wrong to speak of 6 hardcore editors. In the last months I have seen many different people vote and even those who voted repeatedly are more numberous. However, even if someone votes on 5 builds, you are likely not to notice him/her unless you check all ~400 builds we currently have. The voting process is really open to everyone, all anon votes count the same as the ones by heavy editors, so I dont see how the lack of participation there is be attributed as the fault of the process. Incidentally, the people participating in the more important process of creating new policies are considerably less numberous than those voting on builds. Does that mean we should scrap all our policies? --Xeeron 07:06, 7 September 2006 (CDT)

Comments on process
I know this has been said in many different places, but I think it's the most relevant here. I think voting is the wrong way to vet builds. I further suggest that build vetting be treated like Featured Articles on Wikipedia. My proposal is not very fleshed out, but briefly: (Below these are the unfavored, archived, etc.)
 * "Featured builds" (currently called "tested builds") are builds that have been rigorously tested by the community and found to be valid and viable.
 * "Untested builds" are builds that have been found to comply with GW:BUILD and satisfies GW:WBE. However, no consensus has emerged that this build is valid and viable.
 * "Build stubs" are builds that are waiting to get into Untested, but currently fail GW:BUILD or GW:WBE.

Now, when someone thinks that they have found a build that is worthy of being featured, he nominates the build for this status and then initiates commentary (i.e., a "vote") on the nomination. The nomination will be a two-edged sword. If the build is found to be exceptional by a supermajority of participants in the discussion (sometimes called "consensus"), it will be made into a Featured build. If the build is found to be terrible by a supermajority, it will be demoted to Unfavored. If no consensus emerges, the nomination (not the build) fails, to be revisited at a later time perhaps. This build will then return to untested.

The nomination will have to come from a non-author. This means that at least one other person must agree with the author that the build is solid and that it satisfies the style guidelines. This will force the author to look for someone willing to nominate the build. I will list myself as an available volunteer for this, and I hope others who care about builds will do so as well.

Why this is better than the current process:
 * There is no feeling that the entire incoming deluge of builds should be taken head on. People can relax and participate in only the nominations they care about.
 * Featured builds will hopefully be of much greater quality as they will have to satisfy style guidelines before they can even be nominated. There will be no premature voting on builds that have huge gaping holes (such as where it is to be used, as I found with A/Me Genjutsu Specialist, a build that was rushed into tested).
 * This will prevent hit-and-run builds, as if an author wants a build to be nominated he will have to put in some effort.

Potential demerits:
 * The untested builds category will be large and potentially unnavigable. This is almost the reality today.
 * Builds can languish in limbo indefinitely.

Comments? zaishen 05:44, 7 September 2006 (CDT)


 * One further note: I am most concerned about the quality of the tested builds, as I think there are pretty serious problems with many of these articles. I think as a class they do not proudly represent the best of GuildWiki. I have started to go over them and clean them up to conform with the style guidelines and the grammar of the English language. Others are welcome to aid this process and if there is enough interest I will make this into a proper volunteer taskforce with centralized coordination (think WikiProjects on Wikipedia). zaishen 05:52, 7 September 2006 (CDT)


 * So its like double voting, but the first voting part is just a normal joe that nominate the build which he things got potential, then the second voting take place where people actually test the build? Not a bad idea. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 06:04, 7 September 2006 (CDT)


 * I personally dislike the term "voting". The first nomination is not a vote: it's a nomination. Someone who agrees with the author that the build is solid proposes the build as a featured build candidate. Once nominated, the nomination is either supported or opposed, not the build itself. Discussion of the build can take place independently of the nomination. The nomination might have been done too early, before the build has been polished into shape: in this case, the nomination should be rejected, with a possibility of a future renom. Alternatively, the build might have no redeeming value, in which case the nomination discussion might reject the nomination with prejudice and the build will end up in the unfavored gutter. I have three principles here that I think should be kept in mind:
 * Vote on the nomination, not on the build. Disagreements about the build are a matter of discussion, not voting, and should be done on the build's talk page.
 * Votes are not done prematurely. Obviously bad builds can be polished into shape, but once they are dumped into unfavored no one–not even the author–will want to touch the build again.
 * Nomination for featured builds should be centralized. This is like the nominations for administrators. At any time it is absolutely clear which builds are under consideration for featured status.
 * All nominations should time out after 5 days or a week, after which the consensus is tallied. zaishen 07:00, 7 September 2006 (CDT)


 * The build you refer to should not have been made tested, I guess that the anon editing it was not aware of the way we do our vetting. But people doing bad edits is a general wiki problem and not specific to build voting. If anything, with votes clearly displayed, it is much easier to detect such edits.
 * In general, the vote should always about how good the build is, not how good the presentation. Changing grammar, language and formating is an ongoing process in any wiki. Builds should meet certain minimal standards (i.e. not being a stub anymore), but I dont feel that some odd spelling should stop a good build from becomming tested.
 * The drawback of your procedure (as almost any alternative procedure mentioned so far) is its slowness. Imagine we need 1 week to properly discuss a nomination and accept 2/3s of them. After one year, we would have 35 tested builds and some 17 unfavored. On the other hand, we get on average 3 new builds a day (likely the number is even higher). So our categores would look like this:
 * Tested: 35 builds
 * Unfavored: 17 builds
 * Untested: 1043 builds (excellent,good and crap all mixed together)
 * I dont think that would be helpful. --Xeeron 07:06, 7 September 2006 (CDT)


 * I don't think slowness is a valid criticism of this proposal. There is no sword hanging over us to vet builds as fast as possible. In fact, hastiness is the antithesis of filtering for good content. It is far better to have a few well supported builds than a large number of build articles filled with highly questionable junk that somehow sneaked through a premature vote. zaishen 07:23, 7 September 2006 (CDT)


 * "There is no sword hanging over us to vet builds as fast as possible"
 * That really depends on what we want to achieve. If our goal is to filter out the best GW builds, no matter how long it takes, you are right. However my personal goal is different: I try to create the build section that is most helpful for users comming to the wiki. And for that, finding only a tiny number of tested builds is a huge drawback. --Xeeron 07:40, 7 September 2006 (CDT)


 * I don't think having builds of questionable quality in the tested class is being helpful to the reader of the wiki. I also don't think that being hasty about "voting" leads to good results. Lastly, the process I suggest can be as fast or as slow as there are testers available, which is the bottleneck for the current status quo also. However, my proposal will be able to sift for quality much better than the status quo as it will prevent premature votes. zaishen 07:48, 7 September 2006 (CDT)


 * PS: An advantage of the build vote without closing date is that you can continue to vote for tested builds. If some build managed to get through, but enough people feel it is bad and vote accordingly, it will be moved to unfavored. --Xeeron 07:41, 7 September 2006 (CDT)


 * Votes without clear end dates are the worst of all possible ways to go about getting consensus. Consensus can only be built by active participation. It should not be the case that a build is teetering on the edge of some arbitrary figure and months after discussion has died down it suddenly achieves a magic number of votes. Who knows what might have transpired between votes! zaishen 07:48, 7 September 2006 (CDT)


 * IMO, builds voting without ending date is needed, since skills are changing all the time and im expecting them to change more after Nightfall released. If they nerfed or buff a skill, previously tested or unfavoured build maybe not viable or viable respectiviely. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 08:18, 7 September 2006 (CDT)


 * When conditions change so drastically, it is better to restart the discussion than to have some number of votes from before the change and some number from after. In my proposal, drastic changes can be handled by a renomination for featured status. zaishen 08:22, 7 September 2006 (CDT)


 * The problem is, what makes those votes invalid? as long as they are valid votes, we should accept it. They might not able to vote during the voting period due to holidays or testing extensively ortesting other build. They mgiht bring up points where people aren't aware off by the time of voting or testing, etc. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 08:29, 7 September 2006 (CDT)


 * Well, no votes in the wiki should be binding. If a build was incorrectly promoted or demoted, it can be brought back to testing and the discussion restarted. Of course, to do this a clear reason must be provided, as we don't simply want to be in livelock. zaishen 08:34, 7 September 2006 (CDT)


 * I prefer this procedure over what we're doing now, I guess. I don't like ease and fluidity of the current procedure's category shuffling and voting.  Like Zaishen, I'd rather it be hard to get into tested rather than easy to get out of untested.  --Fyren 13:51, 7 September 2006 (CDT)

How about this idea... (And please forgive me if it has been introduced earlier in some other format.) How about we add a new category: Category:Builds graveyard or Category:Build fossils. Any build that is unable to escape the "untested" status in more than a month gets moved there. This category is still listed in the "Builds" portal page but with the clear notion that these are builds no one cared to test, try at your own risk. If the build gathers enough votes in time, it is salvaged from the graveyard, if it does not, it languishes there. I would also recommend that the Builds admin (Xeeron in my mind, but he can delegate the delete flagging to others) be given the authority to delete builds in the graveyard he deems to be abolute crap and that he scans new additions to the graveyard once a week or so to make sure the wiki is not gathering junk. It just seems obvious to me that there are builds that will languish in the untested category forever. i.e. Builds that seem to work, but no one cares about them. Think about it build people. --Karlos 07:21, 7 September 2006 (CDT)
 * I don't really see an advantage to having such a category as opposed to leaving it in untested. --Fyren


 * There is one key difference... It says, there is no pressure to test these. The name of the category and the separation is the key. You can say well, people may try the builds in untested at their own peril, that is true. The difference is that for those involved in the Builds vetting process, such a category would relieve them of the pressure of lookingdown 500 untested builds instead of just 50. If a build fails to generate interest among testers or readers for a whole month, then that is just it, it's an abandoned build. If we were paying these build testers, then we would try an dfind a way for them to get through X amount of builds in N number of days without compromising the vetting process. But we are not paying them. 13:51, 7 September 2006 (CDT)


 * Agreed with karlos. However, if this is to be done, I believe its necessary to create a featured build for the unfavored, otherwise one month is not enough: few people look there (Not a fifty five 15:09, 12 September 2006 (CDT))

Process proposal initiated
I have started the following, heavily influenced by the featured article system on Wikipedia: These are tagged with as this is only a proposal at the moment. If there is interest, we can attempt to see how it works with a few example builds. zaishen 07:59, 7 September 2006 (CDT)
 * Featured build candidate
 * Featured build criteria


 * I think Mo/E Solo G is a good candidate for this experiment, if the authors are OK with it. zaishen 08:23, 7 September 2006 (CDT)


 * I strongly support this process and this test run, though I will take no part in it, seeing as I know very little about Guild Wars. :) &mdash;Tanaric 19:33, 7 September 2006 (CDT)


 * Don't you just hate it when you go away for a couple of days and come back to find everything's changed? :P As I discussed a few days ago at GuildWiki_talk:Style_and_formatting/Builds I am not a huge fan of the processes in place for rating builds. I think Xeeron does a great job, but I don't agree that we should be trying to populate the tested category as quickly as possible. I also don't agree that 3 votes either way should be regarded as consensus. In short I'm in favour of this suggested policy, and I think I would be more likely to be involved in the rating process if it were implemented.  &lt;LordBiro&gt;/&lt;Talk&gt; 04:59, 8 September 2006 (CDT)


 * Interesting. Yesterday I was expecting this proposal to get no support, but today's outlook seems much different. However, I would still like to have Xeeron's blessing. This is worrisome: it wouldn't be worth changing processes if the old timers thought they were being steamrolled over and stopped contributing. Let's see if there isn't a middle ground. zaishen 06:15, 8 September 2006 (CDT)


 * This proposal is now indefinitely on hold until Xeeron returns. I will return to lurking. I am sorry to see that he has taken my suggestion as an attack on him and his work. zaishen 17:27, 9 September 2006 (CDT)

As Xeeron has apparently decided to sit out the policy debate, I have begun an experimental run of this proposal. I have nominated the following two builds for moving to "tested"/"featured" (whatever we call it in the end). Feel free to participate in this experimental run. Keep in mind that the "voting" in the nomination is solely about the nomination. A failed nomination simply indicates that there is no consensus about the quality of the build, not that there is consensus that the build is bad quality. I will later propose a mirror process for moving builds from testing to unfavored. Also be keenly aware that this is an untested process for vetting builds and might eventually end up being scrapped wholely. Don't get too attached to it, or hate it too much before it has had a chance. 66.90.73.113 01:23, 13 September 2006 (CDT)
 * A/E Knock it Off
 * R/A Lunge as One

Compromise
Okay so some say vetting builds should be sped up, some say more time should be spent testing. How about both? Impossible? Nope! here's my solution: A fourth Category.

A new 4 category system where builds must pass a "screening" before even being tested. This should effectively eliminate builds that are simply stupid: sever artery, mending, heal party, optional, optional etc. The screening would be exactly like normal voting except no testing and short exmplanations are encouraged, not discouraged. In the screening system it would take 2-4 unanimous votes (later to be decided) to direct it to either tested or unfavoured. If it is not unanimous, it will go to another category: "continued debate" (crappy name, might think of something later). The screening votes will be wiped (or saved separately for history), and testing votes will begin, with w/e system we choose, only testing is strictly enforced (a warning tag will be placed saying "Do not vote unless you have throughly tested the build"). It should be noted that only people with high pvp experience should participate in Screening, say people with 100k bal faction? E.g. people like rapta or skuld are in fact pretty good. I'm a very experienced pvper and you'll find I agree with about 80% of what they agree on, and the remaining 20% I may not even be right on or have tested the build and found errors in their argument. No way to enforce this of course, but it will stop MOST noobs from making complete guesses. (This is currently in debate, most people believe experience should not be required) No expereince needed for testing rly, since the testers should use the build according to the builds "usage" section.

The new category flow will work like this:

Screening ---> tested or unfavored or continued debate --->

Continued debate --->unfavored or tested.

Lastly, most people think Unfavoured is Build hell and tested is build heaven: there's no going back. This isnt true, people can still vote on them!! (stated in guildwiki:build(s) I think). To this one might say, so what?? nobody looks at them. However, some few do. Their efforts are in vain rly cause nobody will notice a favored vote.

I think this can be changed, with almost no effort at all. Simply have a featured build version for the unfavored, like tested and untested have. It would be used only if a positive vote has been made by someone while the build was in untested. Only a second vote would be needed to bring it to contiunued debate. If one hasnt been made in a week (it should be within a week cause the build is featured), it will remain permanently in unfavored. (Not a fifty five 12:18, 8 September 2006 (CDT))


 * There are, in my opinion, too many levels in the builds hierarchy already. Screening should happen implicitly; in fact, I would say that all build articles, tested or not, are always under scrutiny. However, I agree with you that no voting or vetting should happen until the build makes a modicum of sense, which is why I have proposed a nomination procedure. This is influenced by the "featured articles" process on Wikipedia. zaishen 12:25, 8 September 2006 (CDT)


 * I just wrote something and it didnt get saved o.O. Anyways briefly.  I scanned your thing.  Mines faster at elimating the truly awful builds which I think is the main goal.  Not rly sure if either of our ideas is correct, but they're both a step forward to finding a better system (Not a fifty five 12:33, 8 September 2006 (CDT))


 * I don't agree that yours is faster, nor even with the unstated assumption that we should be "eliminating" contributions as fast as possible. I further think that there are two different issues here: (1) promoting great builds to tested, and (2) demoting awful builds to unfavored, or deleting them outright. These two issues should, ideally, have separate processes. Lastly, I fundamentally disagree with your requirement for nominated build screeners in the wiki. A wiki is for anyone to contribute. Peer review should be open, not hampered by gatekeepers. We are not academia. zaishen 12:37, 8 September 2006 (CDT)


 * Briefly explained. Screening is a rly rly hard process, and not a fun one rly.  If we have newbies voting in screening the votes will not be unanimous like ever, (somewhat experienced or pro: This w/mo lacks offensive power due to rediculous waste of energy in healing.  Newb: but heal party is the vbest skill eva!!!!!.  Result: Screening completely failed)  Secondly it is faster because screening requires absoutely not testing whatsoever and comments may be made in a few words(e.g. lacks offensive power, no res, skills do not work together), it is a couple opinions made by people who are used to devising builds and know what works usually and what is disastrously wrong.  When there is debate, and many many times there will be, it will be transfered to testing. (Not a fifty five 12:47, 8 September 2006 (CDT))


 * This highlights one of the mistakes in thinking of the process as "voting". It should not be a vote. Obviously flawed reasoning during the vetting process should be disregarded. This can be done without denying suffrage to all. zaishen 12:49, 8 September 2006 (CDT)


 * True voting is not the best of systems. It is fast tho, and thats all people are doing atm.  Basically this is how the electoral collage worked in the old days (1700s).  People who were not informed due to lack of phones, tv, newspapers etc. could not reliable vote due to lack of information.  However they WOULD vote on an electoral representative who has agreed that they support the views the a certain nomine.  Locals would know mostly what the representatives know, and can make a good guess as to whether the representative shares most of the views of the president: thus they would inadvertantly vote for the president they belive is right. If you disagree beyond this, then we just have different opinions.  (Not a fifty five 12:57, 8 September 2006 (CDT))


 * And if you still believe this denies suffrage then think about this: would ANYONE trust the ideas of someone who just bought GW that day and has only seen the skills on wiki? I think not. (Not a fifty five 13:01, 8 September 2006 (CDT))


 * I would trust anyone, including someone who doesn't even know the game, to have the ability in principle of pointing out flaws in my reasoning. That being said, the matter here is not of trust. If someone cannot justify their comments in the vetting process, then those comments should be disregarded. The reasoning, not the reasoner, should decide the fate of the nomination/build. zaishen 13:09, 8 September 2006 (CDT)

What about unreasonable reasoning? Who would be the judge of good reasoning and bad reasoning? Even Skuld and Rapta have used bad reasoning in their unfavored voting.-Onlyashadow 13:16, 8 September 2006 (CDT)
 * We don't need judges. If you disagree with someone's "vote", just state your disagreement and engage in a dialogue. If you're right, you will convince the other of the mistakes in his reasoning. zaishen 13:18, 8 September 2006 (CDT)


 * Agree to Zaishen, we really don't need judge or don't want any judge's, Judge will only bring elitism which happened a lot in the PvP community. If it is an obvious unreasonable reasoning, people will state that in the discussion and tell them to review the votes by a good reasoning. Even some newbie may able to provide some thought that people never think of before. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 10:16, 10 September 2006 (CDT)

Shadow's Moved Comments
I like the idea, it would really clean up the untested builds page. If the proposed "screening" process is made policy, I'd like to sign up as a judge. I have plenty of pvp experience although I think the minimum faction req should be raised and require a screenshot for validation.-Onlyashadow 12:30, 8 September 2006 (CDT)

If you think about it, you don't want to be dening this sufferage.Onlyashadow 13:07, 8 September 2006 (CDT)

While this may reduce support for my idea :(, I'll tell you my real opinion. If everyone of the commentors who had 100k bal faction could test at lightning speed and present their results and vote, I would completely disregard anything else said and not bother to read it as "waste of time"(if of course more than 6 votes or so have been made).  I simply believe there are some things the newbies, while clever, will simply not "get".  A good example is parasitic bond.  An intelligent newbie to guild wars will most likely "This skill sucks!!! -1 health regen?! thats nothing!".  They're right about this.  What they wouldn't even think of is that this is, most commonly to by the experienced community, a "cover hex" (Not a fifty five 13:36, 8 September 2006 (CDT))

Proposal: Denote expansions required for build
Hopefully this is on-topic and in the right section, if not you have my IP and can summarily destory my Internet connection. I propose some kind of notation "at a glance" on which expansions are required for a build so that you can tell before clicking into it. At the rate expansions are released it will become increasingly difficult to view builds that are relevant to your expansions. I don't know how this could be better done, I don't know that we need to break out even more sections, but perhaps an icon can be added behind the build name for each expansion required.

On another note. regarding above conversations regarding builds, I think builds are an important aspect of the game in general and I feel guildwiki is a good place for them still. Cheers, Bret.


 * The idea sounds good, but the implementation is hard. It could be done by changing the names of builds, but that would be cumbersome and lead to very ugly build names. Whether there is any possibility to display icons behind names in categories, I dont know. However, as long as you are interested in builds that only need skills from one expansion, we already have that (Category: Prophecies builds, Category: Factions builds). However if you are looking for something along the lines of "all builds needing expansion 1,2,4,7 NOT 3,5-6", that would make the solution with categories impossible due to the exploding number of categories that would be needed with each expansion. --Xeeron 15:10, 12 September 2006 (CDT)
 * Yep, idea is good, but cumbersome to organise using categories. With just 3 campaigns, we're talking about 7 campaign categories already. With 4 campaigns, it'll be... roughly 15 categories. And it just explodes from there. A quick reference page is another idea. But with the rate of new builds being created, tested, and changed, it'll be too difficult to manually keep track of them all. How about instead of Category:Multi-campaign builds, we can have something like "Category:Two-campaign builds", Category:Three-campaign builds", etc. to help narrow things down and makes it slightly easier to browse. --Ab.Er.Rant (msg Aberrant80) 01:09, 13 September 2006 (CDT)

New Subcats
There are an increasing number of builds which contain certain key concepts (MM's, 55ers, Spirit Bonders, Bonders) all spring to mind. (I tend to play monk I'm sure there are many other examples).I feel that creating cat's for such key concepts or an obvious way of checking for builds with a perticular skill would help in a number of ways. (At the moment I end up checking to see what a skills icon has been used in).


 * The increasing number of builds makes it hard to check for simular builds this would help contributers search to see if "it's already been done" as it were.
 * Non contributers would also benifit from making build finding easier.
 * Easier to compare with other builds for assesment. How "good" is a build I don't currently rate builds as I have no easy way of finding builds to compare it with. --JP 07:19, 13 September 2006 (CDT)


 * While we can certainly try to come up with conceptual categories for builds, it is somewhat useless, and not as beneficial as you might think.
 * First, there are a lot more builds that do not easily fit into conceptual categories, which you would then have to lump into a "others" category.
 * Second, ppl looking for builds usually browse via purpose (farming, pve, pvp, ra, ha, etc.) and not concept.
 * Third, by breaking in concepts, it doesn't necessarily make it easier for ppl to find similar builds before submitting. They might not know what concept their build fits into. Searching just the existing tested, untested, and unfavored build categories is enough to show what's already available. What's more important is to get the builds renamed more intuitively. --Ab.Er.Rant (msg Aberrant80) 08:07, 13 September 2006 (CDT)
 * I do not envisage the majority of builds fitting into these catagorise. It would just be a way of grouping related builds that were too disimular to be classed as varients but still "belong together" due to the core concepts involved. --JP 08:24, 13 September 2006 (CDT)
 * Then it'll just mean that you'll be introducing a handful of categories that will at most contain a handful of builds. While it's certainly do-able, I just don't see it as necessary, yet. --Ab.Er.Rant (msg Aberrant80) 09:35, 13 September 2006 (CDT)


 * "Necessary" is not a condition that needs to be met. Further, no "Others" category needs to exist, either. You can very easily make categories for certain well-defined build archetypes and slap them on all the builds that fit that archetype. Some builds might fit in none of these categories. Some might fit in many. It's a great idea that requires no discussion, because it does not change the current status quo within the builds portal&mdash;just do it. &mdash;Tanaric 12:40, 13 September 2006 (CDT)

The issue at hand
At some time after the builds section took off on the wiki a non-formalised vetting procedure was implemented, working with the current structure of builds:
 * Category:Build stubs - unfinished builds
 * Category:Untested builds - finished builds without community verdict
 * Category:Tested builds - finished builds with positive community verdict
 * Category:Unfavored builds - finished builds with negative community verdict

The vetting process in action up till now includes positive and negative votes on builds, however there was no formalised policy on the number of votes needed for moving builds, the possible end date of votes and the way in which votes should be cast.

In the last weeks, a huge and sprawling discussion started about the validity of that process. Several proposals have been made and discussions currently take place on a number of talk pages (this page, Talk:Builds, GuildWiki talk:Style and formatting/Builds, GuildWiki talk:Requests for arbitration/Not a fifty five vs Karlos among others). The discussion has been intense, sometimes too intense. However, up till now, no consensus on the future of builds on this wiki has been reached. In an effort to bring the different strings of discussions together, I will try to summarise previous proposals here and ask everyone to restart the discussion here, since this seems to be the most fitting place for discussion.

What is needed
The wiki needs a policy to deal with builds on the wiki. Especially, the policy should describe a way to deal with the not objectivly verifiable quality of builds, which differs from most other (objectively verifiable) articles on the wiki. The policy should describe how and by whom builds are evaluated and in which form and structure they will be presented to the users of the wiki. Some goals to keep in mind are: Not all these goals will be rated as equally important by all participants, but discussion of different proposals should keep these goals in mind when comparing different policies.
 * Secure the quality of "approved" builds
 * Saveguard against unjustified "disapprovement" of builds
 * Producing a sufficient amount of rated builds for the users of the wiki to browse
 * Keeping workload at a level that can be shouldered by those willing to test builds
 * Keep the builds section in line with the general spirit of articles in other parts of the wiki

Updated build voting
(From: Builds)

A refinement of the current procedure. Testers are called upon not to cast hasty votes and explain their vote. A formal way of moving builds is introduced: 3 more positive votes than negative ones are needed to move a build into tested, 3 more negative votes than positive ones are needed to move a build into unfavored. Voting is never closed and builds can be switched from one to the other category if a sufficient number of votes is cast.

Give builds marks out of 10
(From: This talk page/not a direct proposal yet) Instead of a simple "Favored" or "Unfavored", Maybe this wiki could display the current average marks. This would allow for a less "absolute" good/bad build situation. It would also highlight the really useful builds. --JP 07:19, 13 September 2006 (CDT)

Featured builds
(From: This talk page, Featured build criteria, Featured build candidate)

A process similar to wikipedias featured articles is implemented. All finished builds start out in untested. Builds in untested can be nominated for featured status. Nominations will be discussed in a central location (Featured build candidate) so it is always clear which builds are currently under consideration for featured status. Nominations will be discussed for 1 week and, if consensus (= supermajority) supports the nomination, then it is featured. If there is no consensus to support, the build is returned to unfavored. In opposing a nomination, each opposing comment must give specific addressable criteria for improvement. Once these criteria are addressed, a build may be renominated.

Note: this process does not specify how to move builds from untested to unfavored. A process entirely separate from featured nomination should address this movement.

To see examples of this proposal in action, see:
 * A/E Knock it Off (nom)
 * R/A Lunge as One (nom)

Refined double stage screening
(From: This talk page)

A second stage of build rating is introduced. All builds in untested are subjected to a "screening" process. In this screening process, fast votes are cast without actual testing of the build. The group of people doing screening should be limited to very experienced players. If screening is unanimous, builds are directly placed into tested or unfavored. If screening is not unanimous, the build is refered to the second stage of testing. There everyone is called upon to cast votes, however this time with proper in-game testing and comments along with the vote.

Unrefined double stage screening
(From: This talk page/not a direct proposal yet)

Like refined double stage screening. However, everyone is encouraged to take part in the first stage "screening". Furthermore, all builds without a supermajority against them are placed in what is now "untested" and subjected to the testing process of the second stage. Builds with a supermajority agains them in the first stage of screening are placed in unfavored.

Challenges
(From: Talk:Builds)

Instead of ongoing voting, to move a build from either tested/unfavored into the other category, a challenge would be called. Thereafter the challenger take the build in question into battle versus another buil (yet to be described how this build is chosen). The result of the battle of these 2 builds decides the category.

Unrefined double stage screening, version 2

 * 1) We can create a new Category, lets call it Nominated builds as for now, im not good at naming thing.
 * 2) * Category: Nominated builds
 * 3) New build started at Unstubed builds if unfinished or Untested builds if it is finished and ready for nominated for testing purpose.
 * 4) Untested builds will then move to Nominted builds when people nopminate it for testing. Anyone can nominate a build for testing other than the build creator or submitter.
 * 5) *A Untested build is moved to Nominated builds IFF the 3 person nominate the build.
 * 6) **Undecided whether unregister user can nominate a build.
 * 7) If an Untested builds is Nominated, it will have a Nominated tag with a date stamp on it. And we will use the normal Voting Process, Favoured, Unfavoured or Need Work.
 * 8) *Featured build will move to Tested with ACTUAL TESTING on PURPOSE AREA(PvE, PvP) and FAVOURED. Some build will be harder to test, such as the team build for HA, etc. But, please test it. Comments are Explanation are Recommended.
 * 9) *Featured build will move back to Untested after 1* month of Nomination AND < 3* votes(both positive and negative). Or 2* months after nomination. Or if people vote Need Work, the usual Voting rule applied, eg. 3 votes > Favoured votes and 3 votes > Unfavoured Votes. So 4 votes on Need Work and 1 vote on Favoured and 1 vote on Unfavoured will move it back to Untested.
 * 10) * *The number can be alter through discussion.
 * 11) *Featured build will move to Unfavoured with ACTUAL TESTING on PURPOSE AREA(PvE, PvP) and UNFAVOURED. Comments and Explanation are NEEDED.

Notes:

Builds in Tested and Unfavoured that is moved from nominated builds for more than 1 month can also be nominate to Nominated Build when 3 person nominate it with Explained reason on why it is need to be re-voted. So, consider the votes end after 1 month of successful move.

Between last significant vote and Moving Nominated builds to any category should be more than 24 hours. So that people can still votes. Votes after that moved should explained clearly on said vote(not for the late vote, but why the vote is placed) and the build should moved accordinly.


 * "Nominated builds" is likely better than "Featured builds", since it's all about nomination anyway. Overall, I support this proposal, just some trivial disagreement on some of the numbers. But in addition, I propose (as gr3g mentioned before) renaming "Tested builds" to either "Favored builds" or "Viable builds", to make it less forceful and the guaranteed-to-work implication. --Ab.Er.Rant (msg Aberrant80) 08:07, 13 September 2006 (CDT)

Complete removal of builds from the wiki I
(From: Talk:Builds)

Builds are completely removed from the wiki and placed in a yet to be made BuildWiki. No suggestion on how build evaluation would be done there yet.

Complete removal of builds from the wiki II
(From: Talk:Builds)

Builds will be removed from the wiki, and dealt with in a yet to specify non-wiki project.

Treat builds like normal wiki articles
(From: GuildWiki talk:Style and formatting/Builds)

Treat builds like normal wiki articles. That includes immediate placement of delete tags on builds regarded as bad (and discussion of this on the talk page), and moving to categories according to consensus on the talk page. No voting takes place.

Two Category System
Under this system, there will be only two categories: Tested and Untested. Votes are very simple; they only vote for tested and viable. A consensus of three votes (author votes are excluded) is needed to move the build into Tested by a person who has neither voted for the build, nor is the author of the build.

Otherwise, some discussion should take place in order to improve the build or point out flaws. Votes can be removed by the voter any time the build changes during this period. However, if no discussions have taken place on a build in a period of two weeks, then the build shall be marked for deletion with a date set an additional two weeks afterwards. The deletion tag can be removed as per normal discussion of the merits of the article.

This addresses several things: speed in which Tested builds are brought into the limelight, unhelpful vote comments, unusable builds wasting away indefinately, and keeping the Untested category pruned of dead, untested builds. If a person does not like a build, he doesn't have to lift a finger; if this opinion is shared by the community, the build will die on its own under this system.

If I forgot a proposal or wrongly summarised one, please add/correct it here.

Discussion
''Please keep the discussion both civil and focused on the future of the builds policy here. Idealy point out advantages and disadvantages of the proposals and explain why you favor one of them/how advantages of several proposals can be combined.''

Vote quality

I think we need to have a minimum quality of writing requred for a vote to count. Unless it clearly addresses what is wrong/good with the build, a vote should be deleted by the author. There are too many unfavored votes that resort to sarcasm or ignorance. This usually happens when the author has used underrated skills effectively, or a combination of skills that a contributor seems biased against. It is especially common in votes where the voter has not tested the build in-game.

Here are two good examples from a single page alone. Mo/A Enchantment Keeper is the page in question.

"Bad (even more likely LETHAL) rune spread. — Rapta (talk|contribs) 00:09, 20 August 2006 (CDT)"
 * The build is not designed to go anywhere near combat, but stays well out of aggro range and just maintains the enchantments on a farming character. Therefore defense is not an issue. If you had to defend, you would already have failed by being close enough to be aggroed.

"how many bonds can you line up on a single bar? --Honorable Sarah 12:41, 24 August 2006 (CDT)"
 * The point of the build is merely to support a farmer with maintained enchants without any active involvement throughout the fight. Criticising a build simply for using a lot of maintained spells is not logical. Again, there is no reason given as to why this strategy would be ineffective.

Labmonkey 10:00, 13 September 2006 (CDT)


 * I think it's a tricky business voting. Who's to say whether a comment is valid enough?


 * Personally I think having a featured article system might be best. We could even try and do more than one at a time. For example, if 5 builds were taken from "untested", nominated for a week, and those that received enough feedback moved to the appropriate category, it might take longer than our current system but I think it would produce good results.  &lt;LordBiro&gt;/&lt;Talk&gt; 10:23, 13 September 2006 (CDT)


 * I have to admit, that i used sarcasm for voting too. When i started to test and vote builds, i took my time to write a few sentences why the current build is good or bad. If the build is really bad, this means more then one sentence. Often, you have to explain, why a certain combination of skills doesn't work (5-15 minutes, if you are not a native english speaker). Then the following things happend. The author reacted and we had a discussion or no reaction at all. The number of builds with the second case grew and grew. Builds were abandoned, no solutions. So i saw myself wasting my time more and more. Sarcastic votes were my answer, not for long, i stopped it. The worse a build was, the smaller was my motivation to write something informative (and probably waste my time). Then there were other builds. Most Blood Magic Builds are a good examples. The author took 4-6 Blood Magic Skills and submitted a build. They had no synergy effects. You could arbitrary replace 3-5 skills, without changing the whole intention of the build. These "builds" are, in my opinion, not worth to keep. I illustrated my opinion to those builds with sarcasm. Are those builds worth keeping? Honorable Sarahs comment on the Mo/A Enchantment Keeper hit the nail on the head. Do we need an article for a build which a logical thinking gw player would develop in 10 seconds? This was one of the builds, where i just thought, if you don't have anything good to say, you better say nothing. I'm quite sure, many continuous tester experience the same. Back to topic, why should an author (favoured vote) have the power to replace unfavoured votes, no matter what kind of votes those are?--Nemren 11:05, 13 September 2006 (CDT)

I ma personally in favor of Unrefined double stage screening with the added option to discuss and tell your opinnions in the first stage too. -- (talk) 14:47, 13 September 2006 (CDT)

Ok, I tried to formulate the above summaries as neutral as possible, so lets try to wrap it all up and give my personal opinion.

First of all, I feel that the biggest alienation of users has been due to votes that were cast without properly checking and understanding the build in question. I am definitly one of those to blame there as well. Votes cast at a glance, without any comment at all, or even ridiculing the build, lead to much grief by those submitting builds (and others reading the talk pages). Almost all of the above mentioned proposals try to deal with that problem. Even more important, the one of the benefits of the long discussion is that it made everyone realise how important proper voting is. Hopefully, that alone will help the builds vetting to be less ridden with conflicts in the future. That leaves the issue of which way to formalise the vetting process. For me three procedures seem to practicable: Updated build voting, Unrefined double stage screening and Two Category System.
 * The first has the advantage of being very easily implemented. There is few to know about the process and no need for any "uber" group to stand in the background and lead the process, all steps (adding the voting list, voting, moving a build once enough votes are present) can be done even by very new wiki users. The main disadvantage is the psychological pressure on the testers to "keep the untested category small" which has in the past lead to votes that were cast without properly testing of the build.
 * The second has a very interesting way of dealing with the conflict between complete testing and getting rid of very bad builds fast. By creating a first stage that is exlusively designed to filter out extremly bad builds (while the difference between merely bad builds and good builds will be established in the second stage), it should encourage very thorough testing in the second stage. Of course that implies that the first stage will be over very quickly and it will be hard to find the balance between letting too many builds get past this (making the first stage redundant) and axing too many (making the current problems worse). However, it should work very well if that balance can be found. Another problem is the added complexity in terms of administration by introducing 2 different votes per build. Moving builds from stage 1 to stage 2 would have to be done by people with complete knowledge of the build process, since the old vote needs to be archived and a new vote section set up.
 * The two category system has the easiest system of the three, even very new editors should immediatly understand it. It also does a great job of making comments on negative votes being unnecessary by doing fully away with negative votes. The main problem is that this needs a very hands-on approach of always monitoring new builds. The task of keeping track of the dates for all new builds will definitly a big one. Additionally, this can create quite a big pressure to test builds. The frustration of authors who dont see any negative feedback, yet are not seeing any positive votes either might be considerable.

Let me quickly explain why I dont feel the other proposals would work: Removing builds from the wiki would be a last resort. Builds are a popular feature and we should not think about removing them unless the situation becomes totally stuck and there is no other way out. Treating them like normal wiki article would create additinal work, since sooner or later we would have to redo the debate we are having just right now on each contested builds article. The refined double screening is just to elitist for me, challenges are outright impractical for almost all builds and while giving marks is a nice idea, but is extremely hard to implement technically in a wiki (I will definitly not be the one doing all the calculations by hand) and it still does not solve the problems of voting without consideration and builds sitting without being tested. The one proposal which I did not include in my 3 above which did receive some support from other is the featured builds one. The featured build process on wikipedia works well, but dont forget that they have a wastly bigger group of users who have the task of selecting one article per day. We on the other hand have a much smaller user base but want to (ideally) test all builds (about 4 new ones per day). The procedure would result in an extreme overload, leading to a situation where only a tiny percentage of builds gets discussed at all. And all proponents of featured builds, please dont forget, we alread have a featured build! If anyone wants to, the featured build procedure can easily be used to determine this featured build (however, so far almost noone has shown any interest in this, despite the fact that basically nothing apart from choosing a random tested build is required at the moment, the featured build sometimes does not change for weeks).

So to sum up, I would be happy with either Updated build voting, Unrefined double stage screening or Two Category System. Having to choose one of the three I maybe would still go with updated build voting, simply because it needs the least amount of administrative work. --Xeeron 14:50, 13 September 2006 (CDT)


 * I'm thinking almost as Xeeron, but I do not like the Two Category System. Bad builds are not handeled quickly and builds might not get feedback as much as they should. A few ignorant users could cause bad builds to be moved to tested as no negative votes can be made. Of the two others I prefer, Unrefined double stage screening as I mentioned before, but updated build voting could be okay too. --[[Image:Gem-icon-sm.png]] (talk) 15:10, 13 September 2006 (CDT)


 * I am personally in favour of the "featured article" system. I'm not opposed to the "double stage screening" system, but I would preferably like to have some sort of compromise between the two. Perhaps that's not possible, I'm not sure.


 * One thing you say that I don't agree with, Xeeron, is that we need to get through 4 builds per day. I know that's not a precise figure, but I don't agree that we need to get through a certain quota.  &lt;LordBiro&gt;/&lt;Talk&gt; 15:35, 13 September 2006 (CDT)

Ratification of this proposed policy
I believe this policy, as it stands, should be accepted into the GuildWiki policy base, as it represents the current build vetting policy completely. We can propose and discuss changes afterward. &mdash;Tanaric 12:43, 13 September 2006 (CDT)


 * Fair point and agreed.  &lt;LordBiro&gt;/&lt;Talk&gt; 13:10, 13 September 2006 (CDT)