GuildWiki talk:Builds

I Archived the current discussion. Since some of it was quite recent, you can go and return the relevant text to continue the discussion, or just restart it. -- Ifer (t/c) 14:02, 2 October 2006 (CDT)

Three To One
The three to one process is not very accepted, but I feel it works well within this policy. Discuss it's usage in this policy here. If we decide not to use this, a note should be added to relevant pages that requests build authors to vote on other builds as well, with three to one as a basic guideline.

personally, I think this is great and I believe it can be used effectively here. -- Ifer (t/c) 13:28, 2 October 2006 (CDT)


 * It seems most people liked the idea but the main opposition was in regards to how to implement it. You ''made a good suggestion about how to implement this idea but nobody really responded.  Does anyone have any opposition to the 3 to 1 policy if it is implemented in the way Ifer suggested? (Before a build is moved from stubs to untested, the author of a build is required to provide links to his 3 votes in order to prove that he has fulfilled his obligation). -- BrianG 18:08, 2 October 2006 (CDT)


 * I see no problem with suggesting or providing encouragement for new contributors to vote; but I see no practical way to enforce it - as a result I'm against making it part of the policy. The suggestion to provide links is equally impractical - you're still stuck with figuring a way to enforce that the user doesn't repeat their links on multiple builds. --- Barek (talk • contribs) - 18:19, 2 October 2006 (CDT)


 * Yes, basically you're right, but most of the wiki seems to operate on trusting other users. The rule wouldn't have to be strictly enforced, but at least it gets a point across to new users, once they submit one build and understand that they have to help out by voting on other builds, they will get the idea.  Even if it wouldn't work perfectly it would at least make a positive difference in comparison to the way builds are currently entered.  Even if the requirement was only for a user's first build submission it would still be better. -- BrianG 23:36, 2 October 2006 (CDT)


 * For the reasons stated here I disagree with the proposal regardless of the way it would be implemented. Having new contributors vote on untested builds is not going to raise neither quality nor quantity of new builds. Instead, it's gonna scare off contributors who are not willing to further invest into the guildwiki. Comparing that to the status quo I'd rather spite an author instead of a losing good build. My personal favorite from the discussion was moving the whole build section to a new site with special GW build contribution software. ~ Nilles (chat) 06:10, 3 October 2006 (CDT)
 * You have a problem with the three to one rule, that it might scare off contributors that are not willing to do anything else, apart from sharing their build with the rest of us. Do we even want that? such people will not check if a similar build exists, and if they lack the expertise to test a build, then what makes their build a good contribution to the wiki? I think any user that is able to post a build article is able to vote on other builds. He can choose build that he is somewhat aquainted with if his GW experience is limited. The requirement does not necesserily have to be followed and checked up on constantly, think of it as a strong suggestion. However, the three to one rule can be removed from the overall policy, as I've indicated with the asterixes. --  Ifer (t/c) 09:06, 3 October 2006 (CDT)


 * Foremost, I have a problem with bureaucracy. An author has enough to think and care about and so do reviewers. Correct me if I'm wrong but that additional criteria does nothing but multiplying our work. Do you have any idea what it takes to test completely new builds? Not a fifty five and Azroth already put that very well. You can't force people to submit quality work and you can't force testers to submit quality criticism, no matter how strict the policy. The great difference between the writing workshop (where the idea stems from) and GW builds is that GW builds are not that easy to judge. That's not because builds would be that more complex than written text, but whoever writes has very likely 10-20 years experience with text. The old timers among us have two years at maximum - including beta! ~ Nilles (chat) 09:39, 3 October 2006 (CDT)


 * As I said earlier, I have no problem with it being a suggestion that a user review other builds; but I am strongly against making it policy. You ask if we even want user who would be scared off by the extra work; I believe they wouldn't be scared off - more of an annoyance at our beaurocratic bs that makes them take their builds elsewhere.  I also question if we even want to require users who may be working their first build ever after playing the game for two weeks making votes that would impact if a build is favored or not?  --- Barek (talk • contribs) - 09:51, 3 October 2006 (CDT)
 * Can a contributor who has only played the game for two weeks add a valid build? I rest my case, and leave it to a vote. -- Ifer (t/c) 10:13, 3 October 2006 (CDT)
 * Three problems here. First, votes should only be used as a last resort in establishing policy, consensus through discussion is preferred.  Second, three way votes are inherently flawed.  While one option may get more than the other two, it may still be less than 50% making it a non-majority decision.  Third, we already had this vote last week.  Are you going to forever call new votes whenever it gets voted down?
 * For now I've removed the vote. Please justify why it should be re-voted on after only a week before calling a new one.  --- Barek (talk • contribs) - 11:28, 3 October 2006 (CDT)
 * Note: If it can be justified, I have no problem with restoring the vote. But thus far, I see nothing in the discussion to suggest this is significantly changed from the prior vote. --- Barek (talk • contribs) - 11:34, 3 October 2006 (CDT)
 * Why a new vote? Because the policy suggestion has dealt with some of the problems that were used as counterarguments in the last vote/discussion. This vote was on ThreeToOne as it is used in this policy suggestion. The reason I made a three-way vote is because everybody who votes for the first option is for the second option as well- the second is a watered down version of the first option. The third option will probably not get much support, but to offer a complete array of options I had to add it. If any of the three options would get a convincing amount of votes, that's the one that should be used. If not, the second option is chosen, because there is a majority that favors mentioning it(even though part of that majority would rather have the more drastic approach) -- Ifer (t/c) 11:42, 3 October 2006 (CDT)
 * The prior vote to which I linked specifically states that it's about the three-to-one mechanism, and not about the policy as a whole. The only difference I see between that vote and this one is that vote also included the 30-word minimum clause, which is omitted here.  However, that clause really didn't receive much comment in the prior vote, so I see no reason to suspect that it would result in a difference. --- Barek (talk • contribs) - 11:52, 3 October 2006 (CDT)
 * Barek, this vote is essentially different. Referring to the old vote: If this is to be policy, it's going to be in a copy-paste template. Therefore, your own first point is moot. The second will not happen, as the rule is not actively enforced- if someone bothers to count all the builds you made and all the votes you cast, then YES, he can put it back into the stubs because you double-linked some of your votes. But any contributor who would link to the same vote twice would know that he's cheating the system. Your last argument is a question that has been answered in the policy. Lordbiro's point still stands, but Kitty refers to the discussion above, where all criticism goes to implementing and controlling issues. Unless you believe most users are dishonest, none of those arguments are still valid. -- Ifer (t/c) 18:50, 3 October 2006 (CDT)
 * I still don't see a significant change. But, as no one else is stating one way or another thus far, go ahead and repost the vote.  I would however recommend some changes.  Make it two distinct votes.  First, should three-to-one be used, yes/no.  Then the second vote being that, assuming it is selected to be used, should it be part of policy or set as a highly encouraged guideline.  Also, be sure to add the  . --- Barek (talk • contribs) - 19:05, 3 October 2006 (CDT)

Votes
First of all: Do we like the three to one idea?

Agree Disagree
 * 1)  Ifer (t/c) 03:05, 4 October 2006 (CDT)
 * 2) add your name here
 * 1) To much of a hassle for doubtful profit: Forced reviews could be low quality. --Xeeron 05:01, 4 October 2006 (CDT)
 * 2) ~ Nilles (chat)  07:43, 4 October 2006 (CDT)
 * 3) --- Barek (talk • contribs) - 08:48, 4 October 2006 (CDT) - for the reasons above.
 * 4) Forcing people to review is like encouraging drive-by shootings. Kessel 09:31, 6 October 2006 (CDT)
 * 5) --[[Image:Kitty1.jpg|24px|]] (Talk) (Cont) (Cool) [[Image:Soft2.jpg|24px|]] 11:05, 6 October 2006 (CDT)
 * 6)  &lt;LordBiro&gt;/&lt;Talk&gt; 11:24, 6 October 2006 (CDT) I'm sick of voting. MAKE THE VOTING STOP, ARGH!

If so, do we want it as a policy, or as a guideline?

Policy Guideline
 * 1)  Ifer (t/c) 03:05, 4 October 2006 (CDT)
 * 2) add your name here
 * 1) --- Barek (talk • contribs) - 08:48, 4 October 2006 (CDT) If the "Agree" from first vote wins, then guideline at most.  Too much of a hassle to enforce, and an unenforced policy should not be a policy.
 * 2) add your name here

Discuss
What's the close date? One week or two from Oct 4th? --- Barek (talk • contribs) - 14:37, 4 October 2006 (CDT)
 * One week is fine I think. I mentioned that in my previous poll, but forgot to add it here.. -- Ifer (t/c) 16:06, 6 October 2006 (CDT)

Oh, I never responded to xeerons vote.. The votes can't be of low quality - not noticable anyway. Please, read and think before saying that, because I've implemented a safecatch for that. I am insulted by the way people assume this 3 to 1 incarnation is identical to the one previously voted upon. If you think the safecatch won't work, then that's a good reason, but this is nonsense. -- Ifer (t/c) 14:43, 7 October 2006 (CDT)
 * What's that "safecatch" you're talking about? I really tried reading everything, but the sheer amount of posts everywhere makes it quite hard to track so forgive me if I missed something. Could you rephrase that here or link to it on my talk page? ~ Nilles (chat) 21:36, 7 October 2006 (CDT)
 * Third item Builds. -- Ifer (t/c) 04:15, 8 October 2006 (CDT)
 * Sorry, but your "safecatch" (apart from being horrible democratic practise), does nothing to prevent forced reviews from being bad. It tried to prevent them from having an influence, but nothing prevents the authors from writing bad ones. --Xeeron 05:40, 8 October 2006 (CDT)
 * Nothing prevents anyone from adding bad things to the wiki. However, the obligated build reviews have to be of some quality, because if it's not good it's not going to count for the nomination process anyway.. -- Ifer (t/c) 11:16, 8 October 2006 (CDT) I am sure I signed this...
 * That "safecatch" is infeasible. You're trying to get a system based on review and audition going. The problem is, that we don't want to judge subjective entries. Since we are trying to proceed in consent, even judging builds itself is highly contradictory to this. I don't like the idea to review reviews at all and I don't think anyone else does. In the end, the proposed procedure will not simplify nor speed up the testing of controversial builds, it will in fact complicate matters due to the increased bureaucratic complexity. ~ Nilles (chat) 10:03, 8 October 2006 (CDT)
 * I agree, we do not want to judge the work of others- it's very unwiki. But in the build section, we have little choice in the matter I'm afraid. I believe the proposed procedure will slightly decrease the influx of new builds, and it will greatly increase the number of voters on other builds. You see, if a nominator checks up on the validity of a vote, he's halfway to voting himself :) This system will increase the speed at which builds are rated, and it will help chop down the great big pile of untested builds. However, it looks like it's not going to be implemented, because I'm the only 3 to 1 fan still here.. --  Ifer (t/c) 11:16, 8 October 2006 (CDT)

Catergory Names
I have currently named the catergories I use Stubs, Untested, Favored, Neutral and Unfavored. The fourth has met some resistance, and I have an alternative: Favored, Neutral and Unfavored can be changed to Favored, Unfavored and Unfavored (impending Archive notice). In this case, a week should be enough time to correct the build or to sway the vote - if not, the page is archived.

Discuss.

I personally don't care, I think either will work. -- Ifer (t/c) 13:40, 2 October 2006 (CDT)


 * It seems to me that there are 2 main kinds of people who use the builds section. Those who want to document the most commonly used builds, and those who enjoy creating or brainstorming on new build ideas.  This is okay, because different people are allowed to enjoy the game in different ways.  Personally, my favorite part of the game is coming up with my own build, so I don't really have that much interest in reading documentation of the most popular builds (aside from helping me learn what I might be up against).


 * The first group of people seem opposed to the concept of having a separate section for neutral or closely disputed builds to go to rather than unfavored, while the second group (including myself) seems to like this idea. I think this is because we may enjoy browsing through other people's ideas to help with our own creativity, or we like the challenge of taking a concept that is almost working and see if we can get it the rest of the way.  And it would also allow the untested section to be used more efficiently by both groups.


 * The nice thing about categories is that if certain people have no interest in the content of that category, they can choose not to click on it, and the people who do have an interest in that category, can use it without interfering with other people's purposes. If some people would have use for a category but others would not, what is the harm in having that category?  Wouldn't that be the best solution to satisfy both of these groups of people? -- BrianG 18:03, 2 October 2006 (CDT)


 * Ok, I have changed it to unfavored and unfavored (archive notice), because deletion is too un-wiki. This way reasonably good but unfavored builds stay, but the real bad unfavored builds are put away. -- Ifer (t/c) 11:49, 3 October 2006 (CDT)


 * Ifer I think you missed what I was saying. I don't care what happens to votes that get unfavored, deletion or archive is fine. I was talking about your "Neutral" category, thats the way I think it should be done. A build should not be "unfavored" unless concensus is reached. For close votes or heavily debated builds, I suggested they should go to a category called "Build Ideas", where they could continue to be modified and debated (if there was interest), without cluttering up the untested category. This is basically the same thing as your "Neutral" category. But it seems like there is opposition to that concept, and I don't understand why. It seems like it would satisfy everyone. The untested section would be cleaner, those of us who enjoy creative builds could have an area to debate and improve things. -- BrianG 19:59, 3 October 2006 (CDT


 * That post was not really in response to you. I just changed it as an afterthought to the policy as a whole. I am all for the neutral category, but in the archived discussion there was some resistance. -- Ifer (t/c) 02:53, 4 October 2006 (CDT)


 * What makes a good build? How does one go about testing builds? Perhapse we could have some basic pointers to help people who would like to help test builds maybe a general checklist.
 * I personally feel a major drawback of the current system is there is no way of showing the really excellent builds, the good builds and the "does the job but nothing special" builds - hence my suggestion for giving marks out of 10 in the previous discussion.--JP 08:08, 4 October 2006 (CDT)


 * I never read that marks suggestion :o Anyway, I have incluided some criteria on which to base votes. I guess the truely excellent builds can be added to the list of featured builds or something like that.. -- Ifer (t/c) 08:59, 4 October 2006 (CDT)


 * Yea it was there. See 6.3.1.1 on the archive... it was waving it's arms to try to get everyones attention but was hidden by all the edits, heading and text ;o). --JP 14:13, 4 October 2006 (CDT)


 * I like that idea too JP, but I don't see any realistic implementation. The Wiki software can't average marks/calculate ranks. (not to mention how unwiki that would be.) --Vazze 15:13, 4 October 2006 (CDT)


 * Ah yes! The devil is always in the detail. :o( I don't see how it would be more "unwiki" than an arbitary good build / bad build. Still, that's a moot point given how hard it would be to maintain. ;o) I do have a decidely unwiki idea I may implement in my name space.... but I've been meaning to do alot with my namespace for a while! --JP 16:43, 4 October 2006 (CDT)

Current build procedure
In the absence of a working policy, I wrote down how stuff is usually done with regard to builds at the moment: User:Xeeron/Current build procedure. --Xeeron 08:13, 3 October 2006 (CDT)

Better way of voting on builds?
I find that if I look into the builds section for 'untested' or 'stubs' there's a TON in there and I feel overwhelmed. I have no idea how old some builds are or where to start really. I guess it would be nice to visit a new/old builds page of some sort. Let me exlain further though. I would love it if I could see a list of any new builds added to the 'untested' or 'stubs' sections (new meaning within last 5-7 days maybe) and have a list of those scheduled for deletion, as well as a list that is in between those, etc. That way, when I log in to wiki I can see what the new build status changes are and review it (maybe just a link from the 'builds' page?). As it is now I can only find new builds by scanning line by line through the recent changes pages to my knowledge and that takes waaay too long. If a build changes status (from 'stub' to 'untested' or from 'untested' to 'vetted' or from 'untested' to 'deleting soon', etc.) it would be good to see as well as have the list described what is needed (votes, changes, etc). As I see it though, this is a large undertaking and I doubt it is doable to make it automated wherein it then would require someone to do this manually every day and that isn't reasonable. Any suggestions or did I miss something that already exists?  Vallen Frostweaver  10:21, 6 October 2006 (CDT)
 * At least the list of those scheduled for deletion exists: Category:Abandoned. No list of new builds in untested though. --Xeeron 10:58, 6 October 2006 (CDT)


 * I've suggested a solution for this. A new category should be created ("Build Ideas"?).  This would be used for builds whose votes do not reach consensus one way or another (favored or unfavored) within a certain time period (such as 1 month).  This would ensure that the untested section features newer builds that should be undergoing current testing, but also creates a place for people who want to surf around for ideas or continue to debate builds.  I wish people would provide feedback on this idea (negative or positive) because so far I have gotten little response. -- BrianG 12:55, 7 October 2006 (CDT)


 * Heh, I've kinded dropped from the conversation on builds policies cause of all the indecision, but I'll note here unrefined builds already has this incorporated into it. I even called it "continued debate" for the place you call for people to "continue to debate" lol. (Not a fifty five 00:22, 8 October 2006 (CDT))


 * In this suggested policy, everything that is not edited for two weeks is concidered abandoned, and will thus leave the category. We will probably lose a lot of old rubbish that way. Not reaching a consensus is not a problem either in this policy- I have not decided on a name yet, but builds that have been voted upon enough are leave the untested category, even if people are undecided. In the end, newly created builds will be in Stubs, if they are ready for judgement they will be in Untested, and they will leave that status either as abandoned or as voted upon, both in a reasonable amount of time.. What I'm saying is that the untested category should be the new builds list you want. -- Ifer (t/c) 11:28, 8 October 2006 (CDT)


 * Yes it seems at least the three of us are in agreement with this concept (and you are who I had in mind when discussing people who want this), but who is opposed to this idea and why? I don't understand why there is opposition to this as it seems like it would satisfy everyone.  Why not create a vote on this concept and this concept only (without it being mixed in with an entire build policy)?  Perhaps it will clarify things and maybe we can get this category created!  Even if it is added to the current build policy it could only help. -- BrianG 14:03, 8 October 2006 (CDT)


 * Eh well people mainly aren't responding cause they just don't care anymore lol. The main debate of nomination vs unrefined vs two category which showed three proposals that went into the utmost detail of how to deal with all of the builds "problems" ended in a three way tie and nothing happened.  I'm only skimming what people are writing now, which are good ideas, but lack the depth the three big proposals had.  Perhaps if we called a revote?  It was silly that the "two category" system was not included in the proposals to be voted on and that probably caused the indecision.  Xeeron was right that 3 proposals would not allow for a concensus, but I think by now people would settle for a simple majority so long as SOMETHING happens.  Hell I'm just going to up and put a revote in.  Letting the three proposals all die when 80% of people said at elast one of them should be implemented is simply stupid lol(Not a fifty five 14:24, 8 October 2006 (CDT))

Revote! Settling this matter once and for all :)
Only two of the proposals up for vote were included in the last voting on proposals, I'm including every single one this time. A simple majority (whoever gets the most votes) will decide this time which category gets implemented. Please look in the archives to find the details of each proposal. Only a single one will be implemented so keep in mind which one solves the most problems fully. We can discuss merging proposals that weren't the best but had good ideas later. Note, I'm leaving refined double stage screening out only due to a practicality issue: apparently nobody in guildwiki had 50k+ faction besides me.

Updated build voting

1.

Marks out of 10

1.

Featured builds

1.

Unrefined double screening

1.(Not a fifty five 14:35, 8 October 2006 (CDT))

"removals" from guildwiki

1.

Two category system

1.