Talk: Real Vetting/Archive 6

Revision as of 17:45, 11 January 2008

A suggestion

From PvXwiki talk:Build Master User Rights. -

Krowman {{sysop}} 20:38, 10 November 2007 (CET)

Prior to making such a major and most likely unwise addition to our policies, we should first consider other means of improving upon the reputability and quality of this site. Therefore, I propose making the following minor adjustments to the vetting system in the effort of improving the general quality of our builds:

We move to a out of 10 rating.

This would hopefully provide more precision in the vetting system.

The range for acceptable builds becomes from the 75% to the 85%; good 85% to 95%; great 95% to 100%.

By removing the bottom 50% of currently vetted builds, the average quality of vetted builds increases.

Innovation becomes a separate score that does not impact vetting, and is displayed separately.

This would allow those looking for new concepts to find them, while not affecting build quality.

Universality becomes worth 10% of the final vetting score.
Effectiveness is split into three equal portions, each worth 30%:

Purpose. Does the build accomplish it's stated purpose? If it is a tanking build, can it successfully take damage and survive? If it is a spike build, can it kill quickly and effectively? If it is a pressure build, can it keep up sufficient damage for a lengthy period of time?

This is the most like the old effectiveness score.

Utility. Is this build able to shutdown or hinder enemies?

Self-explanatory. Might need a more detailed definition.

Survivability. How well can this build survive? Does it have sufficient armor and health for its role? Does it have self heal, prot or condition or hex removal?

Also fairly self evident.

Other adjustments:

Write a longer, more detailed beginner's guide.

And we wonder why we get so many noobish/duped builds...

Write at list of skills (i.e. seeping wound sins)/concepts (i.e. critscythe, ss rit, etc.) that have been unfavored and deleted before. Only add to this if we see something 2+ times. Things should be removed from the skills-based section after a buff to that skill, like that would ever happen.

Should cut down on the number of crit_(insert non-dagger weapon here)_ sins, at least.

Lord Belar 23:41, 9 November 2007 (CET)

Seems to me Utility and Survivability are subcategories of Purpose, moreso Utility than Survivability. A BSurge ele's Purpose is Utility, and a BoA's Purpose is most definitely not Survivability. --71.229.204.25 23:47, 9 November 2007 (CET)

To clarify my point because I didn't do such a good job last time: A (PvE) stance-tank warrior that is excellent at what it does would get high Survivability and Purpose but very low Utility, because all it does is sop up damage. A monk would get the same rating, due to its heals and lack of interrupts/Blind. They would both only rate a 66% in Effectiveness. On the other hand, a Heal/Expertise specced R/Mo running Glimmer of Light, Dismiss Condition, and Throw Dirt would rate poorly in all three categories because it's fucking stupid, but because it was rated in all three categories it would have a much higher rating compared to the monk or stance tank than it should. --71.229.204.25 23:56, 9 November 2007 (CET)

Okay, that was a separate argument altogether. Feel free to disregard it. --71.229.204.25 23:57, 9 November 2007 (CET)

(2xEC)I wanted to make it Utility, Survivability and Damage, but then we would end up unfavoring all of the tanking builds. Lord Belar 00:00, 10 November 2007 (CET)

(EC)Yeah, I know. I'm not sure how to get around it, short of having diferent rating criteria for every catagory, i.e. for "tanking" you vote in Survivability, Purpose and Damage resistance(?). Lord Belar 00:00, 10 November 2007 (CET)

I think we should just leave it as Effectiveness, described as "does it do what it's intended to do, and does it do it well?", with these three as criteria to consider. If we try to split it up like this it's gonna end up as complicated as Brockian Ultra-Cricket or the D&D Grapple system or something. --71.229.204.25 00:03, 10 November 2007 (CET)

Good idea. I can handle complicated, and tend to assume everyone else can too. :/ Lord Belar 00:04, 10 November 2007 (CET)

Considering how many people bork up Universality in our current system, I'd say it's safe to assume anything beyond GOOD BUILD Y/N AMIRITE is a little too advanced. :) --71.229.204.25 00:06, 10 November 2007 (CET)

Hey, let's do that! First person to it gets to decide its fate! :P Lord Belar 01:34, 10 November 2007 (CET)

Bad idea for 2 reasons. 1) You will unfavor some of the greatest builds ever, such as Build:A/W Shadow Prison Assassin which has no survivability and no utility, so it will get unfavored. 2) The switch form 5 to 10 (however good it may be) will totally screrw over the voting appearance. It will become wider than the screen and will just be bad, so its impractical. --- Ressmonkey (talk) 00:14, 10 November 2007 (CET)

Horrible example. SP sin deserves to die. -- Armond Warblade

{{sysop}} 00:32, 10 November 2007 (CET)

Perfect example. SP sin is the greatest build ever, right under 600/smite. ---

Ressmonkey (talk) 01:06, 10 November 2007 (CET)

We own TA with SP sin. — Skakid9090 01:07, 10 November 2007 (CET)

TA ez way ftw? - Rawrawr 01:15, 10 November 2007 (CET)

Of course. ---

Ressmonkey (talk) 01:18, 10 November 2007 (CET)

Read the above conversation, I didn't say it had to be those categories. So make the numbers/spaces smaller. Wow, that was hard. Lord Belar 01:34, 10 November 2007 (CET)

Well, thanks for the input, and for organizing it nicely. Your ideas on the Innovation score in particular resonate with many users here (including myself). It is something the server admins simply haven't changed yet, though that likely will be implemented at the same time as the build search engine. However, note that your suggestions relate to Real Vetting and not this currently-proposed policy. One thing that you wrote made me laugh for a bit: "Self-explanatory. Might need a more detailed definition" Lawl. Anyways, more criteria doesn't make us any more reputable; accuracy does. As presented, these criteria would misrepresent some of the most effective/popular builds in GW, and that's bad. Criteria themselves are pretty lacking. Utility? Builds are created for utility purposes, like the BSurge example. Survivability? Many PvP toons don't roll self-heals, especially with 3-monk backlines, off-monk healing/prot, and utility. Splitters would get much higher ratings, even though people these days don't split like they used to. Your 'other adjustments' sound nice, but are based on misinformation. People don't submit bad builds because we permit them to. Acknowledging that, your two 'other adjustments' don't address the cause of the site's problems. No matter how detailed we make beginner's guides, people still won't read them. List of bad skills also wouldn't do much of anything, because of updates/new skills, and because people don't properly acknowledge a skill's value immediately. Ex: Warrior's Endurance. It has taken 1.5 years for people to make an actually good build using that skill. (If you don't know the build, you run a fairly standard PvP Hammer War with WE and a bunch of fast-activating attacks.) 71 makes the most important point of the discussions above: people don't follow the rules. They "bork up" our current criteria all the time. If people followed the letter of the criteria to a 'T,' then there's a slim chance that we could improve the site in general through changing our vetting criteria. Because of all the reasons stated here and above, it's unlikely that we will be implementing these changes (which, again, pertain to Real Vetting and not this policy.) - Krowman {{sysop}} 07:43, 10 November 2007 (CET)

Ok, new ideas.

Add a  to the new build template.
Allow the proposed innovation score to be struck separately from the main vote.

"Self-explanatory. Might need a more detailed definition" Hey, I wrote this around midnight. :P And yes, I realize that this has more to do with real vetting than this particular policy, but since the intent of this policy appears to be to improve build quality, it might be better to improve upon the vetting system before doing anything rash like giving more people vote removal privileges, because as well intentioned as it may be, the potential for abuse is still there, and this is getting to be quite a run on sentence.

Also, no one has commented on the increasing the threshold for acceptable builds. :(

Lord Belar 19:35, 10 November 2007 (CET)

Fine, increasing acceptable thing = bad. ---

Ressmonkey (talk) 20:03, 10 November 2007 (CET)

Care to explain? Lord Belar 20:03, 10 November 2007 (CET)

No =) ---

Ressmonkey (talk) 20:04, 10 November 2007 (CET)

Oh, ok. :P Lord Belar 20:05, 10 November 2007 (CET)

How about these 3 categories on a 10 rating scale.

Effectiveness:

Synergy:

Universality:

--Victoryis yours 21:27, 10 November 2007 (CET)

Synergy = no. There is absolutely no viable way to rate a single slot's synergistic value with other team members. Synergy could only apply to a team build, and how that team works together. Synergy as a criteria would also misrepresent farming builds, who usually roll all by themselves. -

Krowman {{sysop}} 21:49, 10 November 2007 (CET)

Synergy=no, I agree. Effect+Universe is all we need. ~~

frvwfr2 (T/C/Sysop) 23:13, 10 November 2007 (CET)

The problem is that with only two criteria, having 5 votes on a build won't be enough to see a major affect on the build's rating. That was a problem back on the old wiki, where voting was essentially based on Effectiveness and a out-of-one rating system. I doubt moving closer to that style of vetting system would be something we want. This does not mean I'm taking a stance against the removal of Innovation, nor am I pushing for its retirement from the current system. To make the vetting system mathematically sound, at least, there should be three categories. — Rapta

(talk|contribs) 00:53, 11 November 2007 (CET)

Good point... However, innovation is a bad category... A build should not be based on how creative it is... ~~

frvwfr2 (T/C/Sysop) 01:06, 11 November 2007 (CET)

I meant synergy as in between the skills. A nuker with a bunch of random AoE skills isnt very synergetic, but Headbutt with Plague Touch is somewhat synergetic as they work together to apply dazed.--

Victoryis yours 01:41, 11 November 2007 (CET)

BUt that is part of effectiveness. ~~

frvwfr2 (T/C/Sysop) 01:44, 11 November 2007 (CET)

Yea I guess, just freeballing ideas to replace innovation.--

Victoryis yours 01:46, 11 November 2007 (CET)

Effectiveness: 75%. It's how well it does its INTENTED job, so it deserves to be the most

Universality: 25%.

Innovation: 0%

Ease of Use: 0% (A monkey could run SF, but not everyone could run a GvG blinding surge)

Hows that?-- The Gates Assassin 22:07, 10 December 2007 (CET)

Innovation #2

rename this to 'popularity' or 'metaness' and change the description. right now the term and part of its description are contradictory. - Y0_ich_halt 13:57, 11 November 2007 (CET)

and sorry for not reading the discussion above >.> - Y0_ich_halt 13:58, 11 November 2007 (CET)

A serious disscussion about the rating system

As the title suggests i would like serious disscussions about the rating systems, and i know that it's mentiond above but i went to talk specficly about the rating system, not what they're ratted(sp?)on. I prepose the following:

change the range form 0-5 to 0-10, this allows to more clearly distinguish builds between each other.
We change the boundries of the catagories, so that anything lower than 60% overall is a trash build, this will allow the build on the site to be of a higher standard, and to be honest i don't think any build that score less than 60% are of any use.
other changes i'm knicking from the above posts:
- The range for acceptable builds becomes from the 75% to the 85%; good 85% to 95%; great 95% to 100%.

By removing the bottom 60% of currently vetted builds, the average quality of vetted builds increases.' (i may have changed the %age of the builds to remove....)

i think we can all agree that the above suggestions are really a must, 0-5 just isn't a wide enough range, and we get too many build that aren't of any use sticking around because the author and his friedns can get away with bias votes (not voeraly bias but on 0-5 it's easy to get away with it), if we had 0-10 we could distinguish more clearly between votes that are biased, and those that aren't. I'm sure we will have an issue with builds that are already votted/have votes, so i had a thought about how to work round that (i don't know if it will work Hippo or GC will have to tell me if so): We create a special page where it tells users what builds they have votted on, in order, with the most recent votes on the top. (which sounds do-able to me though i could be wrong), and the net bit may be a bit of a stretch if the a last bit was do-able, on this page we will have builds that need the votes re-doing to match the new system in a diffrent colour, or bold or something. So thoughts?PheNaxKian (T/c) 21:00, 13 November 2007 (CET)

i agree with most of the suggestions. and additionally i'd like 'innovation' to be changed. as for the votes page, i'd recommend something like "My contributions" just for "My votes". - Y0_ich_halt 21:22, 13 November 2007 (CET)

seriously, how in hell is a build better because it's never been done before?—

Cheese Slaya (Talk) 00:25, 14 November 2007 (CET)

As I said above, innovation needs to be a separate section, not affecting the rating, but required nonetheless. Lord Belar 22:16, 14 November 2007 (CET)

This talk was started to talk about things other than innovation (there's currently 2 topics of innovation going on above). This specific topic is about the whole vetting system as a whole and how we think it can be improved.PheNaxKian (T/c)

22:55, 14 November 2007 (CET)

Spelling.

The one that I saw was extend rather than extent. Sorry I'm a spelling and grammar nazi. Bluemilkman/Talk To Me 12:46, 21 November 2007 (CET)

Firefox is not my true spellchecker; it is the first of a line of defenses as large as the PvX community! -- Armond Warblade

{{sysop}} 13:13, 21 November 2007 (CET)

Archive?

WARNING: This page is 137 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections. Time for an archive?? it's annoying having to scroll sooooo much....PheNaxKian (T/c) 18:58, 26 November 2007 (CET)

PvX policies are SRS BSNS. And ToC links are there for a reason. *Archives anyway, just to be hypocritical* -- Armond Warblade

{{sysop}} 11:24, 29 November 2007 (CET)

note

"Likewise, a rating of e.g. Zero in Efficiency and 5 in Universality is considered contradictory"

should have effectiveness in place of efficiency. --Victoryis Santas 16:23, 25 December 2007 (EST)

Thanks. ~~

frvwfr2 (T/C/Sysop) 16:29, 25 December 2007 (EST)

Get rid of the "Other" rated builds

High standard of quality gogogogogogogo. Misfate 11:34, 29 December 2007 (EST)

I mentioned something like this before, but no one listened. :( Lord Belar 11:37, 29 December 2007 (EST)

We keept hem there so people can look at whats been tried and Failed but still manged to get vetted, at least thats what i think, so if we get rid of them there will jsut be a swarm of bad builds again, but i do think perhaps the lower rated "other" builds need removing maybe....Phe NaxKian

11:41, 29 December 2007 (EST)

The original intent behind the "Other" category iirc was to have a category to document the usable, and often more interesting/innovative builds that didn't fit into the Good or Great sections.

*Defiant Elements* +talk 15:37, 29 December 2007 (EST)

me too — Skakid 15:54, 29 December 2007 (EST)

I think it would be fun to rename other to gimmicky o.0, but thats just because I don't quite realize why alot of the more experienced members here dislike having random builds laying around, and whats all this talk of higher quality of builds, awesome ones are just as awesome even if surrounded by Rangers wielding WoH as a selfheal with 0 points in healing and a mesmer secondary(the preceding build is a dramitization), thats why we have Great, Good, and Other, I run other builds alot because they ARE gimicky and fun for me to use, with a little editing naturally. As a matter of fact I often find myself digging through the trash for builds (not just my own lol)Under Gunned 19:04, 6 January 2008 (EST)

PvE

Under the letter of this policy, the answer to this question is simple. In practice, it's more complicated. In many PvE teams builds, several character builds come together to form an effective team. However, the feasability of finding characters to satisfy the team is virtually none. Should overly complex, yet still effective, PvE teams recieve poor ratings due to the difficulty in establishing a group?Bob fregman 20:44, 31 December 2007 (EST)

Though it would absolutely be going against the definition of effectiveness, that it's not based on the "player's effort required to use it or to acquire the needed skills and items", I honestly don't think it's feasible to form huge teams for "general PvE". Even HM teams are pushing it. Because to not address this is going against the nature of GW. It's not an answer to the question posed, but I think PvX should just disallow general PvE or HM PvE Teams.

Shen(contribs) 20:48, 31 December 2007 (EST)

And if this is a priority issue, as I think it qualifies to be, votes on that Singers of Woe build should be scrapped.

Shen(contribs) 21:30, 31 December 2007 (EST)

IMO for trivial areas that don't require a specific group arrangement, team builds should be scrapped. For areas like DoA HM where only specific builds work, go ahead and create that generic bond-tank-obsidian flesh-HB team setup. — Rapta

(talk|contribs) 22:59, 31 December 2007 (EST)

If it's unrealistic, don't keep. If it's two people and heroes, fine. If it's something you can throw together as an outline (two monks, two paragons, two warriors, etc) that the roles can be filled by heroes or humans, throw it up and let's see what happens. There's always guildies willing to run an actual good team build in PvE. -- Armond Warblade

{{sysop}} 04:18, 1 January 2008 (EST)

I think really what we should do is say that builds should only be put forward for the higher end of PvE (later on in the game Fire island, DoA, Slaver's etc.) and all HM, i also think it's pointless to make an 8 man build and have 3 heroes and 4 hench, while i think it's a good idea to say you should take these hench, i think what should be done instead is make a bar for a human or hero character, then just put a note underneath it saying you can take xxx hecnch instead, Also i think there should perhaps be a new criteria to PvE builds when it comes to vetting-similar to universality but more how it can do in different missions or areas than it was designed for (e.g. somethings designed for mallyx works really well, will the same build work well in Slaver's?) While i know that's a bit of a contradiction to what i've been saying i think in some ways it would make a bit of sense and we wouldn't count it's weighting as much (about 5% max maybe).Phe NaxKian

06:40, 1 January 2008 (EST)

Agree with Armond. Then we'd need to draw up some limitations.

Shen(contribs) 12:26, 1 January 2008 (EST)

Only the most difficult places should have specialized builds. Quite simply, it's unfeasable that someone could get 5 other guys and do a specialised speed run through Gates of Kryta on NM or even HM. It's just not practical. Sure, DoA, Slaver's, some of the harder dungeons, etc. should (and have to) have specialized builds. Everywhere else? Not needed, really. —ǥrɩɳsɧƴ ɖɩđđɭɘş

12:34, 1 January 2008 (EST)

Phenax, if you're doing H/H, any builds that actually work on the four you control will do, and it's a given that any DoA build might not work for Slaver's. That's kinda like saying "it works in GvG, let's try it in RA/TA/HA." -- Armond Warblade

{{sysop}} 16:09, 1 January 2008 (EST)

I like Quickrez Int-heavy Mesmers in my AB teams, ya know. Or in RA. They are roxorz in RA. ...

cedave _{(contributions_buildpage)} 02:48, 6 January 2008 (EST)

Rewrite

This is a rather important discussion - I'm actually remembering to turn off minor edit for it. :P

Leave any and all reasons for keeping the "other" category here (but please try to keep on topic... I don't feel like reading through a billion paragraphs of random). Silence means assent.

After perhaps a week, if there's no dissent, I will remove the other category. Otherwise, the admins and I will have to make a decision.

Just so there's no complaining that this isn't noticeable, I'll be adding a note to the news part of the main page. I'll also be dropping DE an email for when he gets back so he can take a look at it.

The idea is to raise the standard of quality of the builds on the wiki and remove "interesting" builds that serve no real purpose. This has been proposed before, as can be seen above, but it was mostly ignored.

-- Armond Warblade {{sysop}} 02:35, 6 January 2008 (EST)

I'm in favor of this. Strongly. If you're using an other build, chances are it's only because you were using it before you found the Great category.

cedave _{(contributions_buildpage)} 02:46, 6 January 2008 (EST)

I am NOT in favor of this. Others will stay. People are free to browse builds as they want - we are not in a position to limit knowlege or accesebility of the builds stored on pvxwiki. gcardinal 03:11, 6 January 2008 (EST)

Well, guess that's a rather quick and brief conclusion. GG, eh? Heheheheh..

cedave _{(contributions_buildpage)} 03:31, 6 January 2008 (EST)

You are not, however, community consensus, which is, I believe, what this policy is based upon (that's why we voted, I thought). Just so it's clear, your singular vote won't stop this, though now that there is dissent we will discuss it before implementation (if we do implement it). -- Armond Warblade

{{sysop}} 03:33, 6 January 2008 (EST)

I have two opinions on this. The first is that the Other category of builds provides a database of ideas that have already been implemented and function to some extent, though not to the same quality as Great or Good. In that sense, the Other builds should stay, and the community can benefit from having a large number of builds that can be modified and worked from without threat of deletion. On the other hand, I do question the usefulness of the Other category. If I use a wiki-build, it is always from the Great or Good categories -- I don't see any reason why I would use an inferior build in the Other category. In this perspective, I have yet to see a reason why we should be keeping builds that are proven not to be as good as other vetted builds. I don't believe PvXwiki is only about keeping the best builds, but when we have a rich database of functional builds of good quality, we seem to defeat our own purposes by providing builds that are not as good and have little to no redeeming features. We should discuss the purpose of the Other category in order to refine the Real Vetting policy rather than making absolute decisions. I also think that it is time that we look back at the policy overall now that we have been working with it for quite some time. --

Scottie_theNerd (argue) 03:42, 6 January 2008 (EST)

Something I forgot to say in my initial post - I feel that the main purpose the other category serves is as a reference, much the way trash builds provide a reference for the two week grace period they have. However, I don't see why builds with approximately the same value (in this case, about none - again, why are you using an "other" build?) should have different grace period lengths (infinite verses two weeks). -- Armond Warblade

{{sysop}} 03:53, 6 January 2008 (EST)

@Scottie - Originally, I had the same idea. However, approximately 3 seconds later, I realized that that's exactly why we have Trial. If nothing else, perhaps we need to rename the category. I'm still in opposition to the Other Category either way. Maybe create a "Needs Work" category?

cedave _{(contributions_buildpage)} 04:26, 6 January 2008 (EST)

Rename 'Other' to 'Non-Functional' or summat imo. If we just flat-out remove it, we're going to see a surge of bad builds going into Good just because people feel they don't deserve deletion. Hell, I've caught myself doing that a time or five. --71.229 04:34, 6 January 2008 (EST)

I don't see how keeping these builds undermines the quality standard of the wiki. We don't claim they are good just because we keep them, they are labeled as not too good but still functional. In cases where there is a directly comparable better build, PvX:WELL will do the job. In other cases, I'd vote for keeping them. There's no disadvantage of keeping information as long as it's not wrong. That is, even a description of a not so good build might be useful as long as it is labeled as such. I'm happy with renaming the category to something more appropriate, as well as changing the text in the header box on the build pages. – HHHIPPO ‹sysop› 05:10, 6 January 2008 (EST)

Renaming it seems to be the practical thing to do, although renaming will inherently lead to redefining the purpose of keeping the Other builds. At the moment, they are in a sort of limbo -- not quite Good, but not quite Trash, and the name "Other" carries the connotation of limbo in itself. Wiping the category won't increase the overall quality of the wiki -- as stated, we don't pretend that the Other builds are good, but they do exist for an undefined reason. --

Scottie_theNerd (argue) 05:28, 6 January 2008 (EST)

Very soon we are going to implement advanced search engine developed by Hhhippo - it will allow a very free and customized browsing of the builds - based on type, rating and all kind of possible information. Great, Good and Others will server only as reference storage dir's.

We havent finished what we started with Real Vetting - any change now will hurt both the website and all the work me and Hhhippo was doing behind the scene. Ones we have the new search engine there will be almost pointless to remove any category - as each user can create 5 or 10 steps/rank system as they want.

For the new users as well as visitors who only copy-past builds (95% of users never edit) - it is important to keep all information availabel and acesseble. I think it will be wrong if we will limit users from getting access to information their seek. gcardinal 06:09, 6 January 2008 (EST)

(indent reset)Why is it important to keep all build information? We are already limiting information: we delete trash builds after a two week grace period. How does the Other section differ, and what would users benefit from being able access poor builds? -- Scottie_theNerd (argue) 06:49, 6 January 2008 (EST)

It differs in other builds being not as bad as trash builds. Users benefit when looking for something where there is no great build. It's also easier to explain things if you can point at some examples when saying 'this is better than that'. And again, it doesn't hurt anybody to keep them. – HHHIPPO ‹sysop› 07:02, 6 January 2008 (EST)

Rarely do regulars have to specify builds when it comes to "this is better than that". More often, it works the other way around: many Great and Good builds are used to contrast newer, ineffective builds; that is, "these Great/Good builds are better than this build". That point, if you follow your own reasoning, is not valid when applies to this community. As for your other point: I'm not sure how a user can benefit when they are using barely functional builds. It does hurt users, because we are providing an easily-accessible database of builds that contains poor builds that users will pick up and use. "It doesn't hurt" is not a strong argument to keep something, especially when it is conjectural. Again, how does the wiki benefit from keeping Other builds as they currently are? --

Scottie_theNerd (argue) 07:15, 6 January 2008 (EST)

I think it is wrong that we will decide what is right or wrong for user - it is up to each user to decide. They have brains and if they visit and use other build and stubs and so on - we will provide that information. Again please see a bigger picture here with search engine, build masters and the whole package. Going on with "ohh we know best, we are leet, users are stupid - lets protect them" is not a way to go. This site has 35000 uniq visitors a day only maybe a hundred makes edits. However thousands are using Other builds everyday - why remove if its popular?

There will be very advanced search engine so each user can view build DATABASE as their want and now how we present it. The whole point about removing something that is popular, works and has important functional aspect to it makes no sense.

Let us finish the work we have started with Real Vetting, when it is complete we can start changing it. Changing anything now while work in progress will create chaos. gcardinal 07:25, 6 January 2008 (EST)

Sheesh. To be quite honest, I'm quite content with maintaining the status quo. I'm only raising food for thought here and trying to promote discussion, unlike the last time it fizzled out. There's no need to vilify me or the admin crew. --

Scottie_theNerd (argue) 07:43, 6 January 2008 (EST)

I am sorry if the work flow and status has not been up-to date. This issue has been discussed many times before with admins adn some users - so as I remmber plans was pretty clear about how to develop and finish what we started. Again sorry if there was luck of information. gcardinal 08:06, 6 January 2008 (EST)

Well I'm not the one who started this discussion. Don't take it out on me. --

Scottie_theNerd (argue) 08:09, 6 January 2008 (EST)

I am sorry but I was never refering to you - i was answering comments in general. But if you felt that way I am sorry. gcardinal 09:02, 6 January 2008 (EST)

This is some juicy stuff. I was going to write an essay on a topic quite different but still applicable to this ongoing debate: Innovation. Many thanks to Armond for giving me an excuse to shunt rigid essay structure out the window, (though one will undoubtedly be able to ascertain some resemblance).

Taken from Archive 3, Hippo says "In my opinion, the main purpose of the rating system is not to figure out what's the best build or who's the best author ever. The main purpose is to maintain a collection of interesting builds, along with an accurate description of their qualities, and a system to organize them in a way that enables each reader to find the build he's looking for. To this end, we do need a number of criteria in the rating system."

To address Hippo's opinion is to address this issue in its entirety, I believe. Perhaps the most fruitful avenue for one interested in abolishing, as I do, both the Innovation category and the Other section, can be found in assessing the current state of PvXwiki. One subsequent characteristic can be aptly summarized: Innovative builds fail. It is the Nature of Guild Wars Builds. Innovative builds can never be salvaged, doomed to the Other category, because the innovative part lies in the fundamental concept of the build, one that cannot be given up without concurrently sacrificing the "Innovation" of such a build. To glorify the advantage in keeping Innovation and the Other category, that is, the average user can search for a "collection of interesting builds" and so forth, kills any attempt to keep a standard of excellence. The Vetting system currently allows decent, innovative builds to be accordingly placed in the Good, or even Great, categories. This is excellent. But it doesn't mean PvXwiki has any need for the poor, innovative builds. In theory, as Scottie very succintly points out, the Other Category allows PvXwiki to house poor builds that would somehow be considered worthwhile for an average user. In reality, the Other category is only demeaning to the already wanting reputation of the wiki. Therefore, it is my sincere belief serious users will contribute, or at least look more favorably towards the wiki, if we were to scrap the Other category and Innovation completely.

Another such Truth of this wiki is that many people don't understand Innovation. I've been pretty much voting Innovation willy-nilly, not merely because it doesn't have a significant impact on the score, but because I'd rather avoid any controversy. But other users read Innovation as outlined by Real Vetting and vote justly. The more common voters simply see Innovation as the word's face value, that is, the common connotation attached to it. With these two conflicting ideas on innovation, we've got the Build's getting 5 in innovation because it's meta, and 0 in innovation, again because its meta. The current definition allows it to be so. Furthermore, the innovative-ness, the originality of the build, as most users rate the category, is a radical concept, changing as builds see more use in the actual game. This is a fatal flaw to the feasibility of a vetting search engine. Because no matter how rigidly we define Innovation, there are going to be those who again, simply see the word as is. Tying this back into the Other Category debate, there truly is no benefit to even the optimistic vision of a search engine that allows the bad builds to be filtered through, since innovative builds almost always are tagged for Other, or welled. German capitalization ftw

Shen(contribs) 09:53, 6 January 2008 (EST)

Juicy indeed. i would say that while scraping both innovation and the other catagory isn't the best idea-perhaps we can reach some sort of compromise?, we have had countless conversations about innovations weighting being 0% and increasing effectiveness and universality, which would make more sense than getting rid of the criteria all together. As for the "other" builds, why don't we get rid of the lower portion of the builds (say anything below 2.7-3.0), and put them into the trash section (this allows us to modify as needed...), and we could then change the rating requirement of other builds to 2.7/3.0-3.5. Thoughts? PheNaxKian (T/c)

10:01, 6 January 2008 (EST)

I also feel strongly about Innovation. When Real Vetting was being written out, the concept of "Innovation" had some sort of vision to it. Now that we're all familiar with Real Vetting, the Innovation criteria holds back many good builds and bumps up bad ones. I think Shen puts it nicely: builds which are clearly innovative are usually gimmicks, and they are more often than not really bad. There's a reason why many skill bars have a significantly overlap with other builds -- from 2-3 utility skills common to professions to the extreme but not uncommon example of the BHA vs BA ranger. Innovation is good, but not at the cost of effectiveness. The current weighting of Innovation was a compromise in Real Vetting. Since we are bringing Real Vetting up for discussion, this would be a good opportunity to thrash out the problems we have with Real Vetting. Better we sort things out now rather than complete a search engine on shaky grounds.

In regards to Phenaxkian's suggestion about the Other category: well, where do we stop? gcardinal (and others) wants to keep the other section; Armond (and probably others) wants to scrap it. Trash is currently anything below 2.5. By changing the vote requirement to get into the Other category, we'll trash more builds without properly defining what the Other section is meant to be. Considering comments made in the past and in this discussion, the Other builds are like white elephants: a bank of innovative ideas that don't really work. What do we do with them? --

Scottie_theNerd (argue) 10:15, 6 January 2008 (EST)

Some thoughts:

Keeping bad builds while clearly stating that they are bad doesn't influence the level of excellence of PvXwiki. If someone tries a build that we call bad, then finds it's indeed bad and concludes all our builds are bad, that just means he can't read. I can't and don't want to help such people. As a compromise, we could make it more clear what's the quality of Other builds by renaming the category to, say "Not Recommended". In addition, we could remove the Other categories from the tables on the main page and just put links to the overall 'other pvp' and 'other pve' categories.
I still think there's an advantage to keep these pages available. Our build pages are not just a skillbar plus the one-bit information "we keep this build". They also contain a more detailed description and discussion of the quality of the build, of how and where it works and, most importantly, where and why it doesn't work. I believe a reader can benefit more from a description of what a build is trying to do and why it fails, than from an empty page or "This page was deleted and we won't tell you why".
Our vetting system assigns a number describing its quality to each build. However, this is not an objective measurement, it's just an average of opinions. For most builds, there are people who like them and people who don't. The current system uses the overall rating to put builds into some rough quality categories, but it still allows each reader to make up his own opinion. Deleting a build removes this possibility. Our average-of-subjective-ratings system is good enough to assign some labels to builds to give people a first impression before reading the whole article. But it doesn't give us an objective base for the decision to make a build unaccessible.
About Innovation: I'm happy with reducing its weight to zero. It might also be good to work on the definition such that everybody is talking the same language when calling a build innovative or not. Skipping it completely, again, would reduce in an unneeded way the freedom of readers to look for builds according to their own preferences (in particular when the search engine is done so people can look for each criteria separately). If it turns out that people can't handle Innovation, even with a better definition and without the possibility to abuse this criteria for influencing the overall rating, then I'm fine with skipping it, but for now I vote against. – HHHIPPO ‹sysop› 11:16, 6 January 2008 (EST)

The above post by Hhippo, in particular,the first bullet, is what i agree with. Regarding innovation:has anyone suggested this:simply make a much smaller box(i.e. template) that displays the separate innovation score. this allows innovation to have no weight, and would require very very little changes to the voting system/program that is being used.

13:06, 6 January 2008 (EST)

Your basically suggesting what a lot of people have been saying (minus this box but I'll explain about that in a min). A lot of us have said that innovation should have 0% weighting, so many people rate a build having no idea what it means that really to have it worth anything would mean we'd have to make it really clear (REALLY) as to what is meant by innovation which is easier said than done. as for the box. There's no need you can just go onto the rating page and just look at the average innovation score anyway. @Hippo i think the idea about renaming the category would be a good idea, maybe so it's a bit more clear they're not the best in the world (perhaps call it that =p), also i would like to say that if it does get to the stage we're considering wiping innovation completely that we'd perhaps need something to fill the void? PheNaxKian (T/c)

13:11, 6 January 2008 (EST)

I just want to say one again, the current system maybe dose not look all good to you at this moment - but believe me when we have Build Masters and the search engine done it will work much better.

If there is anything unclear about the "tagging" or description - I am all for suggestion on how to change it. However structual change at this point will only create more destruction then good. Lets finish what we started and then review the results and do changes. gcardinal 14:41, 6 January 2008 (EST)

Regarding an above comment by gcardinal - how do we know people use the "other" category? I'll believe you if you say that we get pagehits there, but how many of those pagehits are actually to look at the build, copy the template over to the game, and run it? We have no way of knowing that, short what we know of the people that look there - and I'd be surprised if people actually use the other category for builds, as opposed to "for lolz".
As for renaming "other", how about "ideas"? I would also support changing it to be 3.0-<3.5, and trash being <3.0.
Regarding BMs and search functions (and this is directed, in particular, to gcardinal and Hhhippo) - the average user has no idea how far along we are on this. There's no real progress information - I remember DE telling me a few months back that BMs were in beta, but that was the only information I'd heard about it outside of "this is a good idea" from the community as a whole (not from the programmers). The search function has been planned since the site's release, pretty much. Even a look at the admin-only version of the site (at least, the one that I know of) tells me nothing. As a result of this (and this may only be me), I have a tendency to ignore it. We are all, in some way, affected by this lack of communication; I don't know how others are, but that's how I am.
I would be opposed to an innovation box, unless it updated automatically (but that would be even more work for our coders).
I'd also support moving innovation to 0% ranking; that way it's useful for the search function, doesn't break the search function, and doesn't break the build.
Additionally, I think the mouseover descriptions on the rate pages should be updated after this discussion is finished. No matter what happens, things will change and the real vetting page will be updated - so the mouseover descriptions will have to be changed as well.
-- Armond Warblade {{sysop}} 15:36, 6 January 2008 (EST)

I say that, but I just noticed Hhhippo added a "status" section on the BM policy talk page. This is good! -- Armond Warblade

{{sysop}} 16:16, 6 January 2008 (EST)

Could i jsut direct this at GC and hippo more than anyone-would it be possiable to have some sort page with status' of facilities and functions etc. that are in the making-so the normal User can see how far along said things are?PheNaxKian (T/c)

16:38, 6 January 2008 (EST)

I'll be perfectly honest, I haven't read through this whole discussion, so hopefully this post won't simply be a re-statement of what has been said; however, there are some issues I'd like to address. First of all, I think people are missing the point when it comes to the purpose of the "Other" category. Back when the site started, we were discussing what the structure of the build database would be. Originally, it consisted of Stub --> Untested --> Good/Great/Unfavored. However, as many of you know, I'm a big fan of "Original Builds," ones which may not be great or even good, but which are usable and interesting. The Other category, far from an "unworkable" or even "needs work" category, was simply meant to house these builds. The fact is that there will always be people on a build site who prefer to see (and use) that which is new and interesting (sometimes to the exclusion of the less innovative builds in "Good" and "Great," and given that, it seems logical to have a place to store such builds. It's not that all "Other" builds will be innovative, merely that in a game in which, in general, it is the cookie-cutter builds that dominate, the truly innovative builds will likely be sub-par, at least in comparison. Of course, this all assumes that "Innovation" has some actual meaning, but that's another question. That said, rather than doing away with the Other category, I'd much prefer some attempt to re-name or re-organize Other and Innovation. Perhaps this discussion will be rendered moot when the search engine comes out, but, for now at least, I think I'd oppose the removal of the Other category. *Defiant Elements* +talk 17:55, 8 January 2008 (EST)

Policy Rewrite Poll, Increasing voting minimum to 10

Would add to the quality and would show a very specific consensus on a builds awesomeness or utter failage.--Shadowsin 14:46, 6 January 2008 (EST)

1. Support

/signed. Lord Belar 14:46, 6 January 2008 (EST)
^--Shadowsin 14:54, 6 January 2008 (EST)
yes plz Punjab 14:57, 6 January 2008 (EST)
Make it 10. gcardinal 15:14, 6 January 2008 (EST)
Yes but wait untill we have the search engine and BMs in.PheNaxKian (T/c) 15:16, 6 January 2008 (EST)
all for it 17:58, 6 January 2008 (EST)
/signed--Coloneh 18:23, 6 January 2008 (EST)
Yeah, sounds goodUnder Gunned 19:11, 6 January 2008 (EST)
I was just about to sign the Oppose, but then I though about it a bit. The more attention we require to be given to builds, the more likely the more well-placed the build will be. Think about it. We want to eliminate Other on the basis of contributing users, but why not just make it so contributing users had a much better reason to vote and get builds vetted or trashed? At the same time, I think we need to work on the idea that builds don't only need to get vetted, but that they also need to get trashed. cedave _{(contributions_buildpage)} 00:53, 7 January 2008 (EST)

2. Oppose

no. - Rawrawr 15:43, 6 January 2008 (EST)
We already know what has to be done to improve build quality, people just QQ when it's done. BM's should be made and an increase in administrative regulation of ratings should be done, as opposed to doubling the amount of votes needed.Bob fregman 15:21, 6 January 2008 (EST)
Not necessary. In my opinion, this is to make up for a lack of attention resulting in trashy Builds sneaking into the Good Category. To implement this would mean such necessary attention will be even more scarce, because there'd be a staggering number of builds stuck in Testing. As Bob said, just let BM's take up quality control to rid the need for an increase in voting minumum. Shen(contribs) 16:08, 6 January 2008 (EST)
Not yet. One variable at a time - let's see if BMs helps. If not, then yes. -- Armond Warblade {{sysop}} 17:59, 6 January 2008 (EST)
Wouldn't do much in the way of fixing anything, except for causing many more builds to get stuck in testing.--Goldenstar 18:03, 6 January 2008 (EST)
No -- at least, not yet. Wait until search engine and BM is complete to get a bigger picture. The problem with requiring 10 votes to be vetted is that most testing builds won't ever reach 10 votes for months. Builds that are already vetted are more commonly looked at, and they continue to draw many votes even though consensus is long since established. It won't work for Testing builds, unfortunately, even though it does present a more specific overview. -- Scottie_theNerd (argue) 01:05, 7 January 2008 (EST)
I don't think it would change much. Dark Morphon(contribs) 04:10, 7 January 2008 (EST)
There are already plenty of builds that can't get out of testing, and increasing the voting minimum to 10 isn't going to help. — Victoryisyours (talk/RfA) 18:28, 7 January 2008 (EST)
The problem is getting rid of the bad ones right away, not make them overstay their visit. — Rapta (talk|contribs) 17:58, 8 January 2008 (EST)
In the reasoning behind this proposal, you indicate that 10 votes would "show a very specific consensus on a build." However, in most cases, 5 is enough to show an obvious consensus. The times when it isn't (i.e. when there are people voting 5-5-5 and 0-0-0) you almost inevitably have a much higher vote count anyway. *Defiant Elements* +talk 18:05, 8 January 2008 (EST)
Can't argue with DE. Mike Tycn(punch out) 05:41, 11 January 2008 (EST)

3. Neutral

(your vote here)

Discussion

It really has nothing to do with BM's or admin regulation, a 5 vote minimum is just too low, its about the consensus of a larger number of people, one stupid vote can really have an effect on a 5 vote minimum but with at least 10 votes a really nonsenicle one can be pretty much quashed.--Shadowsin 15:42, 6 January 2008 (EST)

on a second note you really dont have to wait to trash a build if 5 - 6 votes are leaning that way, this is just so that more quality is accepted into each category instead of just mediorcre slippling by because no one was paying attention.--Shadowsin 15:44, 6 January 2008 (EST)

That makes no sense, we dont have to wait to trash a build if 5-6 votes lean that way, but we DO have to wait to vet a build as great, even is 5-6 votes lean that way.Bob fregman 15:46, 6 January 2008 (EST)

I dont know if you have noticed but it is alot harder to bring a build up that it is to bring a build down. 5-6 people vote to trash, well that normally precedes a trashed build, but if 5-6 people vote great that doesn't necessarily mean that the build will end up there simply because it takes one low rating to bring it to the good lvl, especially with the current minimum of 5 votes.--Shadowsin 19:30, 6 January 2008 (EST)

voting oppose is just succumbing to the notion that 5 people out of a community of 100+ has the power to move a build into a rating that it doesnt deserve, i dont know about you but 1/20 loks alot worse than 1/10--Shadowsin 19:33, 6 January 2008 (EST)

(EC)I don't see how that's a bad thing.

Shen(contribs) 19:34, 6 January 2008 (EST)

the 5 could be msn spoon buddies... it happens.--Shadowsin 19:43, 6 January 2008 (EST)

wai is there neutral, there really is no point to neutral xD.--Shadowsin 19:50, 6 January 2008 (EST)

BMs, if implemented, will be able to monitor votes more stringently, not to mention that builds can change category as more people vote on the build. In a way, bad builds being vetted into Good or Great will eventually get cut down as more people are drawn into using and testing them. A Great build can easily draw a hundred votes if left there long enough, so if 5 people vote it up to Great or (gasp) Feature it on the front page, it'll attract enough votes to naturally put it back to where it should be. --

Scottie_theNerd (argue) 01:15, 7 January 2008 (EST)

In a community of 100+ you would think it would be easy to get 10 votes on one build, 5 is not an objective pool of community opinion. wating for a build to be featured to show its utter garbageness is just a QQ fest in the making. "Well it was in great before wut the fuck is choor problem nuub!" yeah, you know it happens.--Shadowsin 08:18, 7 January 2008 (EST)

Vote Restore/Removal

Another discussion is going on about Real Vetting on my talk page. Please take a look at it here.

Policy Rewrite Poll: Upping the "other" category minimum to 3.0<4.0 or 3.0<3.5

Has been discussed before with no real voting just really really big walls of text. 2.5 is just too easy imo.--Shadowsin 19:49, 6 January 2008 (EST)

Support

3.0>3.5 imo--Shadowsin 19:49, 6 January 2008 (EST)
I'm with Shadow. 3.0-3.5. No more 2.6 builds tyvm. cedave _{(contributions_buildpage)} 01:09, 7 January 2008 (EST)
Agreed. 2.5 is an arbitrary half-way figure, but effectiveness doesn't translate to a linear scale. Bumping the bar up to 3.0 presents a larger hurdle for new builds and defines the Other category as more than just "baaaaarely works". -- Scottie_theNerd (argue) 01:17, 7 January 2008 (EST)
Yes. A build that's just over halfway effective isn't deserving of the "other" category. -- Armond Warblade {{sysop}} 01:20, 7 January 2008 (EST)
Aggreed. Dark Morphon(contribs) 04:11, 7 January 2008 (EST)
At some point (maybe after BM's and the search engine) PheNaxKian (T/c) 12:34, 7 January 2008 (EST)
3.5, imo. Lord Belar 17:11, 7 January 2008 (EST)
/seconded, but that's what removing other category is for. As a second option, this'll do... -- Armond Warblade {{sysop}} 01:46, 8 January 2008 (EST)
3.5 —ǥrɩɳsɧƴ ɖɩđđɭɘş 17:58, 8 January 2008 (EST)

Oppose

Simply not possible at this time. gcardinal 12:12, 7 January 2008 (EST)
Why trash? thats work for everyone XD Under Gunned 17:16, 7 January 2008 (EST)
DE is right, no need for the change.— Cheese Slaya (Talk) 18:31, 8 January 2008 (EST)
Has anyone considered that if the arbitrary number value is changed to another arbitrary value, people may simply change the manner in which they vote? If I know that Other is 2.5 and I think the build should be Other, I'll vote around a 2.5. If 3.0 is Other and I think the build should be Other, I'll vote around 3.0. *Defiant Elements* +talk 17:59, 8 January 2008 (EST)

No? Stupid people will still put 555 on a build that sucks and smart people will 000 so ineffect, it is lowering the standards by being 2.5 because it is easier being an arbitrary number or not.--Shadowsin 18:24, 10 January 2008 (EST)

Neutral

Discussion

Bell curvin it with 3.0>3.5 other 3.5>4.5 good 4.5>5.0 great--Shadowsin 19:54, 6 January 2008 (EST)

This will not be implemented until the BM and the new search engine is in place. Policy re-write at this point is simply not possible. Only when coding is complete, results are reviewed this discussion can take place. At this point it is simply pointless. gcardinal 12:11, 7 January 2008 (EST)

And if you wonder why - simply becouse I don't have time for this. We are working on BM and search engine based on the current version of the policy - any change now will bring only more work and delay it even further. As I tried to say many times before - let me and Hhhippo finish implementing Real Vetting before you start to change it. Changing the first revision of policy before it is even fully implemented makes no sense - no matter from what point of view you look at it.

This is also a clear follow up after "Lets remove Others campaign".

There is plenty to do - like teaching users to use Stubs->Trial->Testing and use PVX:WELL during Trial/Stubs and not in the middle of the Testing. There is plenty to do for sysops and for normal users. So I suggest people with spare free time go out there to new users, stubs and in a FRIENDLY way show how it sould be done.

Any discussion at this point of time - while work is still in progress based on the analyze and review of current beta implementation of the policy - is pointless. Voting/discussing anything now is simply wrong as it is based on the beta revision. When it is fully implemented with all the functions - new discussion will be needed and all previous will be pretty much outdated.

And for all the screaming "lets change lets change" - there is tech/coding and there is policy. We agreed on the policy, now it is time for coding to be completed. Any jumping around and changing based on the "lets change <insert weeks flavor of the change>" wont do anyone any good.

gcardinal 12:25, 7 January 2008 (EST)

You are contradicting yourself. You say that changes can only be made after the new features are finished being coded. Then you say that discussion is currently pointless. Could you explain why it is pointless to discuss and establish consensus now, considering that you will ready to make changes that have been agreed to the moment your complete the coding, if not earlier? The discussion is happening now, and you are opposing on the grounds that you refuse to make changes before the new features are rolled out. That's fine. I don't imagine the policy changes would happen anytime soon; hence the discussion and voting. I do imagine that by the time the search engine and BMs are implemented, this discussion would be near conclusion.

Real vetting has been around for a significant amount of time now. There is no indication of when the new feature will be complete; as far as we know, it could be stuck in development hell. Regardless of the tech/coding side of the wiki, which I'm sure you are working hard at completing, the Real Vetting policy is evidently no longer an agreement. Since you like suggestions, I have two for you:

Halt current progress on development, consider the conclusions of the discussion, and make the necessary changes before you complete BM/search.
Complete the BM/search features concurrently with the discussion and make necessary changes afterwards.

I do not see why the wiki has to stop in its place while the community is unaware of what is being developed behind the scenes. The discussion and the conclusions drawn from it will still be here once you complete the new features. There is a point to continuing the discussion. Unless the development of the new features will actually change the current Real Vetting policy, the discussion is still relevant and still valid. --

Scottie_theNerd (argue) 12:40, 7 January 2008 (EST)

Current discussion goes around current implementation and current version of the Real Vetting. With Build Master and new Search Enegine many thing will change - and only trying them out will show how they will effect usability of the site.

Search engine will change way people will view builds. Great, Good and Others will only act as reference and wont be "really" in use - as each use can specify own categories as he/she wants.
Build Masters will change way people vote and the quality of the rating.

Those are the things we agreed upon and we are working on implementing. I am not on any pay check here so I don't have time (as some people) to waste on writing walls of text. Generally I am pretty tired of explaining this over and over again.

There is no indication of when the new feature will be complete - well maybe you can start coding?

There is no talking about changing - but about finishing something. Real Vetting are in beta stage now (beta = not finished) - and experience from using it goes accordingly to that.

As professional web-developer with (univer degree in app.dev. and on a nice pay-check) I can ensure you that development does not work like this. Discussing old beta while new version is in work based on previous discussion - is simply waste of time. In order to get this work going properly you need at least to complete current revision - test run it - and only THEN take up the discussion.

I understand that some people may think that changing the policy as easy as changing the real code and implementation of it - but it is not. As I did many times before - there is plenty of stuff normal user can do on pvxwiki - booring work that no one wants to do. Everyone wants to jump to the top:) gcardinal 13:15, 7 January 2008 (EST)

No one's said anything about not having anything to do -- or is this your way of telling me to shut up and go do something else with my time? And what's with this: "There is no indication of when the new feature will be complete - well maybe you can start coding?? You're doing this in your own time, and that means you're the man with all the plans. I'm pointing out that there's a lot that we don't know. I don't understand what you are insinuating here. --

Scottie_theNerd (argue) 13:26, 7 January 2008 (EST)

Email me the code. I'll learn it and w/e but i still think getting an idea of what needs to be done is a good thing, all of those new things you are implementing have nothing to do with the "other" category being filled with useless garbage because the standard is set too low. Again its about quality not quantity.--Shadowsin 13:38, 7 January 2008 (EST)

As gcardinal has been saying: code first, then talk. --

Scottie_theNerd (argue) 13:44, 7 January 2008 (EST)

Email me the code I'll help work on it.--Shadowsin 13:52, 7 January 2008 (EST)

That wasn't my point, but whatever. It all comes down to the order of priorities gcardinal has listed out. Now if you'll excuse me, I'll be going back to the boring things that no one wants to do. --

Scottie_theNerd (argue) 13:55, 7 January 2008 (EST)

Would be great Scottie, this kind of stuff always makes sysops life easier. gcardinal 15:00, 7 January 2008 (EST)

I'm glad you think so. --

Scottie_theNerd (argue) 15:04, 7 January 2008 (EST)

"Other" Category changes

I'm probably missing something here, but wouldn't this only require changing the Real Vetting text, as well as the Templates for Other, then going through and removing builds that no longer qualify? I'm just trying to get a feel for what's going on here, not piss anyone off, so please take this as it is, simply a request for information, not any sort of smartassery on my part. cedave _{(contributions_buildpage)} 16:12, 7 January 2008 (EST)

Yep. Servers would probably go offline for a few hours. And for those who may be listening and partaking in this, change "other" template last. -- Armond Warblade

{{sysop}} 01:41, 8 January 2008 (EST)

Proposing addendum to Trial builds

gcardinal makes a good point about teaching new build creators to create their build articles following the Stub -> Trial -> Testing cycle rather than creating a build off the top of their heads and putting into testing. The problem, as I see it, is this:

A user will often create an account for the purpose of sharing a build they came up with.
New users are often over-excited about getting their new build posted, tested and vetted as soon as they can. They will immediately put the build into testing.
These builds are usually immediately voted into trash.

This process is not helpful to the build creators and to the community as a whole. Generally, this is the fault of the build creators for not reading the Real Vetting policy, but as with most wikis we cannot expect users to read the policies before contributing, so it is up to the rest of us to make up for it. However, it is clear that users will continue to prematurely send builds into testing. Real Vetting outlines that the discussion should take place during the Trial period. In practice, build creators will only make changes during or after voting, especially when there has been no prior discussion.

Proposal

I therefore propose an addendum to the Real Vetting policy:

All builds must undergo a mandatory 5-day trial period before being placed into Testing.

In practice, this would involve editors replacing premature Testing templates with the Trial template until the mandatory trial period has passed. The exact length of the trial period is up for debate, but I believe this proposal has the following benefits:

It educates new editors on the proper build creation process.
It prevents possible new ideas from being trashed because they have not been thought out properly.
It encourages thorough discussion by the community over a longer period of time; and more time means more people can get involved in the creation process.
It allows editors time to compare to other builds (thus using PvX:WELL before actual Testing), as well as preliminary testing to pick the right skills.
It provides an obligatory "shelf time", giving the build creator time to reflect on the build's fine-tuning before vetting.
Instead of shutting down new build authors, we can familiarise them with the concepts and basics of why builds work well.
Because it deals with builds before they are vetted, this should not affect development of the BM/Search Engine.

-- Scottie_theNerd (argue) 16:16, 7 January 2008 (EST)

Additional notes

In light of recent discussions, a five day period may be too long for most builds. A possible modification to the proposal is to shorten the mandatory trial period to three days.
Promoting Trial builds is recognised as important in order to facilitate new build creations. Suggestions include more prominent places on the Main Page and possible "Featured Trial" builds.
The Real Vetting policy needs to clarify the distinction between "Trial" and "Testing". In common usage, they mean the same thing, and as the discussion as pointed out, the only real difference in our practice is that editors can vote on Testing builds. A possible solution is to rename one or both of the categories. In the big picture, we could be emphasising the build creation process (i.e. by using Trial as the main pre-vetting category) rather than the result (i.e. Testing + voting).

-- Scottie_theNerd (argue) 04:35, 8 January 2008 (EST)

Discussion

Would IAR be applicable to users with significant contributions? Or could we allow for users with significant contributions to be sidelined from this? Also, how would we apply this? I don't think most contributors look at a build's history before voting, and often the A.N. takes a day or two to get to it, at which time the mandatory period would be over. Besides, I personally cannot recall all but a few times I've visited the Trial section, and these were normally at the request of other users.

cedave _{(contributions_buildpage)} 16:21, 7 January 2008 (EST)

I don't believe that experienced contributors should be sidelined. All builds should go through a consistent process. Even experienced build creators are open to criticism, and often this will form the basis of a better build. Good builds don't spring up overnight; they take time to plan, test, re-plan, re-test, and finally put up for public testing. For the veterans, the trial period is a formality.

In regards to applying the proposal: same thing as manually adding tags to vetted builds. An editor has to check if a build has enough votes for a category before adding the appropriate. If a user sees a build in testing and it hasn't met the requisite trial period, they only need to sub the Testing template for a Trial template. We don't need admins to enforce it, just as we don't need admins to add categories and trash tags when builds meet the requirements.

I admit, I don't visit the Trial section that often myself, but if there's a place where builds are thrashed out for quality, it's in Trial and not in Testing. --

Scottie_theNerd (argue) 16:30, 7 January 2008 (EST)

Hmmk. I get your point. I don't necessarily agree, particularly since I prefer the Testing -> Trash -> Trial -> Testing form that seems to work a lot, but maybe after using it a while it'd become more.. suited to me. Or rather, I'd become more suited to it. Either way, I could see supporting this, but I do still think that IAR should take strong supremacy in cases involving builds like the SP, BA Ranger, Touch, and other famously meta builds.

cedave _{(contributions_buildpage)} 16:38, 7 January 2008 (EST)

While it could be potentially useful, I find it more annoying then helpful. — Skadiddly[슴Mc슴]Diddles 16:40, 7 January 2008 (EST)

Quick answer: Build feedback. Get the comments before the votes start coming in so the build can be influenced and shaped by the community.

cedave _{(contributions_buildpage)} 16:42, 7 January 2008 (EST)

I think the case of putting up meta builds is the exception for this proposal -- clearly, if they are used by thousands of players daily, there's no doubt that they have -- in a sense -- already been "vetted" by the community and the build is being put up solely for reference. This proposal is more geared towards original creations. For example, the first build on my Recent Ratings page is this. The whole build is made in one shot; no refinements, no discussion, and it's likely to be trashed before the day is over.

On the surface, it does sound like it'll be annoying, but for a good purpose. Things become clearer once we've slept over it. I don't expect that any of us will be thinking of Guild Wars before we sleep, but setting it aside for a day or two and coming back to it can bring a refreshing breeze. There's no hurry when it comes to vetting builds; we can wait a few days, and we can use those few days to fine-tune those builds. We generally look for quality over quantity, so this would also encourage prolific creators to spend more time putting builds together instead of slapping together 8 skills for the heck of it. --

Scottie_theNerd (argue) 16:48, 7 January 2008 (EST)

Theoretically, this might be a good idea. In reality, some builds don't need to go through trial(and really, need to not go through trial). As well, the only real difference between trial and testing is that testing builds can be voted on. Testing or even vetted builds are changed often. --— Edru/QQ 16:50, 7 January 2008 (EST)

That is true. However, many builds in Testing need not go through radical changes during voting -- indeed, some Testing builds change so much during voting that it defeats the purpose of voting in the first place. I think one of the reasons why builds are slow to vet is because we like to wait until things settle before voting, and by then we forget about it. This is more a of a push to formalise the distinction between Trial and Testing: that builds in Testing should be complete and not be altered unless there is a gaping flaw that needs changing, in which case all votes would be struck out as current status quo suggests. --

Scottie_theNerd (argue) 16:56, 7 January 2008 (EST)

OHSNAPSELF-UNDERMINE -- Possible problem with proposal: if we really do want to get users to follow the Real Vetting process, we should place more emphasis on Trial builds on the main page instead of stuffing it into "Miscellaneous". But that has more to do with the complacent methodology we share, in which the votes are the feedback rather than the qualitative feedback Trials should be get. --

Scottie_theNerd (argue) 17:10, 7 January 2008 (EST)

Might I suggest a giant CLICK HERE IF YOU ARE NEW TO PVX button on the main page that takes users to PvX:Real Vetting? >.> On a more serious note, yeah.. Trial builds would need more emphasis. Big time.

cedave _{(contributions_buildpage)} 17:14, 7 January 2008 (EST)

I'm not sure it would improve the quality of builds here, but it will reduce the number of new users we chase off, who may later make valuable contributions. Also, we need a concise, well written noobie guide, prominently placed on the main page. Lord Belar 17:22, 7 January 2008 (EST)

Aye, it won't necessarily improve the quality of the builds. What it does do is circulate the knowledge that we have accumulated from our experiences. We trash a build, and it's gone. We keep a build in trial, thrash it out the long, hard and painful way, and we teach a newb how to fish. --

Scottie_theNerd (argue) 17:26, 7 January 2008 (EST)

I like the idea, I also think that there should be a sort of featured trial build bit so that they get more attention, thats another reason many builds are put straight into testingUnder Gunned 17:19, 7 January 2008 (EST)

Featured Trial builds would be a good idea. If you think about it, it's like a presidential election. You want the candidates to have their ideas thought out before the voting takes place... --

Scottie_theNerd (argue) 17:21, 7 January 2008 (EST)

(Freakin huge EC)Even the notion of a mandatory stretch of time makes me uneasy. If the problem you've mentioned, that users won't familiarize themselves with policies, is prevelant, implementing this doesn't solve anything. Giving editors the ability to put builds from premature Testing to Trial does squat. New users still won't accept the utter "failure-age" of their build, and if anything, disallowing votes would halt the process of these newb users learning. There's something lost in mere talk; often times users will vote without even commenting on the Build's talk page, and these votes paint a broader picture, that force the new user to discuss the build's glaring flaws. There certainly are many votes today that spark revealing discussions. To be honest, I don't believe anything is wrong with the Testing to Trash to Trial, or however the variations work, that goes on these days. This seems like a policy intended to accomodate new users, but in reality fails to do so. Shen(contribs) 17:24, 7 January 2008 (EST)

"force the new user to discuss the build's glaring flaws" No, as soon as they see the Trash tag, they QQ and leave. Lord Belar 17:28, 7 January 2008 (EST)

Talking to those kinds of users get nowhere. They won't accept the fact the build sucks.

Shen(contribs) 17:29, 7 January 2008 (EST)

Sorry for the ECs, Shen =P

Anyway, a key factor to the site's usability is the fact that most new builds come from new editors. Now, we can either chase them away with our expertise and see them replaced with more stubborn editors; or we can drop our shield of elitism for a bit and explain why builds work well and why builds don't before the votes are cast. And if the creator is has a severe case of tunnel-vision, we've got the "we told you so" element to back up the votes sending the build to ~~hell~~ trash. Things wouldn't change that much; a longer trial period (compared to no trial period) may discourage the stubborn editors. --

Scottie_theNerd (argue) 17:32, 7 January 2008 (EST)

Only difference is you are giving the author the prerogative concerning the trashing of the build. How effective is this in achieving the purpose of this policy? No really, I'm not sure how. Good grief, it is very hard to be discussing this nebulous region.

Shen(contribs) 18:09, 7 January 2008 (EST)

At the moment, we're not even following the policy 75% of the time. We don't vote for what the criteria specifies, we don't follow the build creation guidelines, and we certainly don't respect what the Real Vetting policy suggests about Trial builds and Testing builds. According to Real Vetting, the vetting begins at Testing. In practice, we are putting builds through testing, trashing them, testing, trashing, and rarely does a trashed build actually go to trial. What this proposal aims to achieve is to bring some form of standardisation to the way we are handling new builds. Either that, or we change Real Vetting to reflect what we are doing now -- and it doesn't look like that is a practical option with current developments. --

Scottie_theNerd (argue) 18:26, 7 January 2008 (EST)

I see, but to impose a mandatory 5 day trial period still rests uneasily with me. You didn't answer my question.

Shen(contribs) 18:35, 7 January 2008 (EST)

You got me confused on what you were referring to :3 Could you rephrase? --

Scottie_theNerd (argue) 18:46, 7 January 2008 (EST)

You know, my train of thought got molested by Cedave. I'll sleep on it, don't think this is over.

Shen(contribs) 18:53, 7 January 2008 (EST)

Regarding making trial builds have a minimum of 5 days, I disagree. With 154 builds already in trial, nearly half of them will most likely be abandoned because the author leaves the build and the community lets it sit and not suggest improvements. Trial builds are rarely visited without being in Recentchanges (at least from my knowledge), and increasing the time the builds must be there, which increases the amount of builds that will be in trial at one time, won't help the build's be visited and tweaked. — Victoryisyours (talk/RfA) 18:38, 7 January 2008 (EST)

Trial builds get little activity because the wiki gives them little coverage. If 5 days is too long, then 3 days. Bumping a low-activity Trial build to Testing will only increase activity because it's placed on a more prominent place on the front page -- and that usually only leads to builds being sent to trash anyway. It's become routine now, and it's become this way because of the emphasis on Testing builds and the lack of awareness of the Trial stage. --

Scottie_theNerd (argue) 18:46, 7 January 2008 (EST)

Victoryisyours (talk/RfA) 18:49, 7 January 2008 (EST)

Precisely; I agree with you. Under Gunned's suggestion of Featured Trial builds would work too; builds get a huge spike of activity when they get a nice shiny feature on them. --

Scottie_theNerd (argue) 18:51, 7 January 2008 (EST)

I think having featured trial builds would be an excellent idea. The link to the trial category should also be given more prominence on the main page - right now, it's down in miscellaneous with the stubs, which aren't really supposed to get much feedback. Honestly, the entire point of the trial section in the first place was so that builds would have somewhere to go after stubs (which are completely ignored) where they wouldn't immediately be voted on. ¬ Wizårdbõÿ777(sysop) 19:00, 7 January 2008 (EST)

I think 5 days is a bit excessive dont you? maybe a 2 or 3 day trial period but not 5 thats slow. --Shadowsin 19:06, 7 January 2008 (EST)

Btw get rid of stubs all together, is wut sandbox's are for yeye?--Shadowsin 20:52, 7 January 2008 (EST)

I second that build stub says to me, "hey not only does this build suck as is but I don't even feel like its good enough to try and test out yet."Under Gunned 20:57, 7 January 2008 (EST)

I'd just like to point out that 5-day mandatory trial is too long for some builds and too short for others. — Rapta

(talk|contribs) 22:07, 7 January 2008 (EST)

5 days is too long period, if a build sucks, it does not need to sit around festering for 5 days so people can QQ about how badly it sucks. --Shadowsin 22:57, 7 January 2008 (EST)

Five days might be too long. If most people feel this way, I suggest 3 days at minimum -- it's a nice odd number that balances time to discuss while not rushing new builds into Testing. Bear in mind too that not every build has to go straight into Testing once those three days are over. I think 3 days is a good balance if 5 days is too long; however, I would rather see builds which are agreed to "suck" not go into Testing at all. --

Scottie_theNerd (argue) 04:26, 8 January 2008 (EST)

Stubs is also for when people throw together a number of mini skill bars from team builder or whatever.
In the ideal situation, the build would go into trial, people would discuss it for five (three, two, whatever - you know how I am about policies) days, if it fell under WELL's reign, such would be discussed and explained, the build would be perfected with the opinions of others (particularly BMs, etc), and then it would go into testing and do better.
We all know that things don't go according to plan most of the time (re:me and policies again), but trial builds on the main page would help that.
-- Armond Warblade {{sysop}} 02:43, 8 January 2008 (EST)

I've realized, though I can't really say why it took me so long, that this will definitely increase the quality of builds that make it into testing. Admins' jobs under this policy would be much easier, because Welling would be in abundance, and for justified reasons, too. Should we then edit the note about how "testing builds don't have to be good, they're just there to get voting attention"? Though I've ceded my earlier argument, I'm still not sure about the time requirement. Would it be feasible to simply allow editors to plop a trial tag on builds as they deem prudent? This'd of course necessitate a overhaul of the meaning of "Trial", but it'll simplify things in my opinion. Shen(contribs) 16:52, 8 January 2008 (EST)

Builds in Testing get WELL'd. Trial builds, despite being more completed and a stub, and since they are still technically "under construction", don't usually get WELL'd. So having a policy that reduces the number of builds in Testing would result in fewer builds being WELL'd. — Rapta

(talk|contribs) 17:04, 8 January 2008 (EST)

That plan seems to conflict with The Administrate Users, Not content policyUnder Gunned 17:10, 8 January 2008 (EST)

Well, should Administrators ignore WELL then? — Rapta

(talk|contribs) 17:21, 8 January 2008 (EST)

not really, after I looked WELL is really for clearing similar yet inferior builds, what Shen proposed is closer to deciding which builds get to exist, not that the admins would abuse, it just seems to conflictUnder Gunned 17:33, 8 January 2008 (EST)

Wait, what? I was under the impression clearly inferior builds would, as in in the future, under this new policy, as opposed to the protocol today, be welled after thorough explanation of the flaws while in trial. That's the entire point of the policy.

Shen(contribs) 17:36, 8 January 2008 (EST)

I'm really not sure, thats just how I interpreted the literal words on the policy page, thats just not how it usually ends up working anyway, so yeah, if you wanna double check that look at the articles EDIT: Under the proposal as is it says editors can WELL earlier, it didn't change WELLing itself. That and if I read right the WELL is really used to delete builds clearly inferior to simmilar builds.Under Gunned 17:40, 8 January 2008 (EST)

"Abandoned" Builds

A problem I've had to deal with as a kinda inexperienced build creator is having builds that are simply not noticed, is there an easier way of getting a build quickly noticed and discussed over? Simply putting a build in the trial phase doesn't seem as an effective way to quickly understand faults in a build whereas putting a build into testing can ruin a build's reputation entirely. I suggest a way of showing recently added builds to keep good and bad ideas moving.--Emeralddragon2 03:38, 8 January 2008 (EST)

One problem I see with a "recently added" is that is usually doesn't differ from the Recent changes list. New build articles pop up all the time, and as far as I know, there is no method in which the wiki software can distinguish between an edit and a new page. Also, new additions are not always complete, furthering the problem of identifying which new builds are ready for open discussion.

The discussion above this has two interesting suggestions: one is to make "Trial" a prominent category in itself, in the same way (or even replacing) the Testing category on the Main Page in order to promote discussion before voting is allowed. The second suggestion is a "Featured Trial" section, showcasing some of the more interesting ideas to generate discussion. --

Scottie_theNerd (argue) 04:22, 8 January 2008 (EST)

After looking over this article, I now understand how these suggestions are going to be helpful (mainly in showcasing builds so they aren't left to gather dust), thanks for "simplifying" the discussion for me! --Emeralddragon2 04:43, 8 January 2008 (EST)

I do believe GuildWiki and Wikipedia have a "newly created articles" special page. Also, recent changes marks an edit with N for new pages and refuses to show you a diff page for that edit. -- Armond Warblade

{{sysop}} 12:26, 8 January 2008 (EST)

That is certainly correct. How silly of me to forget. --

Scottie_theNerd (argue/criticise) 14:28, 8 January 2008 (EST)

It's not just an N. It's an N. Bold ftw ¬ Wizårdbõÿ777(sysop) 17:19, 8 January 2008 (EST)

Special:Recentlyadded? — Victoryisyours (talk/RfA) 18:38, 8 January 2008 (EST)

Special:Newestpages? — Rapta

(talk|contribs) 18:40, 8 January 2008 (EST)

Never knew that existed...should've checked the the list of special pages =/. —

Victoryisyours (talk/RfA) 18:41, 8 January 2008 (EST)

RTFM :-) – HHHIPPO ‹sysop› 03:27, 10 January 2008 (EST)

Hhhippo just got over nine thousand points, I think. -- Armond Warblade

{{sysop}} 04:18, 10 January 2008 (EST)

Instead of newest pages couldnt we have special:newestbuilds, so the pages all have the Build: prefix to navigate to new builds easier? —

Victoryisyours (talk/RfA) 07:11, 10 January 2008 (EST)

Can we do that without including build talk pages? -- Armond Warblade

{{sysop}} 12:23, 10 January 2008 (EST)

I would have thought so. Couldn't you just set it not to include /Build_talk: on the list?PheNaxKian (T/c)

12:27, 10 January 2008 (EST)

That would be simple because Build: is considered a separate namespace from Build talk: (I think). But even if I'm wrong about that, I know Special:Uncategorizedpages shows Builds but not Build talks. ¬ Wizårdbõÿ777(sysop) 15:57, 10 January 2008 (EST)

Innovation v3

I was looking through a couple of build ratings (in the great catagory) and i noticed a couple of people were giving 2's or something in innovation because it's meta. While i know the current discription allows this with the suggestions to the policy being raised i thought this would be a good a time as any to change the deffinition. While currently the deffinition of innovation allows you to vote a meta build both hihg and low, it would jsut makes sense to me to say that if it's meta it warrent's a 4/5 in innovation, because it's basicly the ebst your going to get if it's meta, so it would make sense to me that the best build available at that point in time egt the highest possiable score (of course if we lower the weighting of innovation to 0% this doesn't matter as much but i'd like this clearing up)PheNaxKian (T/c) 13:40, 10 January 2008 (EST)

Which is why innovation isn't even a viable category to sort/rate by.

Shen(contribs) 15:58, 10 January 2008 (EST)

it just needs a change of name so people understand we don't rate innovation but actually non-innovation. - Y0_ich_halt 17:26, 10 January 2008 (EST)

In theory, that's not true, the goal should be to have innovative builds be the interesting ones that present cool synergies or use traditionally bad elites, stuff like that, but manage to do so reasonably well. While we wouldn't want an unworkable innovative build, innovation shouldn't really be tied (in theory at least) to meta-ness or effectiveness. Unfortunately, the truth of the matter seems to be that people essentially ignore it as a criteria. Thus, here's what I would propose if/when this is possible. Rather than including Innovation as a rated category, include a check-box below Effectiveness/Universality which indicates that the rater thinks the build is particularly innovative. The problem is that with a lot of builds, people have very little to say about Innovation, but, because they have to give some score, the scores are largely arbitrary, certainly not based on any universal definition. A check-box I think might go a long way to solving that issue, and it also wouldn't force users to pick a specific number. If we kept track of how many voters had checked that box, we could then sort builds (using a separate category) by the percentage of voters who had elected to do so or some such (of course whether or not it was checked would have no impact on the build's score).

*Defiant Elements* +talk 18:17, 10 January 2008 (EST)

We could also have a separate checkbox for meta-ness.

*Defiant Elements* +talk 18:26, 10 January 2008 (EST)

That sounds great.

Shen(contribs) 22:13, 10 January 2008 (EST)

Acutally the best suggestion for the topic I've heard so far.—

Cheese Slaya (Talk) 00:44, 11 January 2008 (EST)

you spoke right from my mind, DE. - Y0_ich_halt 08:48, 11 January 2008 (EST)

Best idea I've heard. PheNaxKian (T/c)

09:51, 11 January 2008 (EST)

Poll: Rename Universality to Flexibility

When Universality was first named, it included some general notions about both where a build could be run and how flexible it was. However, the fact of the matter is that while the name and the definition never really caught up, the category has come to mean flexibility alone. Thus, I'd propose that we change both the name and the definition to make it more clear what we mean (I don't know about other people, but, personally, I've gotten a lot of questions on the subject from people who really weren't clear what universality meant or thought it was merely a measure of the number of areas in which a build could be run. *Defiant Elements* +talk 18:26, 10 January 2008 (EST)

Support

The current name isn't clear and can be difficult to understand for new users. Flexibility makes much more sense.--Goldenstar 18:33, 10 January 2008 (EST)
Strong Support — Victoryisyours (talk/RfA) 18:35, 10 January 2008 (EST)
--Coloneh 18:43, 10 January 2008 (EST)
Makes it more clear for those with limited reading ability. Lord Belar 20:51, 10 January 2008 (EST)
¬ Wizårdbõÿ777(sysop) 20:51, 10 January 2008 (EST)
Much better than the current name.— Cheese Slaya (Talk) 22:04, 10 January 2008 (EST)
"Universality" implies something a bit more omniscient than "Flexibility". -- Scottie_theNerd (argue/criticise) 01:29, 11 January 2008 (EST)
duh! DarkstoneKnight (Υ/ζ) 02:53, 11 January 2008 (EST)
Like it really matters, but makes sense.--Shadowsin 12:40, 11 January 2008 (EST)

Oppose

Neutral

Discuss

This would differ from universality how? Lord Belar 18:29, 10 January 2008 (EST)

It's a purely semantic change, we'd enforce it in the same way, it would just to clarify the role of the category. I doubt anyone will have a problem with it, but if people have a better way to fix the issue, or for some odd reason they disagree, I want to give 'em a chance to speak up.

*Defiant Elements* +talk 18:31, 10 January 2008 (EST)

It's because people are like OMG IT CN ONLY BE USED IN GVG? and rate universality 0. —

Victoryisyours (talk/RfA) 18:35, 10 January 2008 (EST)

nvm, I thought this was for renaming innovation. Lord Belar 20:49, 10 January 2008 (EST)

Adaptability? Or maybe resourcefulness. I'm still getting the "more-areas=flexible" jibe. Maybe its just me. Shen(contribs) 22:08, 10 January 2008 (EST)

I mean... adaptability is synonymous with flexibility, so if one is gonna mean "more areas," the other will as well by the same token.

*Defiant Elements* +talk 22:13, 10 January 2008 (EST)

Yea, I'd have to agree. But it seems you are conceding there still is some ambiguity? If we're going to rename it, we should try to avoid such a possibility, at least when its this foreseeable.

Shen(contribs) 22:15, 10 January 2008 (EST)

Well yeah, I can see what you're getting at. I think that, at the very least, flexibility is an improvement over universality, but what would you suggest?

*Defiant Elements* +talk 22:18, 10 January 2008 (EST)

Suitability. Based on chance for it to be countered in the place its intended for. It's a different concept, I know.

Shen(contribs) 22:24, 10 January 2008 (EST)

Well... here's what I'd say about suitability: effectiveness and "universality" are intrinsically tied together to begin with; however, if I make a build that I claim is for AB that is clearly not suitable for AB, I think that would fall more under Effectiveness i.e. it will be ineffective in that area, than it would tie into the universality concept. I know you say it's a different concept, but as I said, it's already covered in effectiveness.

*Defiant Elements* +talk 22:28, 10 January 2008 (EST)

Man, that's two for two. I'll sleep on it. But as for flexibility, I'm leaning towards opposed.

Shen(contribs) 22:31, 10 January 2008 (EST)

(RI)Every possibility met the same roadblock, that is, it's already been covered in Effectiveness. Which makes me question the need for Universality/Flexibility as well. I fain would none-too-illogically postulate the inherent advantage of having two voting criteria, one an extension of the other, would be to more easily seperate the Great from the Good, presenting a more accurate assessment of a build's abilities. The rebuttal I would have for that would be that sometimes, this accuracy, or precision, if you want to be scientific, is skewed by misconceptions of the word. Yet abolishing the category isn't an effective solution either. What a pickle.

Shen(contribs) 23:15, 10 January 2008 (EST)

How about adaptability? or perhaps All-Rounded-ility? or Utility?

BaineTheBotter 05:14, 11 January 2008 (EST)

Poll: Increase scale for voting

For many builds, the scale of 1 to 5 doesn't give enough leeway to factor in subtle skill differences, for example some people may consider Devastating Hammer more effective than Earth Shaker, although under the current system they would both be likely candidates for a 5 in effectiveness. A scale of 1 to 10 or more would allow the finer differences between builds to be judged more accurately. Mike Tycn(punch out) 05:41, 11 January 2008 (EST)

Support

— Victoryisyours (talk/pvxcontribs) 07:13, 11 January 2008 (EST)
Means we can better distinguish between builds.PheNaxKian (T/c) 10:15, 11 January 2008 (EST)

Oppose

Universality serves this purpose fairly enough. Shen(contribs) 07:26, 11 January 2008 (EST)
The more votes it has the more distinguised it will be.--Shadowsin 12:30, 11 January 2008 (EST)

Neutral

I don't necessarily disagree with this; however, I would question whether the potential benefit is worth the immense hassle in re-evaluating every build. *Defiant Elements* +talk 11:17, 11 January 2008 (EST)
agreed whit above DarkstoneKnight (Υ/ζ) 12:45, 11 January 2008 (EST)

Discuss

Having read DEs point-would we have to re do every build on here? if yes i think we could do a variety of things (well not really but meh read anyway)

Agree no to post any builds untill all of the vetted builds get re-vetted
Double each users average score and use that (which sounds stupid so meh)

I think really on the first one makes any sense-HOWEVER this first option will have a huge benefit to the site. Obviously we have builds that were vetted back when the site was first set up and voting was allowed, and those builds may have been forgotten and been left where they are. This way we get to up date the database so that every thing's where it should be (you could do this even if you weren't going to change the scale....needs doing really...)PheNaxKian (T/c) 11:31, 11 January 2008 (EST)

@@ Line 513: / Line 513: @@
 === Neutral ===
-*I don't necessarily disagree with this; however, I would question whether the potential benefit is worth the immense hassle in re-evaluating every build.  [[Image:Defiant Elements Sig Test 2.JPG|50x19px]] [[user:Defiant Elements|<font color=black>'''*Defiant Elements*'''</font>]] [[user talk:Defiant Elements|<font color=darkred><small>''+talk''</small></font>]] 11:17, 11 January 2008 (EST)
+#I don't necessarily disagree with this; however, I would question whether the potential benefit is worth the immense hassle in re-evaluating every build.  [[Image:Defiant Elements Sig Test 2.JPG|50x19px]] [[user:Defiant Elements|<font color=black>'''*Defiant Elements*'''</font>]] [[user talk:Defiant Elements|<font color=darkred><small>''+talk''</small></font>]] 11:17, 11 January 2008 (EST)
+#agreed whit above [[Image:Image-darkstone knight Sig.jpg|19px]][[user:darkstone knight|<font color="Black">'''Darkstone'''</font><font color="Purple">'''Knight'''</font>]]<small> ([[user_talk:darkstone knight|<font color="black">'''Υ'''</font>]]/[[special:contributions/darkstone knight|<font color="purple">'''ζ'''</font>]])</small> 12:45, 11 January 2008 (EST)
 === Discuss ===