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) add your name here

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)

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)