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)