FANDOM


Auto-tally

If you want to take this policy and run with it, I'd highly suggest a bot or automatic function to tally up the votes, and rate the build independent of the users. Some users will be too lazy to update the percentage themselves, others simply won't know how to do the math. There's no insulting connotation here; I recognize that a lot of younger people play GW, and may not yet have learned to do this at school. Heck, even I would have some trouble contrasting the two vote categories, as it would be more complex than simply finding the percentage of 3/5 or 8/15. Without this feature, the scoring system will be inaccurate, without even taking human error into account. - Kowal Krowman (talkcontribs) 07:16, 3 May 2007 (CEST)

I agree. The proposal even suggests it already at PvXwiki:Percentage_Favored_Vetting#Script, but no script exists yet and I don't see any comments above from anyone who knows how to code it and is willing to do it.
If I knew how to script, I would love to help out. Eronth 21:16, 3 May 2007 (CEST)
I might be able to write the script. My question would be how we want to implement it. Do we want there to be like a "button" that people could push that would update them, do we want a bot doing it, do we want it to update whenever some adds a vote to the RAB section? DE Sig Test 2 *Defiant Elements* +talk 00:12, 4 May 2007 (CEST)
This is how I see it ideally: A third tab is added called "Vote". It displays the the basic RaB list but with a blank to add your vote under favored or unfavored. Admins have the authority to edit any vote while regular users can only change the vote they submitted. A code is added in the template that corresponds with the percent from the vote tap and updates automatically. The template updates the category based on the range that the percent enters. I'm not sure if it all could be done but that is how I pictured it. --Sefre SefresigTalk*Cont. 00:28, 4 May 2007 (CEST)
This is how I would like to see it implemented: Each time a build's talk page is edited, a script is run automatically, which puts the percentage of favoring votes on the build page. The same script can also change category tags (however, I don't care much about categories, I favor a search engine). Coding the script itself is trivial, implementing it such that it's triggered atomagically is possible. If nobody else looks into this, I will do it as soon as I've got time for it (after may 14th).
The existence of such a mechanism should not be a prerequisite for favoring the policy. Assume that it can be done. And assume also that people will be more motivated to write some code for an accepted policy than for one with an undecided fate. --Hhhippo 02:10, 4 May 2007 (CEST)
The way you guy's want it to work going to be very hard to do. You will not need an extension but more of a mediawiki hack and we are not going for that. It can be implemented only as a extension or as a special page, with other words as add-on to mediawiki script that does not require changing in the source code of mediawiki itself (hack). We have many hacks and extensions as it is to keep track of when we going to upgrade to 1.10. so what ever implementation will be it can not be a hack. GCardinal 20:05, 5 May 2007 (CEST)

Further Changes

First of all, this policy should probably be elaborated on. For example, it doesn't specify what makes a nomination biased or not. What is meant by that? That you can't nominate your own builds, or those of your friends? It's pretty difficult to prove a friendship, so that statement as-is will be entirley subjective. As well, I don't foresee many users being particularly motivated to get another user's build nominated and vetted, especially two unbiased users.
Secondly, the percentage scale is very much unnecessary with a requirement of only 5 votes. Having only five votes also restricts the percentage scaling of this policy. Until more people vote on it, a build with 5 votes can only be 0, 20, 40, 60 80, or 100% effective.
I'm also curious about the Build Moderator system. The way it is written, the BMs seem to simply be people appointed to scan the builds for disputes and relay them to Admins. This position either requires more power(i.e. just make them admins), or should be scrapped altogether. I like the idea of giving certain users more say in the builds section than others (once they've earned it); nonetheless,it shouldn't be an admin who decides which builds are good and which are bad. The BM concept right now is flawed. When a problem occurs with the vetting or drastic editing or w/e of a build, the user who feels he/she has been wronged will likely report the problem to someone to resolve. Basically, a BM would have increased responsibilities, but with no extra tools or powers, which a moderator would need if two users simply refuse to get along.
P.S. Sorry about the long post. - Kowal Krowman (talkcontribs) 05:42, 4 May 2007 (CEST)
I see your points about the build moderator idea. I'm not sure if this portion of the policy is needed, I'd rather try it without BMs and judge how things are working. We can always appoint BMs or more admins if needed. In regards to the comments about percentage scale, yes with only 5 votes the percentage scale will not provide much accuracy, but the idea is that the votes will accumulate over time and the percentage rating will grow more accurately as the votes continue to come in. This allows for a more flexible rating system over time. The minumum is only there because with less than 5 votes it would be meaningless to assign the build a rating. We could increase minimum if you wanted but then it may take longer for the build to be initially rated. -- BrianG 19:40, 5 May 2007 (CEST)
A few more points. As GCardinal was getting at below, the whole idea of revoting 24/7 is problematic. A system of constant evaluation/rating would be much more responsive to the meta and would allow for much more precise percentage scores for the builds. For this, I think the Notify Build Testers policy is useless if there is going to be constant voting on a build (which there should be, for reasons stated abpve and below).
However, for builds that are nerfed or have fallen from grace, it is assumed under this policy that their scores will continually plummet until they are deleted. What we need here is something like the Archived section of GWiki, so that the wiki can document builds that used to be popular pre-nerf. These builds would be exempt from voting, but would be maintained purely as a historical reference.
One other idea that GCardinal inspired is this policy's lack of a naming convention. Below, he describes his build the 'Solo G,' a SoA solo farming monk. It was renamed to something like SoA Sliver to be more descriptive of what the build is. He disagrees with this, but I fully support some kind of naming for the builds here. It will make the builds ridiculously hard to navigate. For example, if a user/player is looking up what a 'Shock Axe' is, as he has heard that namebeing thrown around in the game, he will have a bloody hard time finding it if all the builds have names like "Solo G," "Cupido." or "Champion of Champions" etc. The builds we host should have names that are descriptive of what they are, what they do (such as Zealous Prot, Shock Axe or Touch Ranger). Otherwise, this site will become useless to inexperienced users, the people who need it the most. - Kowal Krowman (talkcontribs) 20:50, 5 May 2007 (CEST)

Discussion

Seems to be a very good policy. Favoured. Napalm Flame 15:25, 5 May 2007 (CEST)

Why was this archived? Discussion is still on-going. - Kowal Krowman (talkcontribs) 19:17, 5 May 2007 (CEST)

Agreed, doesn't make much sense to archive it. But this in my opinion is the best policy out there yet. Napalm Flame 19:27, 5 May 2007 (CEST)
Yeah I agree, not sure why the active discussions were archived. I tried to at least pull out the most recent topics and placed them above. -- BrianG 19:37, 5 May 2007 (CEST)
Have to say I agree with deleting unfavoured builds, we have way too many of those. Napalm Flame 14:12, 8 May 2007 (CEST)
Gcardinal went and archived every proposed policies entire talk page, regardless of how fresh discussion in each section was. I have no idea why...
Napalm, there is criteria to remove low popularity builds in this proposal. The builds that fall into the lowest category will be marked for deletion and deleted after a grace period.--Sefre SefresigTalk*Cont. 15:13, 8 May 2007 (CEST)

updating

There is one thing that concerns me about this policy. I will try as well as I can to explain it. A good while ago I posted a build that had a name Mo/E Solo G, it was first build on guildwiki to use Sliver Armor and how easy boss’s could be farmed. To start with it had only a few boss’s in the list as possible targets and mainly for the Ghial’s that the name Solo G. Anyway now it has stupid name of SoA Sliver even the main feature behind the build is not the SoA part but the Sliver Armor.

So let’s take that specific build as a example. To start with there was not that many people who voted for it, some old timers instantly spotted potential some people didn’t. So in the beginning it was more of 60% build. Then come The Nerf and build was almost useless and went down to 10% and was candidate for deletion, thanks to nightfall its back in business and rocking again. So now it’s a 100% build.

How you policy going to react to those changes? It works well as static system but it’s far from dynamic and without a perfectly working script and a way to Dynamically update percentage of builds even after they are favored this policy going to turn this wiki into a complete chaos as soon as first big nerf will come. So my main question is:

  • How this policy going to respond to dynamic changes in game?
  • How low rated builds can become high rated after a while?
  • Will percentage of the first vote be there for the rest of the builds life?
  • And re-voting 24x7 is not a solution.

GCardinal 20:25, 5 May 2007 (CEST)

I think what they want is for voting/rating to never stop. Once a build has 5 votes, people may continue to vote on it. That way the build's rating will flucuate with the metagame or w/e, and having more votes will allow a more precise rating than only 5. I don't see why the policy won't respond to flucuations in the game itself, if people are allowed to vote on it once it has been vetted/unfavored (as has been implied). Low-rated builds could become high rated if people vote favorably on them after they become unfavored. Under this system, the percentage score of the build would change with every vote (which is why I suggested the auto-tally above). In this way, this system would be more responsive to the GW meta than the GWiki system was. I don't think what they want here is so much 24/7 revoting; rather, a system of constant evaluation in relation to the current metagame. - Kowal Krowman (talkcontribs) 20:35, 5 May 2007 (CEST)
P.S. I remember that build. Nice work! - Kowal Krowman (talkcontribs) 20:35, 5 May 2007 (CEST)
Bahh... and how thats going to work ?.. :((( Who in the world going to vote THAT much ?... *dohh* GCardinal 21:21, 5 May 2007 (CEST)
You can always scratch your vote and change sides... --Ranger-icon-smallfrvwfr2 (talk)(contributions) 01:48, 6 May 2007 (CEST)
Keep in mind that via PvX:NOTIFY, old votes will be striken, so they won't affect the new voting. With that in mind, we needn't worry about outdated votes. When there is an update, people can easily go to the pages they've voted on and change their vote. If a build starts out with a low rating and is later buffed, the old votes won't count against it - it'll be easy to bump it up to 60, 70% if it deserves it. Also, there won't be 24/7 revoting - just revoting as the game is updated. -- Armond WarbladeArmond sig image{{sysop}} 02:51, 6 May 2007 (CEST)
I was thinking 24/7 voting was assumed. The whole advantage of this system is that over time more people will vote, statistically the accuracy will increase, and the rating will respond to metagame changes. And it will work with PvX:NOTIFY. You don't need to constantly vote, each person only votes once, and only changes their vote if an update or other factors cause them to change their mind. The new votes will come over time as more people view the build. This is basically what happened with guildwiki, people would vote even after the build was categorized. But now instead of favored and unfavored we are using more detailed categorization based on the average of the votes. I do think though that we need to adjust the NOTIFY policy a bit, to say that a full revote should only be required if the build is changed drastically, not with every skill update. With the skill updates people can just choose to change their vote if they want to. -- BrianG 06:21, 6 May 2007 (CEST)
I am willing to add some clarification to the policy so that it resembles what I've described, but I don't want to make assumptions about what you all think, please can everyone weigh in on this aspect of the policy as to how you think it should work? -- BrianG 06:24, 6 May 2007 (CEST)

Further Improvement

This seems like the best procedure to me. However, the one thing I would like to see, a la gwkb.org (horrible site with some good ideas) is a feedback page/section. After voting, a user could then give suggestions that would give it a higher score. The creator could then respond or change their build accordingly. The preceding unsigned comment was added by Twinkie Doomcaster (contribs) .

You should be able to do that already with the talk page, shouldn't you? -- Armond WarbladeArmond sig image{{sysop}} 22:10, 8 May 2007 (CEST)
You should, but perhaps we should suggest the addition of such a section to all build talk pages to help encourage constructive critisism? --Rollerzerris <!--Zerris--> 23:23, 8 May 2007 (CEST)
I agree with zerris here, it deffinently makes me mad when i get an unfavored vote thats just [1. -- Eronth 00:13, 9 May 2007 (CEST)] but the person doesnt even explain why its bad... it'd be nice to be able to attempt at improving. Eronth 00:13, 9 May 2007 (CEST)
Same, my only dislike of the Percentage based system, is the lack of reason. A person might vote blindly (Have done many a time ;) on a build, and its turns out, that person has no reason for unfavoring. It also reduces the issue of spite between users. Discussion can also dramatically improve a build. Taking it from unfavored to favored. Another major concern, is the striking of votes. It will be dramatically more complicated if we have a automated system. Readem (talk*contribs) 01:08, 9 May 2007 (CEST) (Taken from ranked user vetting)

"Best Policy"

Please remember, if we pick the best policy out of a list of policies with flaws, this site will suffer the same fate as GWIKI. Don't pass a policy just because we want to get moving, pass one that is sure to work effeciently. - Skakid9090 01:11, 9 May 2007 (CEST)

There is no "sure" involved here. That only exists in hindsight. --Rollerzerris <!--Zerris--> 01:12, 9 May 2007 (CEST)
Effeciently, not perfectly. - Skakid9090 01:14, 9 May 2007 (CEST)
Ehhhh, even so. Until we try them, there's no way to know. --Rollerzerris <!--Zerris--> 01:19, 9 May 2007 (CEST)
Yeah, I agree with Zerris, we need something. We want the best of what we have available. We can't find the flaws until we try the policy... so... DE Sig Test 2 *Defiant Elements* +talk 01:58, 9 May 2007 (CEST)
Let's try them all at the same time! :D OR we could close teh wiki off to everyone else, and test them each one at a time, over a period of like 2 years.. </stupid comment> But for realz, lots of times things dont quite work out, we should get a way to effectively change from one failing policy to a new "yet-to-fail" policy Eronth 02:01, 9 May 2007 (CEST)
Well... the method is already about as efficient as it is going to be. The current method is: Somebody (well, a group of people) decides that the current policy isn't good for X reasons. Then, they either revise the policy, or they submit a new one. Then, we pick. Done. That is about as efficient as it is ever going to be. To be honest though, I don't think we really want to be CHANGING policies all that much. The point of the vote is to pick the best one. So, it is likely, that, unless a policy absolutely tanks, rather than actually choosing a new one, we are more likely to merely revise the original. DE Sig Test 2 *Defiant Elements* +talk 02:05, 9 May 2007 (CEST)
There is no such thing as The "best" policy. At best, we'll find one that works. Let's just be realistic. Readem (talk*contribs) 02:06, 9 May 2007 (CEST)
Oh come on, don't argue semantics, everyone understands that best means best among those that exist (i.e. realistic). DE Sig Test 2 *Defiant Elements* +talk 02:08, 9 May 2007 (CEST)
Well, so far, half the Build Policies are just ideas on paper. Most, if not all have HUGE flaws in them. So we need a system that is realistic, and can be promoted and finished with in the next 7 days. And Defiant, I am agreeing with you. I can almost assure you, an improved wiki system is what we'll be using for several months. Why? Because it works, and isn't much of a hassle lol. Readem (talk*contribs) 23:48, 10 May 2007 (CEST)

Quality control

Please make sure that this policy has all things required to pass quality control. Please read PvXwiki:Voting on Vetting Policy.

IMPORTANT!

Make sure that your policy meets all of above requirements or it will NOT become a candidate and people will NOT vote for it.

  • How new builds will be posted.
  • How new builds will get into actual vetting procedure. (short)
  • How discussion and voting/vetting will be done.
  • How re-voting will be done. (short)
  • How deletion of builds will be done. (short)
  • How builds will be organized. (optional)
  • How it will affect existing builds. (short)
  • If policy needs mediawiki extension, who will make it? (short)
  • Plan on how to make a script (if needed).

GCardinal 22:00, 10 May 2007 (CEST)

Is it ok if builds are organized via PvX:NAME, deleted via PvX:DELETE and PvX:WELL, and re-voted on via PvX:NOTIFY? -- Armond WarbladeArmond sig image{{sysop}} 23:18, 10 May 2007 (CEST)
Strict guidelines before voting is a horrible idea, once people have a chance to vote they will bring up issues and way to fix them, such as the stuff mentioned above. Rushing people to fix all the above issue before will just leave potentially good ideas down.
Now, who knows how to write a extension for the voting idea on this policy and is willing to do so?--Sefre SefresigTalk*Cont. 01:08, 11 May 2007 (CEST)
I guess we can recruit Hhhippo to do it for us... He can do it as of May 14th he said. I'll ask on his talk page. --User Frvwfr2 signature frvwfr2 (talk)(contributions) 14:44, 11 May 2007 (CEST)
What strict guidelines do you mean? Is it really that strict to tell people to post new builds 1. in the build namespace, 2. with the professions abbreviations first, and 3. with a short description of the build? It's not hard, and it's what most of us are used to. WELL and DELETE are staying whether or not we mention them in here, they're vital to the wiki. Same with NOTIFY once it's accepted. Did I miss anything? -- Armond WarbladeArmond sig image{{sysop}} 20:11, 11 May 2007 (CEST)

Starting out

Ok, I'm messing with the policy as per Cardinal's post above. The major thing I have is that a build must start out as a stub. I myself have created a number of builds that certainly weren't stubs. Anyone with half the brains god gave an artichoke can fill out enough to not make it a stub - what equipment is needed, what skills and attributes are needed, and how to use the build. Counters and variants can be figured out as the build is tested. I propose to put a build in new builds first and from there, if necessary, put it into stubs or wait for nominations. -- Armond WarbladeArmond sig image{{sysop}} 22:32, 10 May 2007 (CEST)

I'm also considering making Template:Build, which would merge Template:Build-stub, Template:New build, and whatever template we use to display the percent vetting and categorize the build. -- Armond WarbladeArmond sig image{{sysop}} 23:42, 10 May 2007 (CEST)
Community content is available under CC-BY-NC-SA 2.5 unless otherwise noted.