Note: Please observe the difference between criteria and categories. Criteria are the different aspects of build quality that will be given a 0-5 rating. Categories are part of the wiki mechanics and in this case are used to sort builds according to the results of the rating process.


There's now a draft and a separate talk page for discussing the criteria. Please use it! --Hhhippo 21:39, 4 June 2007 (CEST)

Loose ends from archived discussions concerning criteria:

  • Hhhippo suggests: Should the "Strength" criteria be split into something like "Power" and "Usability"? Not so experienced players might look for a build that they can handle, and accept that it has limited power, while others don't care how difficult a build is to use (or to get the equipment) but want maximum power for a difficult task.
  • Shireen suggests: Idea should be changed to Concept, as it's a stronger word to reflect the attributes meaning. You may want to change out Strength with 'Overall' or another neutral evaluation word, as strength alludes to damage output, and seeing low damage output may skew voters perception.
  • The following threads have been moved here as sub-sections: --Hhhippo 21:23, 3 June 2007 (CEST)

Improvement suggestion on Score calculation and voting categories

Any build can be described by the following voting categories:

  • effective
  • innovative
  • adaptive
  • universal
  • easy to use

  • Effective is simply a word that describes better what Strength is in the original version.
  • Innovative is carried over from the original version.
  • An Adaptive build would be a "paper" build that stands a chance against "scissors". If you are a ZB bonder, you can always leave the bonds when facing enchantment stripping, and just use ZB and whatever other spells you have. If you are a warrior, you can always use an interrupt or a knockdown to stop that anti-melee necro.
  • A Universal build is one that can be used in more than one location for the same purpose. I have deliberately changed potential into these two voting categories, because these describe better what potential is meant to be, and this way they can be weighted differently in the total score.
  • A build that is easy to use (couldn't think of a better name) is obviously easy to use. People want easy builds, so why not give them this voting category.

Now, these categories have to be weighed.

  • A good build has 65% total score.
  • A build that gets the maximum score on both Effectiveness and Ease is a good build.
  • A build that gets the maximum score on both Effectiveness and Adaptive is a good build.
  • A build that lacks innovation, universality or ease can still be great.

So Effectiveness, Adaptive and ease are the core scores.

The other two are less important; the innovative part is hardly interesting for a total score.

I suggest these categories are weighed at 50%, 5%, 20%, 10% and 15%

Ifer - 09:47, 22 May 2007 (CEST)

Err, more like a build's performance should count for at least 80% of the build's rating. I would prefer 100%. - Kowal Krowman {{sysop}} 02:06, 26 May 2007 (CEST)
No. Here's why. Say I have an Assassin boss farming build that can kill the target within a second, but takes ages to get right, is not useful versus any other boss and can't deal with bad mob spawns. That build would get the maximum score in effectiveness, but can hardly be called a good build. -- Ifer 00:12, 27 May 2007 (CEST)
Uhh, and what exactly is wrong with that? You can't expect to instantly, or even quickly, master any build. Builds should be specific to their environment. If you want to farm a certain boss, you fill your bar with skills that can get you to him, defeat him, and survive his mob. Those specific skills will vary depending on him, his mob and the critters between you and his spawn. If the build can successfully farm that boss, then yeah, it would be an effective build. Srsly, under your logic, any farming build or team that is set to farm one area (I'm thinking DoA, the old Urgoz, the Deep) would get a lower score because it can only work in that specific location. Who cares? If it can farm that location well, it is a good build. Btw, I seriously doubt your hypothetical build could ever be realistic, and therefore has very little value as a demonstration of why my argument phails. - Kowal Krowman {{sysop}} 06:38, 27 May 2007 (CEST)
Great build is not the one that can farm W boss's and run away. Great build are the one that can be used every where and still work 100%. The whole idea with this policy is to split lame W solo builds from builds that is Great. gcardinal 15:05, 4 June 2007 (CEST)
RA builds =/= GvG builds =/= PvE builds. No build can be used everywhere. If a build like that ever came into existence, then we could justify sorting builds under that criteria. Until that point, having a build's Innovation score affect its rating will just give viable builds a lower rating, with no real benefit. Having the Innovation score displayed alongside the Strength or w/e score, and having it as a searchable criteria, would be great, but not having it influence the build's overall rating. Imagine what would happen with common, tried-and-true builds under this system. Shock Axes would get low scores, because they have all the staples of good Warrior builds. 55-style farming builds' scores would drop, because the idea is hardly original. Good Monks would lose points because they have hex and condition removal components, maybe some e-mgmt, survivability, etc. These builds would all suffer, while builds like this one would succeed because it may be the best use of a bad elite. People use certain skills for a reason: they are good. Similarily, people don't use other skills because they are bad. A build using these unpopular, bad skills should not be promoted on the wiki over solid builds like the ones listed above. The only positive aspect a set of criteria such as these would provide would be to build authors, who could take some sort of pride from the fact that they made a highly-rated Fox's Promise build. It would not help anyone who came to the wiki looking for advice; it would only make their search more difficult. - Kowal Krowman {{sysop}} 14:09, 18 June 2007 (EDT)

The rating system fails at the moment. Innovation should not be a criterion at all. The very best builds in the game are the ones that are used most (particularly in GvG where bad ideas die fast and good ideas spread round the world in hours), so they should be rated 5 for Effectiveness, 5 for Universality and 0 for Innovation. On the current system that gives them an overall "Good" rating, which is just stupid.

The big problem with gwwiki and now with PvXwiki has always been that it was missing many of the basic builds that everyone uses, but had a lot of random "innovative" shit that didn't actually work very well. The current system only reinforces the problem. I Noob I 04:55, 4 July 2007 (CEST)

I hear ya bud. That's my pet peeve about the RV system, and I have been trying to have it changed to having Innovation as a sortable criteria rather than a component of the build's total score. As a temporary work-around, just give a good build a 5-5-5 rating and keep reinforcing the proposal here. - Kowal Krowman {{sysop}} 11:48, 4 July 2007 (CEST)

Naming of Categories

The nomenclature for the criteria should look as follows:

  • Strength should be replaced by Effectiveness
  • Potential should be replaced by Universality
  • Innovation should be replaced by Ingeniousness

That should help clarify the meaning of each, and it makes them look more uniform. The various standards for 1-5 ratings for effectiveness can be found below. In the cases of Universality and Ingeniousness, the ratings are more straightforward and we felt descriptions weren't necessary for each level. DE Sig Test 2 *Defiant Elements* +talk 07:26, 1 June 2007 (CEST)

Sorry my bad english... but maybe you can find another word for Ingeniousness... I had to read it 3 times before I got it. Can be hard to non-english users. gcardinal 14:53, 4 June 2007 (CEST)

Description of Numerical Values

  • 5 = This build excels amongst its contemporaries. It is well-received by the Guild Wars community, and worthy of PvX Build's highest rating.
  • 4 = A build whose qualities demonstrates better than average capabilities in a realistic environment.
  • 3 = A build which has all necessary prerequisites in order to achieve the minimum level of effectiveness required to qualify as an acceptable build.
  • 2 = This build does not function adequately, either because it features an innefective concept or lacks the necessary elements of a better build.
  • 1 = An ineffective build as defined by PvX:WELL.

- Kowal Krowman {{sysop}} 08:01, 1 June 2007 (CEST)

Category names

Doesn't it sound strange to put candidates for deletion into a category called 'Archive'? Shouldn't we skip the two-stage structure and just call the categories Great, Good, Archive and Trash? --Hhhippo 20:45, 22 May 2007 (CEST)

On a side note, I agree with Hhhippo, it would be better if the categories were renamed to simply "Great, Good, Store, Trash"... or possibly replace "Store" with "Archive". To denote builds as "working/great" would imply that there could be "not working/great" builds as well. When a build falls out of grace for whatever reason, like skill changes.. then it would go to "store" or "archive" where I think it should show what the previous score was for the build and why it doesn't work as well/at all anymore. "Great" for builds that currently work very effectively (based on score), "Good" for builds that work fairly well, may not be very user friendly.. or very universally effective, but still good, "Archive" (or store, whatever) for builds that had previously been favored but have fallen out of grace for whatever reason (had once been successfully vetted), and "Trash" for builds that did not pass the vetting process. But if you wanna still use the 0-5 scale, I would suggest just labeling them "Great, Good, Ok, Bad" or something like that.. store/trash are essentially mislabeled if it's just based on average vote. -- Spore 20:20, 30 May 2007 (CEST)

Some more points about categories:

  1. What's the name of the category for builds that are not yet ready for testing/vetting? The policy says "Drafts", currently we have "Build Stubs" for essentially the same purpose.
  2. How do we indicate that testing can begin? Move from "Build Stubs" to "Testing" as before? And does that automatically trigger the rating tab? Will "Testing" have the known usage subcategories (PvP, PvE,...)?
  3. Once there are enough votes, builds will automatically be moved to one of the 4 quality categories by the extension. Do we have consensus about the names of these categories being "Great", "Good", "Archive", "Trash"? Any opinion on replacing "Archive" by "Store"?
  4. How do the usage categories come into play here? As subcategories to each of the quality categories? Or do we forget about the wiki category concept here and leave the filtering to the new search engine?

--Hhhippo 19:09, 5 June 2007 (CEST)

Build modification after voting

What if, based on poor ratings, the author makes significant changes to his build that should result in higher ratings? Will the original ratings still count against him?

What if an author creates a cookie-cutter build to garner initial high ratings and then changes his build dramatically to be something esoteric/creative, so that the high votes give his weird build exposure it would not normally get?

My point is, while I have nothing against this vetting system, why the hell are you implementing it on a wiki? Why not just write your own simple CMS based around this concept? Wiki and this system are diametrically opposed.

Tanaric 03:07, 1 June 2007 (CEST)

Significant changes (good or bad) could be the basis for a re-vote, but has that ever been much of a problem? Over at Gwiki, if someone changes and breaks a good build, someone else would come along and fix it. The central ideal behind a wiki is that people are generally good, not bad. Look at everything people have been able to create with a wiki. Yes, there are some vandals and troublemakers, but that's what we have administrators for. If someone is motivated to get their build vetted, they are not going to be constantly changing it, and constantly having it sent back to Untested. In theory, it could be a problem, but in practise, it never really has been. - Kowal Krowman {{sysop}} 04:15, 1 June 2007 (CEST)
No, you misunderstand my concern. Under this system, a build seems to be "owned" by its author. He has every right, then, to change it later as he sees fit.
Beyond this, it doesn't matter that people are good. If being good means not significantly changing your build after its posted, and if being a vandal means altering somebody else's build, why use a wiki in the first place, where significantly changing your content and editing others' work is the name of the game?
Tanaric 05:07, 1 June 2007 (CEST)
I don't understand what problem you see in it, when a build needs to be changed of people want it to change they discuss on the talk page. It happened at guild wiki and will happen here. Discussion is just where changes should be and if they turn out to be accepted by people then it will be changed, if the changes are dramatic it would be thrown into a re vote. --SefreSig 05:29, 1 June 2007 (CEST)
Hmmmm... I think I see your point Tanaric, on the other hand, I fail to see how this system would directly cause a severe deviation in the way things are run. As Krowman points out, if a good build is broken, people fix it. If the opposite occurs and a build is significantly improved, then we re-vote. Although it will have to be edited as a result of voting within an extension, PvX:NOTIFY provides a good core structure for the specifications for a revote.
Again, perhaps I am missing something, but why does this system imply ownership. The fact that votes can be reevaluated/changed by the original voter, combined with the fact that Administrators can render old/incorrect votes null and void appears to limit the impact of such an issue. If content changes, we can still change the votes. Based on my limited grasp of the coding that goes into an extension, I see no reason why we couldn't a) Only allow the last x votes to count, or, b) allow an option so that Administrators can simply click a single button to restart the vote count.
Because of the aforementioned flexibility that can be built into the program, I fail to see a significant change from the GuildWiki system, at least as far as the problems you have brought to light so to speak.
DE Sig Test 2 *Defiant Elements* +talk 05:31, 1 June 2007 (CEST)

Alright, I'll start this thread over, because people are only seeing one side of what I posted and aren't coming to the point I need them to. :)

This is a pretty good vetting system. However, one thing is important to it: the build article needs to be somewhat static. If a build changes significantly, the votes need to be reset. Why are you using a wiki as a backend for a system that relies upon the builds being mostly static? It seems a system in which only the original build editor can edit the article makes more since, with perhaps a comment system for limited collaboration. Such a system could be implemented in your language of choice far easier than a wiki extension. I just don't see the benefit of using a wiki backend here.

Tanaric 10:59, 1 June 2007 (CEST)

That is actually a very good point. I still think a wiki is a suitable backend, since there are various reasons for editing build articles. However, we need clear regulations on who may when do what kind of edits to a build, possibly as a policy of its own. Here are some suggestions:
  1. While the build is a Draft/Stub in the Build: space, everybody may edit it. Edits should aim at improving the build itself or the article, and not turn the build into a completely different one. Consensus with the original author should be sought.
  2. Once vetting has begun, only minor edits should be done. Minor edits are corrections to grammar or formatting, adding of variants or improvements to the build's description that don't change the build itself.
  3. If there is a need for a major change, e.g. as a reaction to changes in the game, consensus should be reached on the talk page before doing the change.
In case of a major change to the build or a relevant change in the game, we need a policy for re-voting. Something like PvX:NOTIFY, adapted to Real Vetting. A possible solution might be putting the build back to testing and de-activating all votes given before the change (but leaving them visible). I'm not so sure if one needs the notification part, since voters should have the build on their watchlist. Btw: Will voting put the build on the watchlist automatically? Obviously, this needs to be fleshed out... --Hhhippo 19:41, 5 June 2007 (CEST)
I wouldn't bother with the auto-watchlist voting. If ths site becomes at least as active as GWiki's build section, users may be voting on dozens of builds a day. That'd clog up your watchlist pretty quickly. As well, if a user wanted to see of a list of every build that he or she has voted on, they could just as easily use the contributions page. - Kowal Krowman {{sysop}} 00:29, 7 June 2007 (CEST)
Votes are not static. Each user can rate a build, he is free to edit it whenever he wants to, he can delete his vote and administrators can "rollback" vote - "rollback" will remove the vote with given reason. User is free to come back and re-rate build if his rating was removed. I do understand concerns about significant changes in build and how it will affect ratings. However W/Mo will stay W/Mo and will never end up R/E.
This problem is quite big not only here but on Wiki sites in general. One way to solve it are by introducing revisions. All builds will start with revision 0.1 and each time build undergoes significant changes revision of the build can be updated (by admins, build masters etc) to 0.2. Each time new revision is approved by admins/buildmasters/superusers/etc can choose level of importance on changes that was made.
  • Level 1 - just updates revision number
  • Level 2 - Some changes was done, most of the minor so only notice on the build page where it will say "Please check your votes". Users will re-view them ratings to make sure that everything as it supposes to be according to new revision.
  • Level 3 - some major changes was done and all current ratings call for new rating. All current ratings will be moved to "Ratings for revision 0.x" and notice to all users who originally rated this build will be sent so they can come back and rate build again.
And one again many changes can be done 1-10-100 before new revision/version is decide. It will depend totally on each build. This revision system will go well with "work-in-progress-bar" idea that I liked so much. Where work status can be changed along the way. And when it reaches "ready to rate" or something people will rate it. Anyway they are just some ideas and we are not going to implement them all right away, but I see revisions are the only way to efficiently control work flow. gcardinal 09:00, 6 June 2007 (CEST)
Revision system could work fine. - Kowal Krowman {{sysop}} 00:29, 7 June 2007 (CEST)


I archived a huge part of this page and rearranged the rest a bit. I hope I didn't violate any written or unwritten policies in the process. Please assume good faith. I suggest to start new discussion threads as sub-sections of the existing sections, as far as appropriate. Threads that become too lengthy should be moved to a sub-page. --Hhhippo 21:23, 3 June 2007 (CEST)

There's no actual rule governing archiving of talk pages, so you clearly haven't violated any rule, written or otherwise. The fear of course is simply having someone archive too much, for example if an active section/thread was archived. DE Sig Test 2 *Defiant Elements* +talk 23:54, 3 June 2007 (CEST)

voting categories

What the final on voting categories? I remember asking this question several times and still I dont see a final list with names and descriptions. Please take into consideration post from anonymous users he/she had some really good points that I support. Ones again start, discuss and provide a result in form of list with categories names and description. This is 3rd reminder so please do it or I will decide on it my self. gcardinal 14:59, 4 June 2007 (CEST)

Just to be sure: do you mean categories or criteria? (Well, we need a decision on both, anyway.) I'll post some thoughts in the (european) evening. --Hhhippo 15:18, 4 June 2007 (CEST)
Hi Hhhippo, I am not sure how to name then but its about * Idea – 15% * Potential – 15% * Strength – 70% . new names and full and complete description. They must be easy to understand and be representative. Mistakes here can lead to many problems and miss understanding here. gcardinal 15:32, 4 June 2007 (CEST)
I made a draft and a separate discussion page for that. Let's see what happens. --Hhhippo 21:39, 4 June 2007 (CEST)


I have spend some time on this extension and I got this idea. It may look like to much on the first look but I think it will make sure that people understand what they are ratings actually mean. A few ideas:

  • After rating is submitted user will see textual representation of his votes, total score and what kind of category build will end up based on this users vote. After that user will have to confirm and save rating or to cancel and edit.
  • Textual representation: if user rate 3 on Effectiveness text describing that will be shown. And on overall rating 0-20, 20-40, 40-60, 60-80 and 80-100% will also have they own text comments that will be shown to user.

All this is to make sure that user fully understands what he is voting for.

Another thing that will maybe make this system even strong: build masters. Idea introduced in some policy's. The basic of it: Vote from build master counts for 3 ratings, admin rating counts as 2 and user rating counts as 1. This will ensure that everyone will have a chance to cast they rating and as the same time it will be ratings from high ranked users to use as reference or guideline.The preceding unsigned comment was added by Gcardinal (contribs) at 09:45, 5 June 2007 (CEST).

Good ideas, I support both of them. I guess Build master and admin votes will be marked as such in the list of votes, right? --Hhhippo 12:15, 5 June 2007 (CEST)
Yes they will be marked very clearly. gcardinal 12:48, 5 June 2007 (CEST)
Why should some users get more power then others? I thought the point of the build master or moderators was to manage votes and get rid of in valid ones?--Aliri 20:06, 5 June 2007 (CEST)
And who votes these "build masters" to their position? The other "build masters" with similar opinions? - Skakid9090 20:46, 5 June 2007 (CEST)
I feel some deja-vu regarding this discussion. Should we first get everything else up and running and put the idea of higher counts for build masters and admins on hold for now? It can be discussed later, in terms of a separate policy, and if approved be included in the rating system. --Hhhippo 21:17, 5 June 2007 (CEST)
With the system that allows admins to strike out votes that don't correspond with the build it should get rid of the need to give people higher ranks, if a user gives a bad vote where they say its just good because it works they will have to be stricken out or clarify. If each voter is forced to completely explain the vote then it just about removes the experience levels and all votes would therefore be equal.--Aliri 23:16, 5 June 2007 (CEST)

Yes, the combination of the ability to strike votes and having a higher-ranked vote is a bad one. The potential for abuse is too great. While it certainly would be nice if I were able to just tell people that a certain build is good and not have to go through the vetting procedure, the downside of the idea outweighs its positive aspects. I know we wouldn't be giving the priviledge to people we don't trust, but we really don't need that kind of system here. I strongly disagree with the ranked votes idea at this stage in the wiki's development. - Kowal Krowman {{sysop}} 08:09, 6 June 2007 (CEST)

/Agree Readem (talk*pvxcontribs) 08:35, 6 June 2007 (CEST)
I nominate Jupsto as a build master! - Skakid9090 00:34, 7 June 2007 (CEST)
That's not "constructive." - Kowal Krowman {{sysop}} 00:40, 7 June 2007 (CEST)

Yeah, I have to agree with Krowman, while I think that perhaps we may need more people to control the number of vote (i.e. more people with the ability to delete votes, etc.), Ranked Voting gets a no from me, and, at this point, I would vote to table the entire issue in favor of focusing purely on the necessary aspects of implementation. We can discuss this all later, for now, I say we drop it. DE Sig Test 2 *Defiant Elements* +talk 01:04, 7 June 2007 (CEST)

Sorry if this violates some policy buried away somewhere, but ranked user voting is a load of f***** b******. Favouritism in a sense, it's semi-corrupt in the way that it can easily become corrupt and it's just not even. It's not DEMOCRACY anymore (Thinking back at this, what if it's communism...?), which is basically what this wiki is about. I strongly disapprove of this idea. I bend over and present my 'le derriere' for a nice spanking. ~~ Napalm Flame ^_^ Napalm Flame Sig Image (talk)(contributions) 14:54, 10 June 2007 (CEST)

First of all ranked user voting is not going to happen as you maybe can see from comments above and it was just and idea for discussion. And second of all please don't use f-words, you can make your self perfectly clear without them. gcardinal 18:45, 10 June 2007 (CEST)
Okay, won't use them, just couldn't help it because I feel so strongly against things like that. ~~ Napalm Flame ^_^ Napalm Flame Sig Image (talk)(contributions) 19:58, 10 June 2007 (CEST)
Yeah and I feel strongly for ppl that are not around when so f**** much need help, but s... happens :) gcardinal 20:46, 10 June 2007 (CEST)
Now now, don't be hypocritical. ;) ~~ Napalm Flame ^_^ Napalm Flame Sig Image (talk)(contributions) 21:30, 10 June 2007 (CEST)
I think you actualy mixed communism with a dictatorship (or how you call that in english). Communism is a economic system in the first place. :D (does it matter? Nope) Cookieaddictedmonster 06:47, 21 June 2007 (EDT)


Hey, I was just wondering if there was any ETA when this could actually be put into place.

I'm sure that it is hard work to create the extensions/systems needed but in the original proposal we voted for it claimed it would be within a week...


its been more then a week... wow, i would really like to start vetting some war builds.


Can the creator of the build rate the build or no?Mgelo21 05:16, 30 June 2007 (CEST)

Ditto the above question. Perhaps we should have an FAQ or secondary policy for the actual voting? Such as how to rate properly, what constitutes a "fair" vote, etc... explain a bit on what "Idea", "Potential", and "Strength" really mean. I would imagine the average user would be tempted to simply vote 4 across the board on a build they think is good, rather then try to work out what the difference between Idea and Potential is. --GEO-logo Jioruji Derako.> 11:44, 30 June 2007 (CEST)

You can get some explanation of the criteria as mouseover-tooltips on the 'Rate' page. More documentation is to come. At the moment we are just starting, so please be patient and keep the seat belts fastened until the captain turns of the sign ;-) --Hhhippo 14:57, 30 June 2007 (CEST)

So, back to the original question... Can the creator of the build rate the build or no? --Midnight08 21:41, 30 June 2007 (CEST)

Given that we have no consensus at the moment, let's compromise. Until we have a consensus, Author's may vote on their own builds, however, these votes will be subject to special scrutiny, and votes deemed obviously biased will be deleted. Fair enough? DE Sig Test 2 *Defiant Elements* +talk 22:41, 30 June 2007 (CEST)

Authors Voting

What is to stow authors of their own build from voting on the build? Or is this allowed now? I have not seen any notice against this. Sir On The Edge 13:36, 30 June 2007 (CEST)

Afaik there is no active rule atm. We should discuss this. Feel free to post your opinion here. --Hhhippo 15:01, 30 June 2007 (CEST)
I dont think the authors should vote on their own build since they are most likely going to rate it 5-5-5 since it is their build.Mgelo21 16:28, 30 June 2007 (CEST)
Not all of them, I predict many people will rate their own builds semifair at least. ‽-(єяøηħ) no u 17:39, 30 June 2007 (CEST)
I think its unnecessary to allow build authors to vote on their own build. Its basically guaranteed to be a biased vote. If there is technological issues with being able to prevent them from voting, I'm not too concerned about it. But the policy should at least say that they should not. -- BrianG 17:48, 30 June 2007 (CEST)
I agree. We have to face the fact that most will have some biased vote. Although some may be honest, that can't stand in the way of majority situations. --NYC Elite 18:00, 30 June 2007 (CEST)
See here for mine and Auron's opinions. - Kowal Krowman {{sysop}} 18:46, 30 June 2007 (CEST)
"Trust"? Readem (talk*pvxcontribs) 19:32, 30 June 2007 (CEST)

Given that we have no consensus at the moment, let's compromise. Until we have a consensus, Author's may vote on their own builds, however, these votes will be subject to special scrutiny, and votes deemed obviously biased will be deleted. Fair enough? DE Sig Test 2 *Defiant Elements* +talk 22:41, 30 June 2007 (CEST)

Agree. And if we decide not to allow it, we can still delete all the self-votes at that point. For the further discussion: should we maybe first seek consensus on where to discuss? ;-) – HHHIPPOsysop› 22:49, 30 June 2007 (CEST)
They also need to be marked as such. Sir On The Edge 08:26, 3 July 2007 (CEST)

Why are all the builds "Good"?

Nothing is "great" and nothing is in the "other" category. what's up with the rating system?

It is still undergoing a "Testing Phase" of sorts. Readem (talk*pvxcontribs) 19:40, 30 June 2007 (CEST)
Builds which were favored at GuildWiki were put into Good as a starting point. Once they got enough votes here they will be put in categories according to the overall rating they get. --Hhhippo 19:44, 30 June 2007 (CEST)


should be specified to be when the build was created how innovative was it. - Skakid9090º_o 23:38, 30 June 2007 (CEST)

Definitly, people are already lowering a build's score because the idea/build is fairly old, or is common in the metagame. It probably found its place in the metagame because it was innovative.


cannot be rated ATM. - Skakid9090º_o 23:41, 30 June 2007 (CEST)

Were we ever planning on rating guides with Real Vetting? DE Sig Test 2 *Defiant Elements* +talk 23:51, 30 June 2007 (CEST)
I would think so. Otherwise, they can never be vetted for truth or veracity and will be "Untested" forever while actually being right (or wrong, in which case, whatever). --Mgrinshpon (C/T) 03:33, 2 July 2007 (CEST)

kick it into gear!

comon peoples if your the 5th voter change to trash or good-great ect. i've done it so many times now -_- Skakid9090º_o 16:58, 1 July 2007 (CEST)

Deleting Ratings

Is there a way to delete ratings? Because if you take an unfavored build and edit it, the rating is still there, and the rating could persuade others to rate the same.Dirk150 03:07, 2 July 2007 (CEST)

Indeed, Maybe a feature that hides other votes so that way it doesnt persuade other to vote the same. Metal enchantment 03:23, 2 July 2007 (CEST)
Admins can strike votes, I'm pretty sure they can remove them as well. In such as case as a re-vote on a previously unfavored build, you could probably contact an admin and have them remove the old votes... --GEO-logo Jioruji Derako.> 03:32, 2 July 2007 (CEST)
Jioruji is correct. Admins can delete old votes. If you substantially change a build and you wish it to be re-voted upon, simply contact an Admin, have them delete the old votes, and move the build back to Stub or Trial or Testing. DE Sig Test 2 *Defiant Elements* +talk 05:13, 2 July 2007 (CEST)

PvE Professions

I don't know where to put this, but I decided that it should go here. My concern is that some people have this mindset that all PvE builds should be looked at when deciding whether or not it is good, regardless of profession. I believe that when looking at PvE builds (no PvP, since anyone can make a level 20 right away) the only builds that should taken into consideration are builds of the same profession. For example, Build talk:Team - 2 Ranger Kepkhet Farming. I know that if I was coming to the wiki, being a semi-new GW player, and I only had a level 20 ranger, and maybe a couple level 6 or something other guys, knowing that a 55 can farm this solo, really won't help me. If this gets a bad rating, which it already has, on the grounds of another profession doing it better, it might get deleted. So the person coming to look for a build, won't find one, and wouldn't be helped. I'm just saying that something should be added to the effect of, "When rating PvE builds, only take into consideration builds of the same profession," and then maybe summarize this whole paragraph as the reason, or something like that. Bluemilkman 17:52, 2 July 2007 (CEST)

Abso(lute)ly agreed. ‽-(єяøηħ) no u 19:24, 2 July 2007 (CEST)
There is a difference between, "This Build is generally less effective then a 55" and "This Build is only comparable to a 55 in one way:They both can farm." That Duel Ranger Build requires a full party of Hench, AND 2 people. It is does not qualify as an efficient farmer, as KR is worth so very little anyway. If you can farm Rago's with two rangers, sure. But such a simple boss a Kephet does not qualify. Readem (talk*pvxcontribs) 22:39, 2 July 2007 (CEST)
Perhaps that particular build is a bad example, but I agree with the original point. Just because another profession can do a particular job a bit better, doesn't mean the first one sucks. In the case of a farming build, there's plenty of options as far as profession, and it stands to reason that one choice will be slightly better then the rest. Take Totem Axe farming; there's a Ranger build, and a Warrior build. Both do the job well; there's no reason why either one of these shouldn't get vetted. But there's always going to be people voting that "this build sucks, because Warrior does it better", etc...
Farming in particular, we could always make disambiguation pages... someone's looking for a Totem Axe farming build, they click Totem Axe Farmer, and it brings them to all the choices. Or simply stick with the current setup; there's a "Related Articles" section for a reason. If someone has access to both a Warrior and a Ranger, they can find out which is more efficient. In any other case, they'll pick a build based on what they have available. --GEO-logo Jioruji Derako.> 00:59, 3 July 2007 (CEST)
That is simple to decide. There is no "Profession Bias". It's merely a matter of "Does this Build work well?" Sure, a Build might be able to farm a certain boss, but if it takes two hours, and a 55 can do it in 5 minutes then the build simply does not qualify. Readem (talk*pvxcontribs) 02:34, 3 July 2007 (CEST)
Obviously, any build that takes two hours to farm shouldn't get vetted. The only problem is when a build takes, say, five minutes longer to complete a run, but is voted down because the other's five minutes faster. Builds need to get ratings based on how well they work, not how well they work compared to other builds in different professions. This is usually common sense, but I'm not sure that we have any voting policy on it at the moment. --GEO-logo Jioruji Derako.> 05:30, 3 July 2007 (CEST)
Builds get vetted based on how well they work, not how well they work under certain circumstances (i.e. "profession bias"). If a monk can farm anything better than a ranger, the monk should get a higher rating. If we continue to invent all these niche criteria, we will have bad builds getting good ratings (like the "best use of a bad elite" situation). If you submit a farming build that farms less effectively than another, be prepared for your build to get a lower rating. Simple as that. - Kowal Krowman {{sysop}} 05:48, 3 July 2007 (CEST)

I just want to make sure you know that this only applies to PvE builds, not PvP. But farming and running especially, there shouldn't be a bias based on profession. I have seen other builds (that one wasn't the best example) that people say are bad just because another profession can do it better. My best guy is my ranger, and for a long time, that was the only guy I played. When I came here (or GW) I want to know a good ranger farming build, not that a 55 can do it the best, and that that is the only one worth doing it with since it does it 5 minutes faster than the ranger. I'm just trying to make this easier for new players to find a good build. Bluemilkman 05:54, 3 July 2007 (CEST)

I have a suggestion that might be right up your alley: User:Hhhippo/BuildSearchEngine. This is something we hope to incorporate into the RV policy. It would allow you to do just what you desire: to be able to search builds according to, among other things, primary professions. This way, you could still (efficiently) search for the best Ranger farming builds we have, while the effectiveness ratings of builds would be free from "profession bias" (i.e. "It's not great, but it's the best Ranger runner here, so..."). Is that helpful? - Kowal Krowman {{sysop}} 06:14, 3 July 2007 (CEST)

You're still missing the point. The builds are going to have to be good still. It's just to protect the good build from being voted bad because another profession can do it a little better. Bluemilkman 06:19, 3 July 2007 (CEST)

That's actually my point. If another profession can do it better, why shouldn't it receive a better rating? The search engine plan I linked to would allow you to sort by, say, Ranger primary with a rating of 75% or higher. You would be to narrow your search down any number of criteria, while preventing not-so-good builds' scores from being inflated because they are the best farmer/runner for that primary profession. Anyways, my point is, better builds should get better scores. If you disagree with me, you can use the search engine to sort builds your own way. - Kowal Krowman {{sysop}} 06:28, 3 July 2007 (CEST)

I'm not saying they shouldn't get a better score, but only better than other builds in their profession. A 55 is probably the best farmer there is. But for another build to be voted bad because the 55 can do it better, shouldn't happen. I don't have a 55. So when I go to find Working-great builds, and the only farmer I see is the 55, how does that help me? I go to the working-good builds. No farmers there, because they've all been voted to working-other, or trash, because the 55 is the best one there is, and nothing else compares to it. I don't want to see people not being able to find a good build, because they are under the presumption that anything not in good or great isn't worth using. I want more people to come here to find builds. I'm sure you want the same thing. But good builds will be voted bad because of profession bias. Right now, that is a sure thing. People will not be able to find a good build for their profession. They will leave because they can not find a good build. I don't want that to happen. Bluemilkman 06:38, 3 July 2007 (CEST)

So if you don't have a 55, you use the search engine to find the best build for a character you do have... - Kowal Krowman {{sysop}} 06:40, 3 July 2007 (CEST)

What happens if they are all deleted because they got voted into the trash, not because they were bad and didn't work, but because the 55 did it better? Bluemilkman 06:51, 3 July 2007 (CEST)

That is a good point, but what if they all got voted into the "Great" section because they are the best for their primary profession? It's a Catch-22, I think the expression is. Once we get that engine up, us admins can see what the highest-rated farming build for that profession is, and leave it if it is the only one of its kind. It's nice that none of the deleting is done by bots, and even if we delete something, we can restore it in its entirety with 2 mouse clicks. So far, and on GWiki, we haven't had problems with great or good builds being voted into the trash (well, unless they were very similiar to already vetted ones). I think if you, or any user, was concerned about their build being subject to "profession bias," a note left on the discussion page would suffice to ensure that the build does not suffer. As these circumstances are exceedingly rare, I think it would be best to handle this on a case-to-case basis. I will personally offer to review any build that anyone feels has been subject to any form of bias in the vetting procedure. - Kowal Krowman {{sysop}} 07:07, 3 July 2007 (CEST)

I guess that can work. At least for now. Thanks. Bluemilkman 07:11, 3 July 2007 (CEST)

My Watchlist...

...doesn't update when a build has been rated. Any way to make it recognize when a build has had a change to the rate page? --VallenIconwhitesmall Vallen Frostweaver 19:10, 3 July 2007 (CEST)

When they get tagged

Do we tag them after 3 votes, or after the first vote? I think after 3 makes more sense. ~~ User Frvwfr2 signature frvwfr2 (talk · contributions) 12:17, 4 July 2007 (CEST)

5. - Kowal Krowman {{sysop}} 12:18, 4 July 2007 (CEST)

Testing means that it should be tested

Since they are called builds in "testing phase" i suggest to include in the vetting policy that any rating vote which is clearly not based on any valid and proper in-game testing should be striked automatically by the admins. I suggest this even though an admin (Krowman) just acted like this on a build i posted, so I'm not really full of hope about this whole thing.

If it clearly violates PvX:WELL, it can be deleted or voted down no questions asked. —ǥȓɩηɔɧ/〛 00:15, 8 July 2007 (CEST)
Also, PvXwiki:Sign your comments —ǥȓɩηɔɧ/〛 00:16, 8 July 2007 (CEST)
If your Build does not work, it will be unfavored then deleted. We have had this conversation many times. If anyone wishes to bring it up again, my advice to you it to QQ :). 09:45, 7 July 2007 (CEST)


Ahoy! Not to be difficult, but I was wondering if someone could change the range of the categories to include everything. I posted a build that has a rating of 4.45. That number is neither within 3.5-4.4 nor within 4.5-5.0. Maybe if it was rephrased to "Working-good 3.5 up to 4.5" or something along those lines. It's not a big deal, I just find it annoying that 4.45 isn't technically part of any category. Garrik Fel 21:20, 9 July 2007 (CEST)

Done. – HHHIPPOsysop› 19:10, 10 July 2007 (CEST)


Could anyone please take time and make a summary of the talk's here and archive old topics. Thx. gcardinal 21:34, 9 July 2007 (CEST)

Will do. Readem (talk*pvxcontribs) 20:26, 11 July 2007 (CEST)

Community content is available under CC-BY-NC-SA 2.5 unless otherwise noted.