Talk: Builds/Archive

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) — Skuld 08:25, 2 September 2006 (CDT)

Moving this to GuildWiki:Builds. By definition, everything in the GuildWiki namespace pertains to things on the wiki. :) —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 [[:Category:Untested builds|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.

—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 :) <LordBiro>/<Talk> 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—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—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.

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

If we really can move the builds out of the wiki onto a different wiki-based publishing portal, that would be very cool. Very, very cool. ~ Nilles (chat) 02:09, 27 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:

• "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.

(Below these are the unfavored, archived, etc.)

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. -- 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. -- 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. -- 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:

• GuildWiki:Featured build candidate
• [GuildWiki:Featured build criteria]

These are tagged with {{unfinished}} 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)

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. :) —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#Vetting_categories_are_badly_named 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. <LordBiro>/<Talk> 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).

• [Build:A/E Knock it Off]
• [Build:R/A Lunge as One]

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)

Compromise

← Moved from Talk:Builds#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. <s&amp;amp;gt;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. -- 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

← Moved from Talk:Builds#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—just do it. —Tanaric 12:40, 13 September 2006 (CDT)

Unified discussion on future builds policy

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:

• 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

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.

The different proposals

Updated build voting

(From: GuildWiki: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, [GuildWiki:Featured build criteria], GuildWiki: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 (GuildWiki: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 untested. 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.

Note: A mock up has been called to see if we even have enough screeners for this to function here. Please sign up if you want to be a screener, even if you would vote for another policy instead of this.

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.
   • [:Category: Nominated builds]
2. New build started at Unstubed builds if unfinished or Untested builds if it is finished and ready for nominated for testing purpose.
3. 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.
   • A Untested build is moved to Nominated builds IFF the 3 person nominate the build.
     • Undecided whether unregister user can nominate a build.
4. 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.
   • 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.
   • 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.
   • *The number can be alter through discussion.
   • 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. <LordBiro>/<Talk> 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)

This was left out of the summary for space's sake, but that's part of the policy rly, one must make a comment. Except terse comments like "lacks sufficient self heal" etc are quite acceptable. (Not a fifty five 18:30, 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. -- (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. <LordBiro>/<Talk> 15:35, 13 September 2006 (CDT)

Just to clarify: I was saying we get about 4 totally new builds created each day. --Xeeron 17:21, 13 September 2006 (CDT)

Heya, my comments on each of the polices:

• Updated:Not Good. Better than the current way things are done :) But unfortunately slower, and I must admit those builds are starting to come in mighty fast.
  
• 1-10 Scale:3. Fun idea, but only solves the dillemma of untested builds being "dead" Maybe it can be used combined with some proposal.
• Featured:Not Good. Also nice idea, but as stated the untested would become huuuuge. Rushing categories aside, the problem with untested getting huge is for a person to simply find a build to nominate!
• Refined double staged screening:Good (What'd you expect, it's my idea :P) I like this idea because it filters out extremely bad builds or extremely good builds so we don't need to bother testing those, leaving testing for the debatable builds. The reason I believe the experience is needed for screening is that it'll be hard to get a unanimous vote with a mixed experienced crowd. The vote limit could thus be set to 3 or 4 unanimous votes, rather than, say, 5 or 6 votes for supermajority in mixed crowd.
• Unrefined coudle staged screening:Good. I can see the other side of the coin, that denying voting rights is against the wiki community ideal. However, the point of the screening is only to filter very bad and very good builds out, something better done better people who already know what works and doesn't work in their experience (e.g. a monk build for RA that focuses on healing others more than oneself. An experienced player knows monks get the stuffing beaten out of them first and need self protection). A newbie simply doesn't have this experience. However newbies can easily test a build, for they will follow the usage section and their own judgement, something everyone has in varied quality.
• Challenges: I wrote it at 2 A.M. >.< Works very good for team builds prolly! Too bad they are like 3% of builds out there.
• Removals:In the end a good idea, but why bother? too much work :P
• Two category:Good Idea. I think, however, that this would be more like an "add on". Perhaps use karlos' idea, if an unfavored build is in unfavored for x time, it enters build graveyard, where the builds cannot be moved. Part of this could be added to any idea, and, if combined WHOLE with nomination, may end up being pretty useful in getting "rid" of the uninteresting unfavored builds.

:) (Not a fifty five 16:54, 13 September 2006 (CDT))

Arbitrary section break

I have yet to see a good argument for why the untested category must be whittled down into tested or unfavored as fast as possible. Why is there this sense of urgency? Is it because you fear that good builds will get lost in the noise? If so, make an effort to patrol new builds to speedily nominate builds that are obviously good. Or have some trust in your fellow editors who might just be bored enough to go through every build article once in a while to find good builds to nominate. Or trust that the author of such an obviously good build would solicit the nominations. You don't really have a choice except to have a little faith in others because your time and patience isn't infinite. About the screening suggestions, I claim that any policy that depends on a couple or a few editors putting in a disproportionate amount of work in the wiki is ipso facto flawed -- unless these people are paid for their service. What happens if one of them goes on a break? Or goes rogue? How are these people selected? (Why is the selection process fair?) Who has oversight? These questions must be carefully answered before any screeners are nominated. The purpose of a policy discussion should be to form sustainable self-regulating frameworks, not to form committees. Therefore, I suggest that more effort be put into formulating [GuildWiki:Featured build criteria|good build article criteria] than in determining who or how to select good builds. Ideally, one should be able to say, objectively, that a build fits the criteria for good build articles, rather than to say, subjectively, that this build does or does not work. And yes, one of the criteria for a good build article should be that the build is testably valid and viable. 66.90.73.113 17:48, 13 September 2006 (CDT)

Thats why peopel suggest Unrefined double stage screening, So that every one can screen instead of a set group of people. The reason we want to deal with build asap is because there are 4-5 builds per day but only a few will be vetted or unfavoured per week, If that carry on, we would have a list of 1000000+ builds in Untested in no time, a bit exaggerate, but you get what i mean. I still think that builds that stay in Untested for more than 4 months and still no discussion should be delete or moved to a graveyard cat. -- Cwingnam2000 18:01, 13 September 2006 (CDT)

Sorry, I seriously doubt we will be crossing the million build mark any time soon. I doubt we will reach even 0.1% of that. I am much more worried about bad (and badly written) builds making it into tested and good builds being unfairly sent to unfavored than about the larger number of meh builds that no one cares about. A hastily made bad decision is several times worse than no decision at all. Screening does not address this, as it is yet another means of making snap judgment calls. We can independently adopt both a featured build process and Karlos's graveyard idea or Greven's deletion idea for builds on which discussion is dead. 66.90.73.113 18:08, 13 September 2006 (CDT)

Btw, this is not really an article on how to write a good build. Rather try [GuildWiki:Written build evaluation|that] one. Even that is not perfect and I wanted to rewrite it for a bit, but other things first. Your above post repeats an arguement that has been brought forward at least 10 times in various threads so far, please read the goals I stated at the beginning of the whole discussion. Noone ever said that the untested category must be whittled down into tested or unfavored as fast as possible, but speed of the process is not a non-issue. You reminded me of Karlos proposal, which I missed when writing the summaries, I'll try to dig it up tomorrow. --Xeeron 18:14, 13 September 2006 (CDT)

The screening ideas are predicated on quickly sifting builds. I am opposed to quick decisions, especially decisions made by self-styled committees. I don't agree with your dictum at the top of the "Discussions" section. It just moves the hastiness in decision making to the level of policy making. We need to first decide what the purpose of the untested builds category is. If it is to be a repository of unexamined builds, a queue to be cleared by an assembly line of testers, a dumping ground for builds that no one can make up their minds about, or what? Answer this before enacting policies. 66.90.73.113 18:21, 13 September 2006 (CDT)

Well he was exaggerating a bit (wow people are talking fast, anywyas this is replied to zaishen's other reply), but remember there's going to be a bunch of sequals to Guild Wars. In a year or two I rly wouldn't be surprised if there would be 1000 builds or so (w/o exaggeration), which we simply cannot sift through in the nomination feature's untested hoard. Like cwingham said, if perhaps untested would eventually expire into a "graveyard" after a certain time, nomination might be pretty good. But even then, anyone would agree that the graveyard would require about 2 months some say even 4, of inactivity, in which case untested would still reach 200+ at any given time.

Having 200+ in unfavored/tested isn't so bad, though, since one is usually looking for a build by class for tested. And in unfavored, rly who cares about it?(Not a fifty five 18:23, 13 September 2006 (CDT))

Once again, I beg you to stop saying that "we cannot do X" before arguing why the X must be done. 66.90.73.113 18:26, 13 September 2006 (CDT)

In the nomination, I hardly think it would be practical to have to sift through very large amounts of untested builds to make a nomination. Some will get completely ignored by the time a sequal comes out, in which case they may even be obsolete. Thus, time is, at least to some extent, an issue. (Not a fifty five 18:36, 13 September 2006 (CDT))

That is only a concern if you feel that anyone wishing to nominate a build must first search through the entire untested category. But that is not necessarily the best way. One might, for example, limit oneself to just the assassin builds as I have been doing for the past month. Or just builds that use a specific skill such as Blessed Light (which you can discover from Special:Whatlinkshere/Blessed Light). Or builds written by a particular author. Whatever interests you. The moment it stops being a fun exploration of ideas and starts becoming "work" (and sitting at the screening booth stamping "valid" or "invalid" on every incoming build is pure drudgework), the process stops being a quest for quality and becomes process for the sake of it. 66.90.73.113 18:43, 13 September 2006 (CDT)

I don't understand. How is the build voting becoming work in the unrefined version? The refined version is flawed and we will probably not nominate any testers to do the job. Everyone can just vote for any builds that they feel that they know. After a build is deemed okay by the voting process we can start refining it with discussion. This process isn't getting rid of good builds as a significant majority is needed to delete a build. If some people disagree, the build can't be deleted. -- (talk) 01:01, 14 September 2006 (CDT)

I can tell you why I dislike your idea: It will mean that about 5% of builds get proper testing, while 95% of all authors efforts to provide something for the wiki (no matter if the build is good or bad) will be totally wasted, simply because they sit in untested till they are finally deleted due to inactivity. That is why we should try to "do X". --Xeeron 04:36, 14 September 2006 (CDT)

Edit conflict :(

I don't think 66.90.73.113 was quite saying that, Gem. I would much rather have a system of nomination than a system of outright voting on whatever article you'd like.

I think that if we limited the number of nominations, so there were only a certain number at most on the nominations page at any one time, and each nomination had a time period over which it would be judged (something like a week or even longer) then those interested in helping in the build process could try out 1 or several of the nominated builds each week and we could focus discussion on these builds.

I know that I have sometimes thought I would help out with the builds process, but I have been completely turned off by the whole thing.

Since I'm a PvP player, I would be much more keen on going to a nomination page, finding a build that interests me, spending a few days buying any skills that I might not have and then trying it out and giving my opinion. I'm certain my guild-mates, who also play PvP with me, would be more keen on this method.

I'm not going to be very keen on any method that uses voting as its main form of evaluation. I think voting is flawed. I don't think we will ever be able to confirm which votes have valid reasons behind them and which don't, and even if they don't have valid reasons, should we be demanding a comment? When you vote for a government you're not asked to give a reason.

Overall, I feel I would be much more keen on becoming involved in the system if we were to use nominations and not voting, and if we were to take our time discussing builds rather than feeling we have to rush through them. <LordBiro>/<Talk> 04:43, 14 September 2006 (CDT)

[GuildWiki:We are not the government]. There are reasons why the government does not ask you to comment on your vote, but most of these do not apply here. Neither do we have to deal with millions of votes, nor do we need to bother about non-anonymous voting. It is not to much to ask people to quickly write down why they were voting the way they did vote.

Of course I do like your way of testing best. Take a nominated build, look at it for several days, play it in different scenarios, work on different skill setups. And have that done by several people at once who are engaged in a long discussion. But please tell me a guess of how many builds you usually evaluate in 1 week? Of course your method of vetting would lead to some builds being tested very thoroughly. With the current number of testers it might be 5% of them and that is a high estimate. So you are basically telling 95% of the authors of new builds: "Thanks for all the work, but sorry we dont care about your effort. Your build will be deleted in a few months without having been looked at". Unless proponents of the nomination proposal are willing to step forward and tell me with a straight face that they accept that fact as a necessary evil, I will not be convinced that you gave all goals listed above proper thought. --Xeeron 07:09, 14 September 2006 (CDT)

I'm just after a system to make people take their time. Some builds are submitted that are ridiculous and nobody cares about. So leave it that way. It needs to be easier to move up a build that people use and that works. I'd go for the 2-category system. People will always disagree on a strategy, but if 50% of people like a build, they'll be the ones that use it well. If you don't like it, you'll ignore it.Labmonkey 05:53, 14 September 2006 (CDT)

As I said further up, Gem, I'm not opposed to filtering out bad builds first, even though I'm not that keen on the idea of using voting. A compromise between the nomination system and the 2 stage wotsit would be fine by me. <LordBiro>/<Talk> 06:03, 14 September 2006 (CDT)

I'm kind of against voting because it deadlocks controversial builds. You might not have a majority, but if a lot of people like a build, that should be enough. Some builds get voted down because people don't like the style of play you need to use with them. In that case they should just accept it's not for them, rather than railing against it.Labmonkey 06:08, 14 September 2006 (CDT)

Wasn't the point of the unrefined system that the inital vote just takes care of the totally crappy builds. After the vote those which aren't deleted are evolved by disussion and testing. -- (talk) 04:55, 14 September 2006 (CDT)

I hate posting out of order, so this is in reply to Xeeron's comment a little further up.

I think people should be allowed to vote for or against a build for any reason, and they shouldn't have to explain themselves to us. I don't think it's our place to ask users to give us a reason, and I think it would be impossible to come up with a definite criteria as to what constitutes a useful comment. If I was to vote with the comment "too many enchantments" or something, what does that actually mean? Should the vote be allowed or not? Some will say yes and some will say no.

To put this another way, I think that either people should be able to vote without giving a comment or we should encourage a system of discussion without voting.

I doubt that only 5% of the builds would be nominated. If we could handle more than X number of builds in a week and still give each build a fair trial then we could double X.

At the moment I evaluate no builds, so there's a fairly accurate estimate :P I would be more inclined to help with the evaluation process if I knew I had a certain amount of time (a week for example) in order to test a build and give my feedback. At present I don't have any urge to help out. I'll occasionally try an untested build, but often by the time I've tried it it's been moved already. <LordBiro>/<Talk> 07:46, 14 September 2006 (CDT)

Xeeron: I can tell you why I dislike your idea: It will mean that about 5% of builds get proper testing, while 95% of all authors efforts to provide something for the wiki (no matter if the build is good or bad) will be totally wasted

You are still arguing that every incoming build ever must immediately receive the full attention of the community. Why? And I don't agree with your 5/95 figure. There is no reason why nomination cannot handle every incoming build if necessary. What nomination forces, however, is standards; and what nomination prevents, most importantly, is premature voting. I think it is very important to realize that when someone submits a new build article, it is generally in no shape to be given a thumbs up or down, even a preliminary one. The first order of business should be to test, not to vote. I would argue that voting should be reserved for the crème de la crème of builds. With regard to your claim that the author's effort is wasted: again, I don't agree. If someone writes a build, eventually someone else, maybe even someone who patrols new builds, will read it and the process will begin. The author can even be proactive if he wants his build to be nominated; he should firstly put in the requisite effort in making the builds conform to GW:BUILD and GW:WBE, then solicit comments from testers, then, if the testers leave generally positive feedback, finally solicit a nomination. If the build is solid, this process will happen veyr quickly. If the build needs work, then it will be slower, with hopefully more active discussion. If the build is not particularly novel, the discussion will make this clear based on which the initial author of the build might be convinced to merge it into the variants section of some other build. In cases where the build just sucks, the discussion will bring out the major flaws and the community can decide, independently of any votes, to simply delete the build. This already happens to a degree, as I have seen Skuld delete obviously bad builds (eg. W/Mo Holy Swordsman) speedily. And I commend him for doiing it. The important thing---and though I keep repeating this I fear that the point is being repeatedly missed---is that at no stage in this process is the general community voting on an unfinished product. 66.90.73.113 08:22, 14 September 2006 (CDT)

This in reply to LordBiro and 66.90.73.113.

Please dont missquote me. I never said that all builds must immediately receive full attention. Instead I pointed out that having a process that enables us to test more builds (everything else equal) is better. If all builds can be tested, perfect. If only very few builds can be tested, bad. You both doubt my number of 5%, which is fine, since I pulled that one out of the air. However I did not pull it out of nothing. Maybe the true number is 7.35%, maybe it is 3.56%, maybe we will have a huge boost in activity and it will be 14.98%. But with having a very good knowledge of how many new builds arrive here, how long testing takes and how many people are active on the wiki, I can guarantee you that both of your procedures will fall short by far of even reaching one third of all new builds. "If the build needs work, then it will be slower, with hopefully more active discussion." is plain wrong. Look at the history of many older builds and you will see that without voting, builds sat around with 0 discussion, 0 testing, 0 attention for months and months. And that was at a time when the number of builds was maybe 10% of what we have now, both in terms of total builds and inflow.

You both make it look like voting excludes discussion and testing, without having taken a big part in the voting process so far. While sometimes voting without discussion takes place, that is not the overwhelming number of cases. And that was before we wrote a policy draft encouraging people to explain their votes (And yes, I do think we can ask people to explain the votes. We can not force them, but neither can we force them to assume good faith, or follow any similar policy). More often then not people post comments first and only vote later if their comments are ignored, or point out better ways to reach the goal together with their vote. --Xeeron 09:00, 14 September 2006 (CDT)

I don't think the voting system is rubbish Xeeron, for all I have not contributed directly to it I do use builds a great deal and regularly read the discussions on them, as do many of my guild mates, so while I may not be in as experienced a position as yourself (although in this regard few people are) I do have some experience of the build process. I don't want you to think of me as someone coming in and trying to change your good work without fully appreciating the processes already in place. I am aware of the things that you've done to improve the builds section and I admire your commitment to this area of the wiki.

I think voting was the right choice to make when you overhauled the builds section. I don't think anyone can reasonably argue against that. However, at this point I feel strongly that a system of nomination would improve the quality of the build section as a whole, and (avoiding an argument over percantages) I don't think that the number of builds we get through will be as low as you do. <LordBiro>/<Talk> 09:26, 14 September 2006 (CDT)

It wasn't a quote, so it can't have been a misquote. It was, I maintain however, an accurate paraphrase. You repeat again above that you want all builds to be discussed. No objection there! However, the means you use to force this discussion---voting---is flawed. Voting nearly always signals a breakdown of consensus building, and premature voting is contrary to good sense. I am not saying this with no evidence to back me up. Surely you read Greven's post about builds such as [R/A Lunge as One] being unfavored with unjustifiable comments and no testing? Surely you cannot deny that [A/Me Genjutsu Specialist], a bad build (in my opinion, though possibly improvable), was rushed into favored? I blame the rush to vote entirely for the premature misclassification of these builds. Anyway, to ground this discussion in the present reality, I think that what you saw with builds months ago is not necessarily what will be the situation today. We have several people who have expressed interest in the builds section. I think we can be relatively confident now that all builds will be discussed, whatever vetting policy we may eventually adopt. (By the way, I have been participating in the builds process for months, but I have never once voted on a build. All of my edits have been testing and cleanup.) (parts of this comment were in edit conflict and reiterates what LordBiro said above.) 66.90.73.113 09:35, 14 September 2006 (CDT)

It was not an accurate paraphrase (and I'll be careful not to say missquote when I should have said wrongly summarised in the future). You make it look like the speed of the process is the only quality I care about, which is wrong. It is one of the qualities that a vetting process should idealy have. Of course I want all builds to be discussed (do you prefer builds not being discussed to builds being discussed, all other things equal!!??), but that does not mean that this is the only point I look at. However I had the feeling that you are only looking at the other qualities of the process and totally ignoring that one. In the light of your past 2 posts, I might have been wrong: It seems that you dont look at it, because you think that a featured build procedure will manage to look at all builds and therefore you dont see a trade-off. I do believe otherwise, but since we are talking about possible events in the future, I doubt that one of us will manage to convince the other. --Xeeron 09:46, 14 September 2006 (CDT)

PS: Other things where we likely cant get together: You think that the past (without voting procedure) is not representative of the present, since the situation is different. By the same argument, all your examples are void, since the situation in the past (without an established build policy and before this discussion was done) is different from the present where these things happened. I do believe that with the policy described on this article page, such things would be avoided in the future (and similarly with the unrefined dual voting), you dont. And none of us can prove the point. --Xeeron 09:51, 14 September 2006 (CDT)

Well, I remain hopeful that a middle ground between the nomination and the "unrefined screening" ideas can be found. My objection to screening, as should be fairly evident, is based on the principle that voting is evil and premature voting is worse. Principles are not provable or refutable points: you either accept them or you don't. By the way, I think we do agree that discussion and testing should happen; our disagreement is on the means of promoting or demoting builds. I would urge you not to equate discussion and testing with the process used to promote or demote builds. 66.90.73.113 09:58, 14 September 2006 (CDT)

You are perfectly right about the principles (which is why I a bit less hopeful). I have rarely seen any discussion about principles lead anywhere. It is almost like trying to prove god exists: Fun to try, impossible to do. What we disagree about is not only the process of promoting, but the goals that the promoting process should try to achieve, that is the real problem. --Xeeron 10:05, 14 September 2006 (CDT)

PS:How about agreeing to disagree for now and letting the others have their chance of speaking up before we reach 2 pages with just us 2 posting. Of course I'll let you have the last post for here and now =) --Xeeron 10:08, 14 September 2006 (CDT)

Well we've been talking for 2 days and it's been pretty much just me, you, zaishen, biron, and gem >.<. We need a title "Somebody else talk!" Or rather set a few links from talk:builds etc to here. (Not a fifty five 12:31, 14 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. —Tanaric 12:43, 13 September 2006 (CDT)

Fair point and agreed. <LordBiro>/<Talk> 13:10, 13 September 2006 (CDT)

Suggestion From A New User

Hey All, I've been reading guildwiki, especially the builds for quite awhile but have just signed up for an account. It seems like there is a lot of debate about the issue of the untested builds section being so flooded and whether or not reviewers have time to give each one a fair vote. I've also noticed that a lot of the builds in this section are incomplete, abandoned as soon as they are posted, or barely make any sense. What I would suggest to tackle this problem is similar to some previous suggestions but seems more simple. This would be to require builds to be submitted to the build stubs (or another section specifically for this purpose, like "Build Queue"), and then require the builds to be nominated by another user or admin before being moved to untested. The nominator would not have to test the build to see if it will work, or even offer an opinion on whether they think it will be viable, but would just make sure that the build is completed, makes sense (its not based on an inaccurate intepretation of a skill combo for example), and is written in the proper format. If not, put a quick comment to say why the build will not be nominated for testing. It would then be the author's responsibility to bring the article up to standards, and once they do, they could somehow re-request nomination. Nominations should be able to be processed in order as they come in, and shouldn't take very long for an admin to go through. Obviously if you have the testing section and the submitting section both as the same section, on a website that allows anyone to contribute anything, the testers are going to be stressed and overwhelmed. Its a total mess. This will save the testers the time of sorting through half-assed builds, and they can focus on builds that are actually ready for testing. This will also encourage more people to test because the untested section will be less overwhelming and messy. -- BrianG 21:31, 14 September 2006 (CDT)

I like this. It should already be done, maybe with a slight notice to indicate the build is ready for testing from the author. It would be essentially the screening process, without the abuse that could go with it. It could easily fit with my suggestion on how to deal with untested builds, so I support it fully :D

Proposed Order of Operation:

1. Build Stub initially created.
2. Build Stub worked on by author(s).
3. Build Stub author leaves a note on talk page indicating he feels it's finished.
4. Build Stub moved to Untested Build by a non-author who agrees that it's ready for testing, or a comment is left as-is indicating disagreement (however, another non-author could override this) and returns to step two. The only criteria for build-stub not being moved should be the build not conforming to article format standards.
   1. Untested Build is commented on, and may be lightly modified via discussion
   2. Untested Build may then be voted on, with three unique votes being the requirement before it can be moved to Tested Builds
   3. Untested Build can only then be moved by a non-author to Tested Builds, once the vote requirement is met.
5. Build Stub/Untested Build will be flagged for deletion two weeks after the last modified Article or Article Talk date. At this point, it is assumed abandoned, and the Article may not be modified except to remove an improper Delete tag, unless the Article Talk has been modified in which case the Delete tag will be removed.
6. Build Stub/Untested Build will be deleted two weeks after the Delete tag is added, unless the Article Talk has been modified.

That looks a little complicated all spelled out like that, but actually doing should be pretty easy. - Greven 23:17, 14 September 2006 (CDT)

Certainly sounds better than the current system. I'm just a bit worried about step 4, I reckon we want to try an avoid the current arguments between submitters and testers as much as possible, we don't want fighting about getting the build to submission. Basically we want to make our testers job as easy and stressfree as we can and we want it to be easy for build submitters to understand the process and what they need to do. But I like the idea. --Xasxas256 23:49, 14 September 2006 (CDT)

This certainly helps getting rid of some of the half-assed builds, as people would comment during stub stage. I'm not sure if this will help speed things up tho. Admittedly untested will be very small, which is great, except wouldn't the stubs section just then be huge? Anyways I do like the idea :) (Not a fifty five 02:14, 15 September 2006 (CDT))

I like the idea, however I would not be as harsh on unstested builds. Dont delete them after 2 weeks, that gives the testers more time to consider the build. Those in build stubs that are incomplete and abandoned can be deleted (especially since it is very simple avoiding that deletion by nominating the build). --Xeeron 04:08, 15 September 2006 (CDT)

I'm not sure I agree with this idea entirely, I agree that step 4 is a little... messy. I really would like a system that is less vote-oriented, but I think you all know that by now :P

However, I am keen on this almost "assembly line" approach. I think having certain distinct stages is very appealing. <LordBiro>/<Talk> 04:52, 15 September 2006 (CDT)

Any idea that does not amount to voting on builds is acceptable to me. I am not too worried about abandoned builds, or builds that are just of poor quality, but any idea that will guarantee that 1) good builds will not go into unfavored because of the whims of one or two people, and 2) bad and badly written builds will not make it into favored because of rush voting, is as such fine by me. My nomination proposal just has a lot of experimental evidence that it works, as it's essentially the featured article system from Wikipedia. I am not sure how well oiled this pipeline will be, but experience will show if stages need to be added or removed from it. I am categorically opposed to "admins" having final say on builds as per BrianG's suggestion, as admins should administrate users, not content. - zaishen (not logged in) 16:00, 15 September 2006 (CDT)

Thanks Xeeron, I'm glad you are taking my suggestion into consideration. Zaishen, you may have misunderstood my comment, I did say "another user OR admin", as since I'm new here I don't really know which people the admins are. So I provided both options, as a way to say "nominated by whoever you feel appropriate". The important part of the idea is not who does the nomination but the idea of screening the entries for quality from an objective, not subjective, perspective as a way to improve the quality and efficiency of the untested section. Also, I never said admins would have "final say" on a build, so I'd agree with you that this wouldn't be good. I just said that someone would nominate it from an "under construction" section. The issue of how to go from there, untested to favored, is a whole different argument, and I agree its a tricky decision. I don't think I have an easy answer for that problem but some form of voting system seems like an unavoidable situation. At least my suggestion might help get things more organized and with everyone making an effort we can see if the voting system improves. -- BrianG 21:52, 15 September 2006 (CDT)

Ok so far I have heard all sorts of "ok" or "I can live with it", which is definitly more than we had before. Please everyone have a last glance at the current article, unless someone who has not spoken up so far is dead opposed, I'd like to get this implemented, since this is by far the closest we have had to a consensus since the discussion started. --Xeeron 16:15, 15 September 2006 (CDT)

I wouldn't rush anything at the moment Xeeron. BrianG only proposed this yesterday. I appreciate you are anxious to test out this process but it might be best if we wait a few days to see if anyone else has any objections.

I also have to say that I agree with zaishen reject, I hadn't really clicked with the mention of admins. Yeah, I don't think admins should be administrating content here, it should be a contributor nomination, not an admin nomination. <LordBiro>/<Talk> 16:50, 15 September 2006 (CDT)

Well if you look at the start paragraph, I think the whole admin thing is just a mistake in his writing. All he says is "non-author". Later he mentions admins lookng through nominations, I think he just mistakenly believes admins flag for tested/unfavored, he did say he is just signing up for an account (Not a fifty five 16:57, 15 September 2006 (CDT))

Just a clarification: What I wrote in the article says nothing about admins (I dont think he meant that admins should be the only ones to nominate). --Xeeron 17:00, 15 September 2006 (CDT)

Yes thanks guys, you're right. Thats based on my limited knowledge of who admins are, and I didn't mean to specify one way or the other who should do the nominating, whether its "anyone", or an assigned person or persons, or whatever everyone thinks would work. Also its nice to know that a new user can show up and can be heard so easily, definitely makes me feel more comfortable contributing. Thanks. -- BrianG 21:52, 15 September 2006 (CDT)

And yeah, I actually dont agree with the idea, I just said it was cool >.<. The reason is something could easily get rushed into a category, and there is little mention of "unfavored builds". If a builds gets three votes for tested and 9 for unfavored, under the rules as is it would go to tested. Also it doesn't solve at all the tested votes vs terse votes problem, which is one of the main problems up for debate. If we aren't mixing policies (which would be fun but take a while o.O) I would rather take unrefined whole than this policy whole. (Not a fifty five 17:06, 15 September 2006 (CDT))

Not a bad idea so far, its just number 4 sounds a bit messy really, it can lead to a revert war or people argue whether the build is ready for testing or not if done without cares. Having said that, i agree with 55 that this doesn't solve the problem that causing all of these discussing. Its not a bad suggestion, but its just doesn't solve the main problem we had. -- Cwingnam2000 17:10, 15 September 2006 (CDT)

See Biro I am not talking about rushing, but after 2 weeks of discussion, with almost everyone involved having quit already, I fear this will go EXACTLY the way of the legacy article debate. Because that is the small black part of consensus building's soul that noone likes to talk about: If you continue talking and talking, one of 2 things will happen: Either nothing (and the totally botched up current state stays, see legacy) OR everyone gets bored and in the end 2 people implement what they want, because everyone else quit the debate. I have not quit yet, but I have yet to hear one negative comment about the current state of the article (which noone seems to have bothered reading). --Xeeron 18:29, 15 September 2006 (CDT)

2 weeks? Policies have been up for two days >.< Besides, so far I've seen more support for unrefined than this :P If we are going to make a final decision we'll call a vote, I think we've got all the points discussed on each policy(Not a fifty five 01:25, 16 September 2006 (CDT))

Perhaps, Xeeron, to draw attention to the proposal, a notice could be added to the build templates so that users involved with the build will be aware of what is going on here.

I have to say, with regard to actually implementing this policy, I'm not keen on many details of the policy, but I'm going to think about it further before I give another opinion on the matter. <LordBiro>/<Talk> 05:59, 16 September 2006 (CDT)

Time to vote then?

It seems we have everything talked out, wanna start the policy vote tomorrow? (Not a fifty five 21:18, 17 September 2006 (CDT))

I keep reading through the article and it just doesn't seem to be different enough to what we already do. Since I'm not 100% familiar with the builds process, would anyone be willing to make a summary of what will change if we were to start a trial of the new process? <LordBiro>/<Talk> 04:56, 18 September 2006 (CDT)

At the moment we dont have a codified builds policy (which is part of the problem). What is more or less the way we do it now:

• New build gets posted into untested
• Someone puts up a rate-a-build on the talk page
• discussion/voting, refinement of the build
• Sooner or later, the build gets moved to unfavored or tested. We only recently did vote on the number of votes needed for that, before it was more or less a free call.

--Xeeron 07:38, 18 September 2006 (CDT)

Well basically what I think would happen is with nomination we would get better quality "votes", with two category we will have untested uncluttered, and unrefined is kinda the middle ground of those two. (Not a fifty five 13:05, 18 September 2006 (CDT))

The major vote problems remain. People don't test, vote with assumption, different opinions lead to abandoned discussions. Voting is the key problem, not a suitible policy. I laughed heartily at this [Talk:Mo/any Bond-Powerhealer#Time_to_move_on?|example], alliance ftv (for the vote). Don't get me wrong. All are active voters and participate in discussions. The fact i don't like is the their open support of an alliance member and the weight they can give in a vote. Just another example of things, that this policy can't fix. --Nemren 08:58, 18 September 2006 (CDT)

Well I do think unrefined solves most of the problems, it will allow for the time to do actual testing and "get rid of" awful builds. As to votes being the problem not policy, thats obviously an issue, but obviously has no solution, so its not worth thinking about. Enforcing testing under new policies isnot hard:it's obvious when someone hasn't tested for they dont use solid sentences (I think.. wouldn't?.. I don't see how). The current problem with voters nto testing is our current policy doesn't do anything about it, and we wouldn't rly have time to with the updated version, which could lead to up to 7 to 8 votes for a build.(Not a fifty five 13:01, 18 September 2006 (CDT))

Thats the problem, when i tested and vote, i will still use suggestive sentences due to being polite(if im in the mood) or afraid that there are something i did wrong during testing. But i agree that the biggest problem now is the test voting policy rather than the process, the current porcess is not bad but not the best. -- Cwingnam2000 14:35, 18 September 2006 (CDT)

About the "agree with both"... I actually would put my vote there except it seems like a throw away vote, ya know? Since I agree more with unrefined I voted there atm. Is that vote category like 1 vote for each? (essentially undecided, only making sure that a policy gets voted on) (Not a fifty five 12:43, 19 September 2006 (CDT))

Not really. If say, 60% of people vote for proposal 1 and 40% for proposal 2, NO proposal will be implemented, since policies can only be implemented by consensus (which means considerably more than a simple majority). --Xeeron 12:51, 19 September 2006 (CDT)

But that's the same as voting "neither" then. Different reasons of course, but same effect. Actually its a very strong way of saying neither, for it more likely to cause neither to be implemented. (Not a fifty five 12:55, 19 September 2006 (CDT))

Vote on builds policy

We currently do not have a builds policy, therefore this vote is to establish a builds policy. The discussion leading to this vote can be viewed on this talk page.

Proposal 1: Dual Screening, nomination

(this is the policy reflected in the current state of the article)

• New builds are placed in builds stubs.
• Any non-author can move the builds from stubs to untested by nominating them. The nominator is responsible for checking formal correctness.
• Builds in untested are discussed and voted on, voters are strongly encouraged to test the build before voting. 3 more votes for either tested or unfavored means moving the build into that category.

Proposal 2: Dual screening, double vote

(This is the procedure refered to as "Unrefined double stage screening" above)

• New builds are placed in build stubs
• A (first) vote is held. If a super-majority (i.e. all but a very small minority) disfavores the build, it is placed into unfavored. If not, it is placed into untested.
• For all builds in untested, a second vote his held, this time voters are strongly encouraged to test the build before voting. 3 more votes for either tested or unfavored means moving the build into that category.

Note that this process differs in the way builds are selected in the first stage

Vote

"I agree with proposal 1, but would also agree with proposal 2"

1. Xeeron 11:42, 19 September 2006 (CDT)
2. BrianG 19:46, 19 September 2006 (CDT)
3. Token Cleric 16:48, 22 September 2006 (CDT)
4. (Your vote here)

"I agree with proposal 1 and I do not agree with proposal 2"

1. Ifer 12:04, 19 September 2006 (CDT) -- Changed my vote.. I stongly prefer this option, but I do believe the other would work as well.
2. -- (Talk) (Cont) (Cool) 11:55, 21 September 2006 (CDT)

"I disagree with proposal 1, but would agree with proposal 2"

1. (Not a fifty five 11:53, 19 September 2006 (CDT))
2. (Onlyashadow 12:33, 19 September 2006 (CDT))
3. Also agree to add a time limit. -- Cwingnam2000 17:30, 19 September 2006 (CDT)

Neither of the above

1. I don't like either of the above a great deal... I'm curious why these are the only two proposals in the vote, when more were made above? - Greven 12:57, 19 September 2006 (CDT)
2. Having a build-stub and untested-build category is redundant. Use only one and require a majority of votes (at least 3) before a build can be moved from stub/untested to favored. (T/C) 20:00, 19 September 2006 (CDT)
3. I strongly disagree with any policy based around a static number of votes. I further disagree with the method of filtering these proposals out, which appears to be "argue until everyone who disagrees gives up." —Tanaric 21:27, 21 September 2006 (CDT)
4. I prefer Greven's idea. — Skuld 04:50, 26 September 2006 (CDT)
5. Me too, what he says at the bottom of this page seems to make more sense than this.— Azroth 12:47, 26 September 2006 (CDT)
6. I've thought about this for a while now, and I really can't support a system based on voting. I prefer the idea of a nomination process. I think a builds council would be somewhat elitist. I don't agree with Greven's idea, since it still seems to revolve around voting and not debate. <LordBiro>/<Talk> 06:39, 26 September 2006 (CDT)

If there is a substantial share of people voting for "Neither of the above", no builds policy will be implemented. End of vote is the 27th of september. --Xeeron 11:15, 19 September 2006 (CDT)

One more day to go. --Xeeron 04:21, 26 September 2006 (CDT)

Discussion:

To Karlos: well so far as to your graveyard proposal not a single person has disagreed with it (and many have agreed, including me), I think we're gonna implement it anyways regardless of the vote. People just can't agree to what the time limit should be yet is all cause we haven't all talked about it at once. (I've seen 2 weeks to 4 months lol)(Not a fifty five 12:14, 19 September 2006 (CDT))

And to Greven, in the debates above only 3 policies showed any remote sign of interest as far as being the "best" policy:the two above and two category. I think we need to add two cateegory for the vote >.< (Not a fifty five 13:03, 19 September 2006 (CDT))

I'm curious why these are the only two proposals in the vote, when more were made above?

I can give you a simple answer to that: Because in a policy vote with many policies, none will be adapted. A policy can only become policy if there is a consensus for it, meaning a huge majority of people are ok with it. If everyone votes for their slightly different pet policy, none will ever get that. --Xeeron 13:27, 19 September 2006 (CDT)

Well we could just lower "concensus" from 2/3 majority to 1/2 majority in this case. I believe it is the concensus that a policy should be adapted actually, so we rly only need a simply majority to see which one, one might think (Not a fifty five 13:32, 19 September 2006 (CDT))

I dunno, I tend to think my suggestion is quite a bit different than the two above (timelimits/only favorable tested votes/different 'nomination' process), but perhaps I'm biased, eh? - Greven 18:02, 19 September 2006 (CDT)

Well I've cast my vote, but if you guys are all about consensus I don't see why you can't come up with a system that does both of these options. For example, I'll propose a system. First, a build is entered into "Build Stubs", and must be nominated objectively as I suggested above. Then it goes to a "New Builds" Section. A first vote is held, and if it is a strong majority, the build can go directly to the "Favored Builds" (this allows obvious or important builds to be published quickly, but if considerable opposition arises later, a revote can be called). If there is no support for a build, it goes to "Unfavored Builds". This section would have a timed delete of, for example, 2 months (if support arises, a revote can be called). If there is any significant debate or disagreement on the build, it goes into the "Testing Builds" Section. This area would have a time limit, for example 2 months, where everyone who cast a vote would have to test the build fully and provide a qualified opinion in order to vote. This would be an ongoing vote until either significant consensus, or the time limit, was reached. The build would then go to favored or unfavored based on that consensus. If consensus is not reached either way by the time limit, it would go to a "Build Ideas" section. This would be an area that people could browse for ideas that might be interesting, and were tested out a lot, but were not "favored". A revote could be called at any time if there is more support later on, and then it would go back to "Testing Builds", etc.

I know there may be resistance to increasing the categories, but it is only actually 2 extra categories, and if it is intuitive and laid out nicely, nobody would mind and it would actually make things easier to sort through. This system would ensure that bad builds get deleted and don't clutter things up, new builds get evaluated in an organized way (and properly tested and debated if needed), obviously good builds get favored quickly, and build ideas that have significant opposing viewpoints can be maintained for future debate, improvement, or modification with new expansion skills (i can't wait! :) ).

Obviously you'd have to set numbers for what would be considered "significant", and "majority" etc. But that should not be difficult. It might work to do it based on a percentage rather than a hard number, and just set a minimum total vote. I really think this system takes everyone's concerns into account but if not, please discuss. :) -- BrianG 21:00, 19 September 2006 (CDT)

Chuiu, you say having two categories is redundant. I disagree: the first is checking on the style and format of the build. We don't want to upset new users that make their own build very clumsily by negative comments in the voting process. The vote will simply not start before the build article meets Wiki standards.. Ifer 02:12, 20 September 2006 (CDT)

Exactly. Think of Build Stubs like Shing Jea Island for new wiki submitters. Except in this case if you already know what you're doing, you won't be stuck there forever, its only 1 quick nomination away from being moved. -- BrianG 08:10, 20 September 2006 (CDT)

Re:Tanarics vote comment

Tanaric, I agree, see my suggestion below. I suggest a percentage vote with a minimum requirement for total number of votes. -- BrianG 22:18, 21 September 2006 (CDT)

If you are worried about numbers in a policy article, we can leave the numbers out of the policy article and instead refer to another article where the numbers will be decided on. Of course that adds another layer. Quite honestly I dont understand at all what the second part of your comment is about? Do you suggest implementing a policy while many people are against it? How would you ever implement a policy if not by discussing it till everyone agrees with the current version? --Xeeron 03:57, 22 September 2006 (CDT)

I think Tanaric is saying that, while he is opposed to voting in general, he is even further opposed to saying "a build needs to receive X amount of votes", whether X be 3 or 100. <LordBiro>/<Talk> 05:47, 22 September 2006 (CDT)

Fair enough, but has anyone made a suggestion of a system that will work that will not be based on votes at all or not have a requirement for number of votes? -- BrianG 08:17, 22 September 2006 (CDT)

GuildWiki_talk:Builds#Comments_on_process was free of votes. <LordBiro>/<Talk> 16:13, 22 September 2006 (CDT)

I just read that process and it still involves a vote to move the build to favored/featured. The main problem with this plan is that the only builds that are moved to unfavored are ones that are nominated, and builds that are so bad that nobody will bother to nominate them will just sit there forever. If the "Untested" area is used for both new builds and old builds (either ones that had an even vote at nomination or ones that nobody bothers to nominate), it will make the "Untested" section too huge for people to sort through and pick ones to nominate, and it will continue to get bigger and bigger. I'm all for the general concept of keeping around builds that are a close vote (not a "supermajority"), but I just think there should be a separate section for new builds and previously nominated or tested builds ("New Builds", and "Build Ideas"). This process you've mentioned is very similar to the process I've suggested in the discussion section (requiring a supermajority to move to favored or unfavored), with the only difference being that I have suggested separate sections to make things easier to sort. If I want to see what the new build ideas are that everyone is submitting, I should be able to go to one place to do that, and another place if I want to look through old builds that were close to successful to see if I can improve them. I'm disappointed nobody responded to that suggestion as I think it seems to cover the bases that everyone is concerned about. Sometimes its easier to design a policy everyone will agree with, than it is to get everyone to agree on a policy (if you know what I mean). -- BrianG 18:34, 22 September 2006 (CDT)

I think Agreeing with both should be clarified a bit. According to Xeeron, agreeing with both is more likely to cause neither to go into effect. I don't think ifer etc were thinking this when they cast their vote, it was made unclear what voting for both does. Voting for both counts as vpoting for both. However, Xeeron says only supermajority adopts a policy. So in reality voting for both is more detrimental to adopting a policy than voting for neither O.O (Not a fifty five 03:40, 24 September 2006 (CDT))

Err maybe I was not clear enough, but there is an important letter difference: Agreeing with both is more likely to cause either to go into effect. Meaning you should vote both that option if you can live with both policies and make sure that one is implemented. --Xeeron 04:25, 24 September 2006 (CDT)

From above. Not really. If say, 60% of people vote for proposal 1 and 40% for proposal 2, NO proposal will be implemented, since policies can only be implemented by consensus (which means considerably more than a simple majority). --Xeeron 12:51, 19 September 2006 (CDT)

It just seems here that voting for both means one is less likely to be implemented. If people there really wanted one to go into effect they would change their vote to whatever one they think should win. Currently the vote percent is something like:60%unrefined 40% nomination. So even tho consensus of voters believe A policy should be adopted, none will!!! I think a simple majority is all that should be needed. Seems kinda silly that this vote will prolly end up being a waste of like 5 hours of debate.(Not a fifty five 12:57, 24 September 2006 (CDT))

Uhhh, how should I explain this. You should think about it like this: How many people are opposed to proposal 2? 4, while 8 agree with it.

Oh and if it just were only 5 hours, it feels like 50 at least... --Xeeron 16:14, 24 September 2006 (CDT)

5 = both, 1 = prop 1, 3=prop 2, 3= neither. So. 6= prop 1, 8= prop 2, neither pass. I mean if you're saying above that prop 2 would pass anyways, cool :) it just sounded like neither would pass. (Not a fifty five 20:54, 24 September 2006 (CDT))

An epiphany of sorts.

I will first admit to not having read every single post on this page. Thus, if I step on anyone's toes, or restate something that's been said, I wholly apologize.

That said...

It seems that the more popular solutions right now—at least, the ones involved in the vote—are based on a static number of votes. This seems problematic to me for two reasons. First of all, this method only achieves its goal if the number of editors voting on builds remains static. Secondly, it's horribly unwiki.

I have come to accept that the second problem is going to be there with nearly any builds solution. I've also come to accept that a purely wiki solution, like a featured build system, is too slow to be worthwhile to our readers.

Since the vote-based solutions set up an informal oligarchy anyway, I'd like to do the next best thing—formalize it. I therefore propose the creation of the Builds Committee.

The Builds Committee should have the following structure:

• At least 6, but no more than 12, voting members.
• All members must have been active on GuildWiki for at least 4 months, with at least 500 edits.
• All members must be nominated via the [GuildWiki:Build committee nominations] process, which would be defined in a similar manner to GuildWiki:Requests for adminship.
• All members are subject to a quarterly review, in which any member of the community in good standing can request their removal.

(Details can be hammered out.)

Votes from the Builds Committee will be bound by the following protocol:

• Only 1/3 of the committee voting in either way (favor/unfavor) is sufficient to change the category. This allows for a significant number of abstentions for every build.
• Any member of the committee may vote "unfavor override" if a build violates site standards. If the override is uncontested for 3 days, the build will be deleted/moved back into stubs.

(This is roughly based on the judge's panel rules from OCReMix)

Thoughts?

—Tanaric 16:17, 25 September 2006 (CDT)

Well, see my comments above about how, in the end, we will never sift through the backlog of 500 untested builds without a person with the authority to just look at the build and move it. My suggestion was that the voting process can take place, but if the build does not garner enough attention after a month or so, then someone should be empowered (a committe a single admin) to just look at it and move it. Instead of just going in, voting and leaving it there to languish. I also suggestes this person (Xeeron is my choice) be allowed to delegate his power to a few others. I don't think any voting process will ever help us sift through them. A couple of people just need to be empowered to plow through them. --Karlos 16:37, 25 September 2006 (CDT)

Formal committees are just as evil as voting. A builds committee disincentivizes testing for people not in the committee and causes (or at least gives a perception of) elitism. Why bother, when your opinion does not count as much as some other person with X number of edits or Y amount of seniority? Your suggested numbers for how the builds committee will work are just as arbitrary as any other numbers suggested so far, and may even be contrary to GW:YAV. Furthermore, contributors should be free to participate as much or as little as they wish. The work of the wiki should not be held up because a few members of a committee are being tardy, nor should any volunteer contributor feel burdened by tasks that need doing. You can get around this by saying that build vetting does not require quorum from the builds committee, but then why have the committee in the first place? Basically, I'm saying that committees should be formed only when absolutely necessary. I think Karlos's idea of a (benevolent) builds Czar has a better chance of working, assuming a sucker sufficiently selfless person can be found to wear the crown. Make him an admin, give him a shiny delete button, and get out of his way. 71.126.187.175 17:04, 25 September 2006 (CDT)

I agree with you on one count Tanaric, it is very unwiki :P I don't agree with the idea of some sort of builds council.

I've been wondering for some time if there's an easy way to monitor the current statistics as to how many builds we get through. I've been monitoring [:Category:Tested_builds] for the last couple of weeks, and it seems like on average the category increases by 1 build every 2 or 3 days. On its own this isn't a very useful statistic; you can't tell how many builds were moved to unfavored, and as far as I can tell there's no easy way to collect this information as unfavored builds are (if I'm not mistaken) periodically archived. The same goes for stubs that are deleted.

Is there any way that we could monitor the amount of builds that go through our current processes? The reason I ask is that I'm currently concerned that, even if we did implement a comittee on the grounds that a nomination system is not fast enough, would be able to accurately compare the speed of the current system with another one? If this doesn't make sense I apologise, I'm really tired. <LordBiro>/<Talk> 19:26, 25 September 2006 (CDT)

I should have emphasized that I'm not particularily fond of this idea either, but it seems the best of all possible evils. It is significantly more wiki than a benevelant dictator. It is potentially more wiki than a static votes system, as it gives editors that have no talent/inclination to rate builds some control in the builds vetting process—they can control membership on the committee.

I'd like to also note that we have an informal builds committee right now anyway. With formalization comes standards and accountability. Right now, builds are largely done according to the whims of the editors who cared to set it up. While I'm grateful for their astronomical effort, I don't believe such a system is sustainable, especially with more expansions coming out. I also don't believe a singular dictator system is sustainable, especially if, as Xeeron said, we get thousands of builds per year.

—Tanaric 22:54, 25 September 2006 (CDT)

I see where you are comming from Tanaric, but the committee solution looks incredibly elitist to me. It would indeed take away a lot of the incentive for other people to test builds. Just looking at who tests and rates builds now and 3 month ago, at least 50% (and maybe many more) are new contributers. Had we set up a committee 3 months ago, these people might have all not joined the build vetting process. In the end, for all its faults, the voting procedure is very open for new contributers and encourages everyone to work on builds. Much the same goes for a benevolent dictator. The idea of "we need to get rid of builds that are just bad" seems to be much better served by having a sort of "if nothing was added in the last month to an untested build it gets deleted" clause, which, btw can be added to almost any procedure we have discussed so far.

Regarding your fear that votes will be static, I feel they will be less static than a committee. Getting new people on and off a committee is a long process (just take a look at the admins. I do not want to start a "remove inactive admins" discussion, but that shows how slow the process can be). In contrast, just changing the number of votes needed if we get more contributers is a very simple move. --Xeeron 04:21, 26 September 2006 (CDT)

---

While we are epiphanizing... I had thought about this some time ago, but wanted to wait till this discussion was done, but I'll throw it out there anyways. I think there should be a separation in votes between unfavored because there's something better/similar and unfavored because it just doesn't work. i.e. There should be three types of votes "Works" "Does not Work" and "There is something beter/similar." Because the question of whether the build works or not is different than whether the build is better than another build. --Karlos 18:17, 25 September 2006 (CDT)

The proposal I suggested above solves all of this! By eliminating negative votes and modifying the way in which a build is tested in the first place, the only issue that remains is the number of evil 'votes' that have to take place, which is mitigated by the fact that they can only be favorable.

If a build is similar to another build, then it should be a candidate for {{merge}}. If a build doesn't work or has poor article, it should remain in build stubs until it dies (after y period of time) or is improved. If a build works and has acceptable article quality, it should be moved to Untested Builds.

And if X people support the build being moved to Tested Builds, then it should be so.

Deleting articles may come off as a little harsh, however keep in mind that articles can simply be recreated. If after a period of time (say, a month) it is not favored, then there's very little hope for it, and it's time to pull the plug. - Greven 01:49, 26 September 2006 (CDT)

Hmmm, some people already put that (build xyz does the same better) in as their reason for a negative vote. It might be clearer if there are distinct categories of votes, but so far I have not seen a big problem distinguishing the two. --Xeeron 04:21, 26 September 2006 (CDT)

What do people want out of Build artcles?

Perhaps some of the issues people have with the above is due to differing opinions about what they want out of Build artcles. This is how I judge Build articles:

1. The Build article is of good quality.
2. The Build functions as written.
3. The Build has significant differences with other Builds.

This is what I prefer (since they tend to catch my eye), but are not necessary in my opinion for a Tested Build:

A. The Build functions comparably to other Builds with a similar purpose.

B. The Build is innovative in usage of underused skills.

C. The Build is innovative in usage of skills in interesting ways.

I know some people who vote have different opinions, such as placing A in required, and 3 in preferred. Please share your thoughts about this. - Greven 11:44, 26 September 2006 (CDT)

Hmmm...This is a good point, this whole time we've been arguing about how to test builds and how builds should be vetted, but we've completely ommitted what criteria a tester should be looking for and voting on. If we managed to get a uniform set of criteria of what determines if a build is worthy of being moved to tested, then it would fix a lot of other issues which could be stemming from it. Issues like builds being moved to unfavored for apparently invalid reasons, which seems to be what got everyone trying to fix the builds process in the first place. I think you might have something here :)— Azroth 12:43, 26 September 2006 (CDT)

I want build articles to be either innovative or putting well-known skills (or combinations thereof) in a new context resulting in a new playstyle. This is my priority. I would also like our build collection to reflect the meta-game to some extend. I've never seen Mo/As until I had spent the last weekend in the arenas. I loved to find an article about these new monks here on the wiki and I think, that should be our purpose. When people come here in search of builds, they usually want to find info on something they've seen in game or they want fresh ideas. We should provide them with both. I like, that our current collection of favoured builds is rather small. That way, it's easier to find your way around. ~ Nilles (chat) 18:31, 26 September 2006 (CDT)

I disagree, people seem to continually submit these weird niche builds that are only good for one purpose and are composed of a an unusual array of skills. Then people vote against them because they probably don't use skills in the most efficient way (although they may do one thing very well) and the creator gets all snooty because their special little baby is being trampled. Then we get other people who submit a perfectly conventional build but it gets voted down because it's invariably considered too similar to another build.

I'd like to see our builds follow our mantra of documenting Guild Wars a little better. There lots of really common builds that we haven't got here. Furthermore, often a build improves with time but when it's been "vetted" we don't like it being changed, plus if someone does submit a new build which is better than the existing build and is what people are currently using, it gets deleted (not even unfavoured) because it's too similar to an existing build.

I'm a bit sick of builds that are designed to kill this one boss to get a unique item and can't do much else. Or builds that look like they're "my first build that killed a few teams in Random Arenas". Or builds created by someone who's clearly just looked over the skills quick reference, picked out some unusual skills that people don't use much, and created a build which utilizes them.

I'd like to see more buildw that top guilds are using in GvG, builds that people are successfully running in ABs, to do missions in master time or whatever.

So that said 1 and 2 are of course good, 3 is hard to define but builds don't have do be totally different to one another, I don't mind seeing a thing or two in the "see also" section. Sometimes only one or two skills have to change for a build to be different enough to warrant its own article. Sometimes it's hard to tell the difference between a build and a variation vs two similar (but separate) builds. But by no means do builds have to be be significantly different.

B and C are irrelevant in my opinion and it's very hard to have A along with B and C anyway. Generally builds with B and C are not going to perform as well as existing comparable builds unless they're groundbreaking and revolutionary, in which case A may apply. I'm not saying that specialised and unique or unusual builds don't have a place here, I'm happy for them to keep being submitted but I'd like to see more builds submitted purely on the basis of effectiveness personally as well as less builds being deleted because "they're too similar to anorher build." The unfavoured category should be used more and we shouldn't be so quick on the trigger to delete/unfavour them anyway. Perhaps this will change with the new build policy, I don't know. --Xasxas256 19:41, 26 September 2006 (CDT)

I'd like to see more buildw that top guilds are using in GvG, builds that people are successfully running in ABs, to do missions in master time or whatever.

As I see it, having a build page for a single character defeats that purpose. We don't have a single AoD spiker here although they were really big until June. People just feel reluctant to submit builds that need a group to fully act. And that's what we'd need to see more GvG builds or mission builds. We'd need team builds instead of single builds. ~ Nilles (chat) 02:09, 27 September 2006 (CDT)

Well team build ideas take time and patience to write out which most people simply don't have a lot of: I've made two out of perhaps 12 or something but that's because I'm too sick to get out of the house :P And also people vote extremely harshly. E.g. the major team build stub I'm working on [Team - The Swarm] had quite a bit of support and now has pretty much none. I took the advice of those people I found had the best ideas and implemented them. However, its turning out like a guild cape in a guild that has 100 officers, it changes every day lol. While I think the end product I came up with is remarkably good, many people want a simple cookie cutter 3 monk backline for instance, and will vote negatively on simply that point even tho they agree with all 5 of the other player builds in it. Pretty much anyone believes its better than IWAY, a vetted build, and yet few would vote positively if I decided to take it out of stubs and push it into untested, cause they have some nitpicky ideal. I feel like I've wasted about 8 hours making a build nobody will bother looking at (Not a fifty five 20:49, 27 September 2006 (CDT))

And most importqantly, if we have few people willing to test single builkds, there isn't a chance in hell we'll get testers for team builds. Mine has a few people interested in testing, perhaps to encourage more team builds to be tested, but I doubt this'll last. I'd love to make a guildwiki GW guild just for testign builds, but nobody will join. (Not a fifty five 20:51, 27 September 2006 (CDT))

3 to 1 Vote to Post Policy

I was once in an internet writing workshop. We would submit our work to a list, which would forward the work out to all of the other members of the list for critique. Generally, you got 5-6 critiques for each piece that you posted. There were two general rules to the workshop:

1. If you were in the workshop, you had to make 4 entries per month.

2. you were expected to enter at least 2 critiques for every submission of your own.

While the first rule wouldn't necessarily be a good thing for the wiki's builds, I think the second one would be very useful. Based on this, here's my proposal: Make it a requirement that, for someone to post a build, they have to test and vote on at least 3 builds in the untested section. This could provide several benefits, such as:

• Added help: It will help us get through the untested builds more quickly.
• Reduced Influx: It will reduce the rate in which new submission are made
• Reduced duplications: It will ensure that the people posting new builds have at least looked at the list, which will increase the likelihood that they will find something that already exists that is similar to their build.
• Increased format quality: It will ensure that the people posting new builds have at least looked at the formatting before posting a new build.
• Increased build quality: If someone has critiqued a build, then they will go into their own build asking the question "what criticism can I expect to see?" By making people critique first, it puts them into a critiquing attitude when they do their own write-up.
• Reduced abandonment: It will reduce the incentive to "slap something together and post it up", never to look at it again. People care about things they have to work for; if people have to do just a wee bit of work to earn the right to post a build (and 3 votes per new build isn't much to ask), then we wouldn't have the mountain of abandoned build ideas out there.

Of course, I understand that, if this were implemented, I would have some catching up to do. But I would gladly do it if it would solve this problem.--Token Cleric 14:56, 27 September 2006 (CDT)

Huh...*Applauds sarcastically* great idea, in a perfect world. But sadly this isn't a perfect world. Therefore, I'll have to add one more bullet.

• Increased number of "bad votes": You see if you were required to vote on 3 builds before posting one, it wouldn’t make people spend more time on a build and stop them from just throwing something together and then abandoning it. All it would do is cause the number of no test votes to skyrocket as most people who would be posting new builds would just make three votes like they were required to. This would be a fiasco. We would get tons of inexperienced voters casting votes with no backing just for the sole purpose of getting there build in. This would destroy the builds section on the wiki, as no build would be properly voted and thus the vast majority would go to the wrong section.
  

Sorry, but this is what I see happening if your policy was to be added to the wiki. Your free to dispute this if you want, but I cant guarantee it will get you anywhere.— Azroth 17:17, 27 September 2006 (CDT)

That's a straw-man argument. It's like arguing that taxes shouldn't exist because some people would cheat on their taxes. The fact that some people would cast bad votes to get around it do not change the merits of the policy.

I've seen this kind of thing in the writer's workshop time and time again; these are the same types of people who get a quick hankering to write, but then when they find out that they have to contribute to get something in return they back off. The people who abandon builds are generally two things: spontaneous and lazy. If you require even the slightest amount of work for them to get what they want, their laziness generally overcomes their spontaneity and they don't post.

Regarding bad votes: if you want to minimize bad votes, put a minimum standard on what constitutes a vote. We have standards for everything else (format, content, etc.), there is no reason for having no standards for what constitutes a vote. Consider a 30 word minimum. This would have the following benefits:

• We get at least 90 words worth of thought out of each person before they could post a build.
• It is MUCH easier to spot a bad vote if it has 30 words worth of bad explanation behind it.
• Once again, laziness would overcome spontaneity, and the crap would be stopped before it ever hit the wiki.

If it will make it more palatable, let me amend the suggestion: 3 votes posted for each build posted, and each vote must include at least 30 words of explanation for the vote, regardless of whether it is an "up" or "down" vote. Is that better?  :-) --Token Cleric 18:06, 27 September 2006 (CDT)

Ok, if other changer were implimented along side this like a minimum number of words in a vote like you suggested, and maybe better screening of votes before a build is moved (like the person moving it reading all the votes and making sure that they're valid instead of just counting the number of votes) then I could see this working. But you would deffininely need the minimum word count to increase the work enough for lazyness to overcome some people. Otherwise we're back to my previous argument. Other than that, a minimum word count on votes alone would be helpful, and as you said would make it much easier to tell a good vote from a crap one.— Azroth 19:41, 27 September 2006 (CDT)

Well I've been commenting on lots and lots of builds and I'm sorry but I have to agree with azroth here. Using the tax analogy, it is right to condemn the tax system if 90% of people cheat on their taxes, which is kinda how the builds voting is goin. (Not a fifty five 20:40, 27 September 2006 (CDT))

Vote results inconclusive it seems

Well the final tally is 3 in favor of unrefined, 2 in favor of nomination, and 3 undecided. If you also consider that three people in "neither" voiced they voted therecause they liked greven's idea.. that makes 3 unrefined, 3 undecided, 3 two category, 3 neither, and 2 for nomination. I.e. this is quite literally the most divided it could possibly get. well.. umm... I'm the first to comment so I say we adopt unrefined lol. No srsly, what the hell do we do now? (Not a fifty five 21:19, 27 September 2006 (CDT))

Now we start over, consider other options, and try to hold a vote between two (or more) options that aren't as similar to each other as the last two. Hopeful if people see enough diffence between the new options in the next vote they wont all vote undecided (myself included). Personal I like where Greven and Token Cleric are going— Azroth 21:39, 27 September 2006 (CDT)

I will give up trying. The results are as far from a consensus as it gets and one month of talking (including the latest comments here) show me that there will be a never ending flow of new suggestions, but never one that the majority can agree on. This experience has shown me that the wiki concept is inherently flawed in dealing with big controversies that can not be dealt with by citing a fact from somewhere else. --Xeeron 04:22, 28 September 2006 (CDT)

Cheer up, Xeeron; this is just a small hurdle. The wiki concept is meant to be an encyclopedia, with easily verifiable information. It's a good system for documenting hard information, such as the skills and their calculations. It's difficult in the context that we are using it for builds because, ultimately, it is going to come down to opinions. I think we can come to a solution that we can agree upon, though (and speaking of that, please chime in on the vote below. :-) ).--Token Cleric 15:16, 28 September 2006 (CDT)

hmmmm....

well seeing as talking about this anymore isn't going to get us anywhere, I'm just gonna start an unrefined parallel builds process in my namespace :) If you find anything wrong with that say so, but I'm currently not gonna bother posting/commenting on builds in the current policy, and no new policy is going to get adopted. I'm starting this project here (Not a fifty five 09:49, 28 September 2006 (CDT))

Delete after two weeks

I hadn't noticed this in the policy until now. I think that anything with a "Delete" tag shouldn't need to wait two weeks. We may want a new tag for this time frame - something like a "delete warning" or "Build Delete". Then after the two weeks, it can be changed to "delete" to flag it for the admin as ready. --- Barek (talk • contribs) - 13:06, 28 September 2006 (CDT)

How about this: [Template:Abandoned] - Greven 14:01, 28 September 2006 (CDT)

Good draft, but the icon needs to be replaced or removed - the current image is of such poor quality as to be meaningless. --- Barek (talk • contribs) - 14:14, 28 September 2006 (CDT)

I like the idea. It is an excellent way to notify users and the creator of a build's fate. So, unless anyone would want to step in--the build will eventually be deleted. Though... I'm curious: What is that black image supposed to be? -- Feather 14:16, 28 September 2006 (CDT)

My PSP skills are lacking.. I've redone the image. - Greven 14:32, 28 September 2006 (CDT)

As the [:Category:Abandoned] is now in use, I updated the draft policy to reflect this. --- Barek (talk • contribs) - 20:59, 28 September 2006 (CDT)

VOTE: Prerequisite to Post a Build and Standards for Voting

I'm not big on calling a million votes for every little topic, but I think this would really do a lot to solve our problem. Here's my proposal (please read the "3 to 1" section above for more information):

If a person wants to post a build, that person must test at least 3 untested builds prior to posting their own builds. This should be done for each build that they want to post (example, if I have 3 builds that I wish to post on the wiki, I must cast a vote for at least 9 builds). Further, each vote must include at least 30 words of explanation for the vote, regardless of whether it is an "up" or "down" vote.

Vote

For the sake of this vote, please vote by the standard described in the proposal, i.e. at least 30 words of response, regardless of whether it is an "up" or "down" vote.

Hmm... shouldn't down votes be required to have less than 30 words?>.< (Not a fifty five 15:18, 28 September 2006 (CDT))

I knew this would come up; that's why I clarified. For this one vote, please contribute at least 30 words.

"I agree with this proposal."

1. --Token Cleric 15:09, 28 September 2006 (CDT) :Most of the people that abandon builds are lazy writers who get a momentary burst of motivation followed by no desire to follow-up. By creating a small amount of work for them to perform prior to getting what they want, we can help their laziness overcome their spontaneity and keep the rubbish off of the board. This will be easy enough for the people who care about their contributions, yet tough enough to prevent drive-bys (in both the form of drive-by build posting AND drive-by voting).
2. --I agree with the proposal in theory, but I feel it would be hard to impliment. There is a chance that some good build ideas might not get posted here as a result of lazyness. but I feel the risk is worth the reward as long as the required vote to move a build from untested remains at 3. As long as this stays stable it will mean that there will be a 1:1 ratio of builds coming in too builds going out of untested which solves the problem of the constant growth of the untested category. All in all, if it can be enforced I think it could be a big help.— Azroth 16:58, 28 September 2006 (CDT)
3. Though it is hard to impliment, I think this would be a good idea.

"I disagree with the proposal."

1. Sometimes it's obvious why some builds are unfavored, and/or reasons for your vote have already been provided, so i'm against this proposal right now, but the idea sounds nice. I also agree with Not a fifty five. -- (Talk) (Cont) (Cool) 15:22, 28 September 2006 (CDT)
2. I have three concerns with this. Fisrt, and to my mind the bigger concern, lets say we manage to attract some of the more established build makers to try their hand at documenting their builds on GuildWiki - if as soon as they try to post, they're told this administrative rule exists and they must vote on others prior to contributing - they might accept it and do it, or it may sour them on their experience in the wiki as it could give them the impression that the wiki has a build-making elite that places road blocks to getting new users with new ideas. While that's not the intent of this rule, I can certainly see it causing a negative reaction in some users which would lead to bad publicity for the site. Second, if a user has only made 8 votes, and posts three, do you toss out their build (which may be a very good build) on a technicality? Lastly, how do you enforce it - are we going to create a group of people who go around counting votes made? We could just rely on trust that they've voted; but I've been dealing with auditors at work and their lack of trust is rubbing off. --- Barek (talk • contribs) - 16:23, 28 September 2006 (CDT)
3. This is a nice idea but impractical. I do not think GuildWiki is the place for individual authors. Let me explain: Our goal has always been to document the world of Guild Wars as thoroughly as possible, and this includes non-factual information including guides and builds. Imagine if Touch Ranger was not listed as a build here. Then surely someone should add it, be that me, or any other contributor. Since they are documenting a build that is popular within the game (and is certainly not the contributor's own invention) why should the author then be subject to vote on other builds? He is not submitting his own work, he is documenting a commonly used build in the game. I would argue that GuildWiki is not the place for build authors, but the place for build documentors. <LordBiro>/<Talk> 17:25, 28 September 2006 (CDT)
4. There are a number of reasons stated above, especially Lord Biro's about documentation that I agree with. Furthermore, there is no way to check wether a user has in fact tested a build before voting on it. That's not a bad thing, many decisions can and have to be made based upon experience with the game. The only use that the regulation in question would have is that new users saw how other builds are made. In fact, new contributors want to make their idea public and rarely care about others. I really don't want new users strolling around the Category:Untested builds and cast votes on everything just to fill the demands. ~ Nilles (chat) 18:39, 28 September 2006 (CDT)
5. (Your vote here)

Discussion

Would it be possible to add a line of code which checks how many builds a person has contributed to voting on versus how many they have posted and if its no a 3:1 ratio or above pop up a page that tells the person they must vote x many more times before submitting their build. If so, then you could probably add a line of code to enforce a minimum word count in votes well. This would take care of the dependency on the honor system vs. audits problem.— Azroth 16:50, 28 September 2006 (CDT)

The problem is that this is a wiki, designed by MediaWiki from the ground up to maximize the ability of multiple users to provide unlimited input. The types of restrictions you're describing would be much easier to implement in forum software rather than the MediaWiki software; or better yet within a specialised build/voting system (it would be extremely difficult to write code here that could differentiate between a build vote vs. a build comment vs. posts/edits on non-build articles.) --- Barek (talk • contribs) - 17:18, 28 September 2006 (CDT)

Barek, I'm trying to understand your statement about a "build-making elite" above. We're not talking about a college initiation to get into a fraternity. It's not the gauntlet. We're talking about a little bit of thought coupled with 90 words. If someone is soured by such a simple prerequisite, isn't it likely that the same person would probably be the same type that would abandon a build? To quote the builds page: "The build should meet the standards and expectations of the GuildWiki..." We already have standards for builds; why do we have no standard for votes? I'm asking that we establish a standard for what constitutes a vote, as well as a way to streamline the process.

I do understand your point, though, about the mechanics involved with enforcing such a request. If that is the problem, then should we consider adding a simple request? That is, post something in the build section specifically asking that people test 3 builds prior to posting. This still keeps it voluntary, albeit with a mild guilt trip involved. It's got to be better than what we are doing right now.

Also, most of the replies above focus on the 3 vote requirement, but there has been little response about the 30 word minimum on votes. What do you guys think about that? Can anyone think of a drawback to such a requirement? If you type at 10 words per minute, it's still only 3 minutes.--Token Cleric 19:17, 28 September 2006 (CDT)

Maybe it's just me thats soured on bad experiences with new users having tantrums when they violate some policy or guideline. I start seeing potential causes of future occurances everywhere.

As for the thirty word minimum; I'm not a big fan of that either. I could see a guideline that more detail in your reply is preferable to help others understand their logic; but minimums shouldn't be required. Sometimes the build has such obvious flaws, or is so obviously the norm in use, that a vote reason can be summed up in just a dozen or so words. --- Barek (talk • contribs) - 11:15, 29 September 2006 (CDT)

The votes on [Talk:E/any Gust Support] are some goood examples for both sides of the 30 word minimum argument. Dirigible was able to get his point across in 19 words for a favored vote, where as Ham Popcorn Solo needed 38 words to explain his unfavored vote. And Rapta...well... Rapta was just being Rapta I guess :P— Azroth 14:17, 29 September 2006 (CDT)

The beauty of the 30 word minimum is that it really highlights the bad votes. Two people may both give the same vote, but for completely different reasons. One reason might be good, but the other might be terrible. If all they provide is a name, though, we can't weed the bad ones out. With a simple 30 word requirement, there will be no more hiding of bad votes behind silence.

I agree with you, Barek, that sometimes the flaws of a build can be explained with 12 words. If that is the case, though, it doesn't take much to give 18 words worth of recommendations for improvement. We're in this together, and every bit of help...well...HELPS. Do you see anything wrong with that?--Token Cleric 02:48, 30 September 2006 (CDT)

My hybrid solution

We now have Build Stubs, Untested Builds, Favored Builds and Unfavored builds. We're not agreeing on a voting polecy, and we are not even sure about what defines a good build. The three to one to vote polecy would work great in a perfect world, but we are not reaching a consensus whether implementing it would work or if it would just be a lot of work.

Greven's idea about deletion times seems to be a good one, so I'll quote it here:

1. Build Stub initially created.

2. Build Stub worked on by author(s).

3. Build Stub author leaves a note on talk page indicating he feels it's finished.

4. Build Stub moved to Untested Build by a non-author who agrees that it's ready for testing, or a comment is left as-is indicating disagreement (however, another non-author could override this) and returns to step two. The only criteria for build-stub not being moved should be the build not conforming to article format standards.

1. Untested Build is commented on, and may be lightly modified via discussion

2. Untested Build may then be voted on, with three unique votes being the requirement before it can be moved to Tested Builds

3. Untested Build can only then be moved by a non-author to Tested Builds, once the vote requirement is met.

5. Build Stub/Untested Build will be flagged for deletion two weeks after the last modified Article or Article Talk date. At this point, it is assumed abandoned, and the Article may not be modified except to remove an improper Delete tag, unless the Article Talk has been modified in which case the Delete tag will be removed.

6. Build Stub/Untested Build will be deleted two weeks after the Delete tag is added, unless the Article Talk has been modified.

My additions to this are:

• A build can be commented on and voted on simultaniously. If the author decides to change something in reaction to the discussion, he may remove the current votes and start the voting fresh.
• After a minimum of four (three is too few imho) votes, the build is moved to Favored/Neutral/Unfavored. A build that has an excess of three positive votes will be favored, and a build with an excess of three negative votes will be unfavored. This will be unbalanced when the number of votes increases too much, so for every ten votes an additional excess vote will be required (though this will rarely happen I guess)
• if we want to implement the 3 to 1 rule, the author must also link to the three votes he casted before a non-author can place the build into Untested.

Another quote:

Perhaps some of the issues people have with the above is due to differing opinions about what they want out of Build artcles. This is how I judge Build articles:

1. The Build article is of good quality.

2. The Build functions as written.

3. The Build has significant differences with other Builds.

This is what I prefer (since they tend to catch my eye), but are not necessary in my opinion for a Tested Build:

A. The Build functions comparably to other Builds with a similar purpose.

B. The Build is innovative in usage of underused skills.

C. The Build is innovative in usage of skills in interesting ways.

The first should already have been taken care of by the nominator; The second and third are good criteria. A should be a prequisite as well, although I would like to rephrase it into:

4. The Build functions comparably to other Builds with a similar purpose that require a similar level of expertise to use.

An exception to this criterium should be that if the build is unique in its purpose for that profession, this does not count.

B and C are nice of course, but should not be prequisites.

Finally, I agree we should implement a guideline for casting votes:

• a voter must have read all the comments
• he must have tried the build in-game
• he must explain his vote in a minimum number of words
• he may not personally attack the author or other voters
• he should take into account the criteria that define a build as good or bad, and preferably refer to the one(s) he thinks are not met.

---

This will implement a bit of control in quality, it will be dynamic in the favored/unfavored system, and it offers guidelines for all the problems that occur in the build screening process. It involves yet another build category, but I think this is the best way to sort it all.. some builds just are neither great nor bad :)

Ifer (t/c) 05:00, 29 September 2006 (CDT)

Hows that, I indented the quotes and italicized them.— Azroth 14:39, 29 September 2006 (CDT)

This is awesome! I've been pushing people to try to come up with a policy that incorporates everyone's concerns and suggestions and it looks like this covers it! It also reminds me of my suggestion but nobody responded to it. I also love Token Cleric's 3 to 1 idea, but my main concern with that was how to implement it technologically, but you've proposed a good solution to that as well! The author is required to provide proof of his votes before his build can be moved from stubs to untested! My only suggestion would be to consider a percentage based vote rather than a requirement of 4 (that way its scalable). Also, please elaborate on what you mean by "Neutral". In my suggestion above I proposed a "Build Ideas" area, where neutrally voted builds ended up to be worked on and reconsidered in the future. I'm throwing my support behind this suggestion as the best hope for reaching consensus! -- BrianG 18:47, 29 September 2006 (CDT)

" There lots of really common builds that we haven't got here. Xasxas256. " Really? There are ~150 builds in the tested category, and I doubt there are 20 more that is above the average performance lvl of the category (I am not talking about team builds, because that section is pretty much non-existent). The tested category has already started to slip. Not because the vetting process is bad, there are no more outstanding builds. When nightfall is out, obviously this is going to change, yet I doubt that the amount of energy and time the community is wasting on this issue is justified. If the wiki wants to grow as a build library, then we should look into the unfavored category (thats where 96% of the 3-400 untested builds are heading anyway). If the wiki wants to concentrate on DOCUMENTING builds that are widely known and used, than the build writing 101 should be saying that: “we do not carry pet builds of genius inventors, if you have not seen your build ingame on other people, don't post it. Wiki is not a forum for new build discussion.” My point is that we should not be forcing a policy vote on evaluating builds before we agree on:

1. what kind of builds the wiki wants to catalog. (document or invent)
2. how many of them (minimum performance level)
3. what is going to be the cataloging system (1,2...? directories, ranks) Vazze 07:16, 30 September 2006 (CDT)

@Azroth: The simplest solution always slips my mind ;)

Neutrally voted builds are builds on which the voters cannot reach a consensus, but have been voted on enough to make the term "untested" unjustifyable.

Vasse, your reaction is probably directed at the entire discussion, but I'll respond to it with my own suggestion in mind; I think a wiki should both document and be open to now ideas, and that they should be treated identically(= objectively). "If it's good, it's good" is what I say! -- Ifer (t/c) 12:19, 30 September 2006 (CDT)

A "neutral" category would be as useful for visitors as the untested category is today. I don't see real benefit there, only more work. I like the idea to seperate the stub page from the untested category though. It makes it easier to review. However, I disagree with "users have to play the build before voting". The first lesson concerning builds in GW is, that it's not advisable to put your points in more than three attributes at max. The second lesson is the responsible use of runes. The third is that players have expectations to which the build should live up to. The third is usually where builds fail. The builds that get argued most are usually on a tightrope walk between irresponsibility and effectiveness and require either very skillful play or special support from the team to fulfill our expectations. Wether a build complys with the first two rules is easy to see. I don't see why a player should invest his time to test something that's inferior from the core. The third, the expectations, are not as easy to judge. An experienced player however already had his share of fooling around with the game mechanics and already played a vast number of skills in any imaginable combination. That might not be true for all classes, but if you've played a Monk for over a year, you know what to expect upon entering the Arena. If a responsible wiki user can't determine the immediate benefit of a build or how it would be played, he doesn't vote.

If a build causes too much controversy among the community, it's obviously not suited for general recommendation and should go to unfavored. If a build might work just fine under most circumstances but completely fail when conditions with fair probability are met, the whole build has failed and shouldn't be favored either. I think all builds should be at workable to some extend under all likely conditions for which they are intent. Any condition that keeps your build from fulfilling its purpose by the time it is needed, causes the build to fail. That includes being out of energy or the inability to deal adequate damage when needed. Of course, a Domination Mesmer that does nothing but spamming Martyr while waiting for Eburn and Shatter Enchantment to recharge needs almost no energy management while most assassins need large amounts of energy to be able to bring their combos to effectiveness. Our senior contributors do see those flaws and take appropriate action. It is the responsibility of each author to convince the reviewers that the design of the build is coherent and that all skills, items and attributes have their purpose to contribute to the gameplay. Most authors fail there because the base of their argumentation, the build, does not withstand the criticism. Increasing quality by changing the formal process like we try on this page does not make our builds better nor the testing easier, so set your expectations accordingly. However, it might help in lifting good builds out of the untested category. ~ Nilles (chat) 21:13, 1 October 2006 (CDT)

Then lifting good builds out of the untested category it is! Seriously, I think a policy is important if you want the wiki to be accessable. If the "senior contributors" want to do everything by themselves that's fine with me, but I say make the build rating as open as possible. More votes are always better, and being experienced does make you somewhat biased. (Want to see proof? see:User_talk:8765) My decision to make a neutral category was to differentiate the bad builds that could be deleted for being so useless from the builds that are not optimal but work for some people. I agree some builds need no testing to see they are terrible, but you always need to test something to see if it really is good. An alternative to Favored, Neutral and Unfavored is Favored, Unfavored and Unfavored + Deletion tag.

On a side note, I really like this quote: It is the responsibility of each author to convince the reviewers that the design of the build is coherent and that all skills, items and attributes have their purpose to contribute to the gameplay. Most authors fail there because the base of their argumentation, the build, does not withstand the criticism. -- Ifer (t/c) 09:43, 2 October 2006 (CDT)