GuildWiki talk:Build vetting procedure/P1

No one is interested in discussing adding "No original author voting" to the current vetting procedure? I find this surprising. — Jyro X 18:16, 1 January 2007 (CST)
 * I'm interested, but I and, I imagine, most other people are pretty fed up with the whole "discussing build policies" thing at the moment. It's pretty silly, you can hardly turn round without another vitriolic debate on the whole subject, with various incompatible policies all trying to achieve too much too soon individually, so every single one of them gets talked to death then ignored when the combatants run out of steam. That's why I stripped out all the policy stuff from Build Split (check the history), only now people are saying that as it includes no policy, only action, it doesn't achieve anything - can't win, don't try.
 * As for this itself it seems reasonable enough. It's entirely appropriate that authors can't vote on their own builds and it should go into the policy. The problem is that very few people - contributors and admins - follow it anyway. Builds get instantaneously deleted by over-zealous admins, unfavoured votes get placed based on a fundamentally flawed understanding of the build born from never actually having tried it, new builds which are only one skill different than existing builds get posted and so on and so on. Everybody tries to shortcut the system because they think they know better (myself included), which is part of the reason why it's looking so wobbly at the moment. If we could actually get a new set of policies in place people might be less inclined to ignore them, but based on current discussions (or rather the lack of them) I can't imagine that happening any time soon. --NieA7 04:39, 2 January 2007 (CST)
 * I have to agree with the problematic review process. Builds get canned with not a single person actually testing them, with negative votes that make no sense or even refer to completely wrong builds (in one instance suggesting Life Bond I believe on a build with no monk compontent) and honestly with a lot of bias, taking builds out of context.  Admins and non-admins strike votes out, for unknown reasons (saying, "test the build first," for example, though the vetting procedure clearly says that one doesn't need to - a decision that is decidedly odd, since it can be very difficult to assess some builds without having tested them.  Counter-gank builds for example I always test with guildmates, getting them to bring teams of common gankers into the base in a scrimmage situation).  Further, while I agree that it could be assumed that an author favours a build he/she puts on the wiki, minimally an author deserves the right to vote against a build he/she puts up, if people have altered it through their edits.  While I agree that a vetting system is needed, I wonder at this choice, and the logic behind having non-tested votes counting when it says outright to please test them.--Epinephrine 09:21, 2 January 2007 (CST)

diff's and author voting
1. Is there a way to diff this from the original document? (aside from making a copy of the original in a user sandbox, then editing it with the new document?

2. Anyway, if I read this right this is about authors voting for their own builds. I could kind of care less as long as they don't sockpuppet multiple votes. Most builds don't get more than 5 votes either way (for or against) so I'm not concerned about author voting. However, if you don't get acceptance on this, maybe we should add something along the lines of "authors can vote on their own builds" to the current policy (since it stands to reason). -- Oblio (talk) 12:15, 2 January 2007 (CST)
 * Authors are too biased to vote for the build they have created and they tend to vote favored almost 100% of the time. I think authors should be allowed to vote unfavored if the author feels their own build is not good at all. --Lania Elderfire 03:34, 7 January 2007 (CST)
 * I believe that would only further complicate the situation though. Because then you're going to have people saying things like "Oh so I can say my build sucks, but I can't say it's good? How fair is that?" I think it would be much easier and a lot simpler to just bar authors and major contributors to the build from voting on it at all. That's just my opinion though. The only exception to an author or major contributor voting is if the build is radically changed from their version by another (independent; as in not told to do it by them) editor. — Jyro X [[Image:Darkgrin.jpg]] 11:15, 7 January 2007 (CST)
 * Yeah that's very true. Simple is probally much better, but for some reason I remember a case where an author decided his build wasn't good and voted unfavored, and the moderators allowed it.  I can't remember which build it was, if I do, I'll let you know. But I agree that prohibiting build contributors from voting at all would reduce the amount of bias in the voting process.--Lania Elderfire 12:38, 7 January 2007 (CST)
 * I don't have a very good context on the issue admittedly. I don't "create" builds, I only type in other peoples builds. An up vote by myself on a build that I typed in is that it worked well for me. As I only really put in farming builds, there are real metrics for saying whether the build is effective or not. That is why i am neutral on this policy idea- it is a very good idea for some build types, and isn't really a good idea for others. Anyway, i don't think it will make or break policy, so am happy with whatever the outcome is. I do think that if the build split proposal goes through, of if something like "no-original-builds" gets adopted, then this issue will need to be seriously visted. I'll refrain from further bigmouthing on this (I don't want to muddy the issue for people that it is important to) -- [[Image:Ranger-icon-small.png|25px]]Oblio (talk) 12:51, 7 January 2007 (CST)

Idea
All right, I completely agree with the fact that the current build vetting system is unreliable, how if enough stupid votes get it, the result may be unreliable. I think this is what we should do:

Make a rule: Absolutely NO SARCASM in the vetting process, to ensure that votes are true and to avoid insulting the author.

Votes for a build should be checked at around the same time every day, and vetting can only happen during certain time periods in a day (to prevent the situation where it is 3-0 but there are four unfavouring people reading the build, it gets vetted, but full opinion is not displayed). Good times might be every hour or 2 hours, for 10 or 15 minutes past the hour...? (Times can be skipped, but cannot be changed, the author has to be the one checking the stats and can only check it once for every 15 minute period)

If, at one of these checks, one side outfavours the other by three, then the author freezes the polls, places a tag on it, and the author, an admin, and a volunteer (normal user) decide, as a team, on the talk page, whether the votes actually reflect their real intention, whether the voters had tested the build, and whether they are well-based (to prevent dork votes). At this point, this "council" (through a consensus) can remove any invalid votes. It will be the "council's" duty to make compromises and reach a consensus. If one side still outfavours the other, then the "favoured" or "unfavoured" tag can be placed on it. If not, then the polls can re-open, and last like that until the next checking period, and so on.

The author can post his/her user name in the Talk Page for easier reference, at the creation of the build.

I think this makes the vetting process actually vetting and it doesn't place the vetting power in the hands of random people, as much.

This is just my suggestion, I'm still relatively new to the Wiki, so this might sound stupid... sorry if it does. 58.24.194.160 07:05, 10 January 2007 (CST)


 * I like the idea of changing categories only at certain times, though I'm not sure how it might work in practice. Maybe only move a build 24 hours after the last valid vote? The council idea, however, sounds to me like it'd be almost impossible to get running smoothly. --NieA7 08:04, 10 January 2007 (CST)


 * Time period restriction is unrealistic, and entirely unfair to some users. This wiki has users world-wide, covering a wide range of time zones.  Also, the whole council idea seems cumbersome and unweildy to me.  --- Barek (talk • contribs) - 10:28, 10 January 2007 (CST)


 * Rather than a restriction I was thinking of having a period of no less than 24 hours between the last vote being cast and a move into (un)favoured. A day is a day all over the world, such a delay would actually help people in different time zones vote for/against builds they're interested in before they're quickly (un)favoured. --NieA7 10:52, 10 January 2007 (CST)
 * NieA7 - Oh, sorry - my comment on time restriction was towards the initial proposal from anon for only voting during certain times of day. Yea, I agree with you - 24hrs minimum window is a good idea. --- Barek (talk • contribs) - 11:06, 10 January 2007 (CST)
 * You agree with me? Quick, let's get some other users in here, otherwise a dangerous bout of cooperation could break out... --NieA7 11:17, 10 January 2007 (CST)
 * That is precisely the same idea me and various other users have been discussing verbatim. I agree with the 24 hr minimum (mostly because users will post their build and get 3 friends to come vote on it really quickly so they can move it to favored before it gets any negative votes). — Jyro X [[Image:Darkgrin.jpg]] 12:19, 10 January 2007 (CST)
 * Why don't you update the proposal to include it? Nobody's particularly objected to the policy change so far, give it another week and we can put it into effect. --NieA7 12:44, 10 January 2007 (CST)
 * What I meant about the hourly time restriction is that votes can be checked only for a certain time past each hour. I don't find this restrictive for world-wide users because, worldwide, no matter which hour it is, each hour begins at the same time. And I don't mean that the author HAS to check in every hour, just that if/when he does, it be within ~10 minutes past any hour. But yes, I also completely agree with the 24 hour minimum. And, for the "council" thing, it's just to root out the invalid votes, and three people are required to do it so that the "rooting out" is also fair. The author can just post a note that votes need to be looked over, the next user and admin who sees it can talk about it with the author, and once a consensus is reached, decisions are made. This might take only 10 minutes or so if all three people are available at the same time. Oh well. 58.24.194.160 19:01, 10 January 2007 (CST)
 * I agree with 24 hour minimum too, or more specifically, 24 hours since the 1st vote. I also think that tags should only be placed on 3 days after the last vote. I also agree to having someone check for out of order, unfair or generally invalid votes. But the time restraint thing about it being at a certain hour is out of order for people say, on the other side of the world. Napalm Flame 11:55, 18 January 2007 (CST)

Votes

 * In favour of proposed changes
 * 1) Aye. -[[Image:Spiked Eggnog.jpg|19px]] Krowman [[Image:Spiked Eggnog.jpg|19px]] 19:09, 15 January 2007 (CST)
 * 2) Sure. --NieA7 03:53, 16 January 2007 (CST)
 * 3) Am I allowed to vote? If so, *stamp*. — Jyro X [[Image:Darkgrin.jpg]] 06:56, 16 January 2007 (CST)
 * 4) Not that much has changed, but sure, I'll say yes. Napalm Flame 11:57, 18 January 2007 (CST)
 * 5) --Lania Elderfire 12:03, 18 January 2007 (CST)
 * 6) Your vote here
 * Opposed to proposed changes
 * 1) Your vote here

Comments
Note: Votes, especially on policy and guidelines, are not the same as vetting (although they do use related processes). When doing a vote, it's best to add the vote category, and to set a timeline for when the vote is to open/close. See Category:Votes. The category is out of date, and the votes in it are long dead ... but it should be restored, and contains relevant information/instruction. --- Barek (talk • contribs) - 10:03, 16 January 2007 (CST)
 * Do I remember reading somewhere that votes are non-binding (and therefore pretty useless) unless the result is unanimous? --NieA7 10:18, 16 January 2007 (CST)
 * Votes are non-binding - meaning the results are not final and subject to interpretation via existing policies and guidelines. Votes are a way to get an idea of current sentiment, but shouldn't be relied upon as the primary means of determining concensus. --- Barek (talk • contribs) - 10:23, 16 January 2007 (CST)
 * I guess if nothing else they're a good way to (potentially) bring a long winded discussion to a close. Trouble with build stuff is that usually everybody gets their knickers in a twist about it and spends so long fighting that nothing gets achieved. Reckon we'd be better off with a softly-softly approach in future, changing one little thing at a time. --NieA7 05:20, 17 January 2007 (CST)

Final Discussion
Seeing as the debate here seems to be dead (has been for two weeks now), and that the community seems to be in favor of the idea that by submitting a build to the wiki, the build author is assumed to be in favor of it, this change in policy should be implemented swiftly. Discussion of the 24 hour minimum and the eligibilty of votes may continue to be discussed, and those proposals to the build vetting procedure can be made, but for the moment, let's wrap up this build author voting debate for good. If you have any strong objections to the proposed changes, and only the proposed changes, please list them succintly below. Hopefully we can sum up any oppostion to the changes concisely and move on to bigger and better things. Thnx. - Krowman  03:29, 1 February 2007 (CST)
 * Well of course I'm in favor of implementing the changes listed in this article. But I wouldn't dare presume that my opinion was the only one that mattered. x___X — Jyro X [[Image:Darkgrin.jpg]] 13:07, 2 February 2007 (CST)
 * Rolling changes are a good idea, better to get things in piece by piece than trying to do it all at once (and getting mired in discussion). --NieA7 19:16, 3 February 2007 (CST)

Wait a sec...
...something not mentioned that I've seen recently. I don't think it's a *huge* problem, but it only takes once to piss people off. The vote on this page was archived fully four (yes, four) times, for apparently no reason at all (on the first one or two). Then, the author throws in and takes out random skills and changes elites about three times, and each time he does so, archives the old vote (which is unfavored every time). I know there's a line about "If the build has been sufficiently altered to render old votes invalid, sometimes a new vote is called," but how is "sufficiently altered" defined? Is it okay for an author who cares about nothing except getting his build vetted to archive unfavored vote after unfavored vote? -Auron  03:39, 1 February 2007 (CST)
 * Well, in my opinion, that particular build should just be deleted, but as a rule of thumb, I'd allow users to reconfigure their builds enough times to get it right. After all, if one takes the communtiy's advice (which they seldom do) on his monk bad monk build, and edits it into something good, well that's good for the Wiki. One more good build to add to our collection, one less to add to the titanic landfill that is the Unfavored section. If a user acts like the one in the example, and makes changes that numerous and random, someone could always ask for an admin's help in the nifty-deletion-tools department. -[[Image:Spiked Eggnog.jpg|19px]] Krowman [[Image:Spiked Eggnog.jpg|19px]] 03:47, 1 February 2007 (CST)

Unfavored votes without testing
I think there needs to be some sort of wording to address people making Unfavored votes without testing. I stop short of requiring testing to vote because some builds will have obvious flaws or severe deficiencies that don't make sense at face value to even try, such as 2 skills required to be used at the same time but cancel eachother out. But, short of an obvious flaw or deficiency, there should be an extreme onus on the Unfavored voter to prove their case if they wish to vote Unfavored without testing. I believe that a voter that wishes to vote Unfavored without testing should be required to first state that fact in the Discussion section and fully explain the reason why...not something like "Low Damage, Point Blank Caster" which are totally generic and not necessarily a bad thing. Also if a voter wants to make the assertion that "Better build exists" then they should be required to back it up by linking to the better build that they are referring to. Only after Discussion or maybe within some arbitrary time limit should a vote for Unfavored be counted from somebody that didn't test the build. Voters that have tested a build and vote Unfavored should be required to state the problem that they encountered with the build in direct reference to the testing that they did. I think adopting something along these lines will keep a build poster from feeling that their build was just dismissed out of hand without good cause. If people can just vote Unfavored on a whim it makes a joke out of the vetting process.Turnwrite 22:30, 7 February 2007 (CST)
 * The same thing happens to favored votes too... which is why there have been and are several bad tested builds. + any high ranking PvP player voting for a Pvp build probably knows what he/she is talking about... and this kind of idea and other ideas have been suggested before but it just turns out that it really doesn't work well.  IMO most of the problem comes from people making RA, AB, CM or PvE only builds with less than ideal skill setup.  The problem is that almost anything works in those areas as long as the rest of your team is good.  --Lania Elderfire 23:16, 7 February 2007 (CST)
 * Sorry Lania, but I have to disagree with you there. A LOT more factors come into play than just that... — Jyro X [[Image:Darkgrin.jpg]] 23:18, 7 February 2007 (CST)
 * Yeah that's true... It's just that the people who cause most of the problems tend to gravitate towards those categories because those areas don't require a lot of experience to win a couple matches, or defeat a boss. So... many times you get immature teens or adults that don't understand what makes a good build and get hyper defensive when someone says "no, that's a bad build because of so and so". But from what I've seen, well thought out builds for GvG, HA etc that are not only popular but also already been proven effective by high level guilds and HA teams don't have such problems.... other than a couple of trolls complaining that its a popularity contest. --Lania Elderfire 23:25, 7 February 2007 (CST)
 * Well when you're faced with a lot of the elitists that think PvP is the only aspect of the game worth giving time to, people (with shorter tempers) tend to take on those beliefs and behaviors and it's not hard to understand why. If you had someone dissing the aspect of the game that you like to play so much and calling you a n00b all the time for playing it, I think after a while you would probably get a slight bit defensive as well. Hardcore PvP players will never fully understand the hardcore PvE players and vice versa. Just the way it is. Doesn't mean fights have to break out and insults have to be slung though. Some people that play PvE think that a lot of the PvP is really easy and for noobs and the same can be said about PvP playesr and their opinions on PvE. And that's all it really comes down to is opinion and you can't dispute that point. — Jyro X [[Image:Darkgrin.jpg]] 23:49, 7 February 2007 (CST)
 * The same can be said about voting favored on a whim too by your logic. Why should unfavored voters be required to support their opinion, but not favored? Doesn't make logical sense to me. — Jyro X [[Image:Darkgrin.jpg]] 23:16, 7 February 2007 (CST)
 * You can't require something you can't verify. You can't tell whether or not someone tested a build.  --Fyren 23:17, 7 February 2007 (CST)
 * I'm not adverse to having people explain their Favored votes either, but just in general I think there are far less dubious reasons to vote a build Favored than there are to vote a build Unfavored. Ego and Eliteism don't enter into the equation when voting Favored in my opinion.  I know, Assume Good Faith and all that...but it becomes much harder to do that when somebody just calls your build a 'poor build' without testing it and gives no explanation or a questionable explanation why.  As far as determining if someone has tested a build it is very easy, they will say if they tested the build and will be able to make direct comments of how the build reacted during that testing ex. "During Jennur's Horde I found that my energy ran out too quickly and I was not able to sustain combat all the way through certain mobs because of it." instead of ex. "I don't think this build will be energy efficient enough."  One gives evidence...the other is untested opinion.  They should not carry the same weight even if they both turn out to be true.  I'm sorry, but I don't care how much you have played the game you cannot predict exactly how a build is going to function just by imagining it...except in cases of glaring defects which can be brought up right away. Turnwrite 03:19, 8 February 2007 (CST)
 * People voting favored on their friends' builds is exactly the same. If you want reason to come into the decision, then you don't want a vote but a discussion.  --Fyren 03:36, 8 February 2007 (CST)


 * If this is about your build Build:E/A Angry Earth it looks like it already have been discussed already--Lania Elderfire 08:53, 8 February 2007 (CST)
 * OK, so maybe there is just a disconnect due to my not fully understanding Guildwiki. I am new to the process.  Is there a way for a build to be discussed without people simply voting Unfavored and moving on?  It seems to me that the voting block is just arbitrarily thrown up without any guidelines.  Maybe there needs to be guidelines as to when the voting block should be inserted, or maybe I am just missing the whole thing and there is some step that I didn't realize where the build could be discussed without being voted on?  And yes, BTW I still feel that I wasn't given a fair shake with that build.  It was railroaded to unfavored in a couple of days with nobody testing it and bringing up explanations for their vote which were highly debateable.  But, maybe it was just my fault for not realizing there was a way to have the build be discussed w/o being voted on?  By the way Lania if you think that a discussion is just people dropping their opinion down then not bothering to come up with a response when their opinion is questioned then that is part of the problem.  That is not a discussion.  People should not assume that they are the God of GW and don't have to bring up evidence for their opinions when they are challenged.  Even if it is my fault because I missed a discussion step before putting the build up, what happened on that build was not a discussion.  To characterize it as such is just not accurate. Turnwrite 12:13, 8 February 2007 (CST)
 * Leave the build as a stub rather than putting it in the untested section. Then politely ask some people to look at the build you made and ask what they think of it.  People can't vote when it is stubbed, though some people break those rules. --Lania Elderfire 16:49, 8 February 2007 (CST)
 * OK, well that explains alot. Thank you for clarifying that.  Is there any section on Guildwiki suitable for soliciting comment on build stubs? Turnwrite 18:26, 8 February 2007 (CST)
 * No section particularly, perhaps that's something that can be addressed in the future. By the way, if your build is stubbed and not catagorised feel free to remove any votes/rate-a-builds that come along. Stubbed builds shouldn't be voted on, simple as that. --NieA7 18:33, 8 February 2007 (CST)


 * The available guidelines specific to builds can be found at Build vetting procedure, Style and formatting/Builds, and Writing good builds. There are also a few templates and other items, but that covers the majority of it.  --- Barek (talk • contribs) - 18:43, 8 February 2007 (CST)

I made a rough draft for a page that would highlight the build stubs from people that are looking for input from the community for comments and suggestions to make the build stronger. Please take a look and join the discussion. Request_for_build_discussion Turnwrite 21:05, 8 February 2007 (CST)

The problem I have with voting without a reason besides the 'Its bad' or 'Its Good' is that in essence a build can become favored or unfavored with no one having any idea of why. Gander over to the currently unfavored builds and look at the tags. Most simply are taged with the generic statement of the Community found it to be a poor build only a few builds have the tags explaining why. If a build gets taged as good or bad there should be a reason as to why it was tagged good or bad except for 'Cause we said so.' Builds should require you to test them (the section is called tested not looked at and thought it was good) and a reason should be given (again positive or negative) simply because if you did test it you have an idea of why it failed or passed and many times simply looking at the reason given can prove if the voter tested the build (or even fully read the instructions on its use). Besides commenting on why you voted yes or no to the build shouldnt be about justifying to the creator that is works/fails it should be about informing the person browsing the section why it passed or failed. This is one of the reasons I stopped looking at builds here, I got tried of simply seeing tags and votes but nothing to explain how they reached that conclusion. Sure there is a discussion and a build stub section to help create, prefect and inform but again the vote should be geared to inform the browser looking at the build to decide if it is for them not the author and certainly not the voter. At least thats what I think.

My last build is a good example of this. I think users should at least give reasons as to why they unfavor builds. I try to every time I unfavor.--Nog64Talk 15:05, 25 February 2007 (CST)