Proposal 1

I have two concerns with this proposal. First, the requirement that users recalculate the percentages themselves - what enforcement exists, and what mechanism will validate the calculation is correct? If a user fails to recalculate or calculates wrong, does their vote then not count and get struck out?

My second concern is with the line "A vote that is obviously inaccurate will be struck out. This includes reasoning such as missed facts on the article page or just statements that have no merit to the article." This is a good idea, but the wording needs refinement. From my experience on GW, most authors will see this as an excuse to strike out the majority of votes against the build, as in their opinion any negative votes are obviously the result of the voter missing a point, not the author missing a point. --- Barek (talkcontribs) - 05:40, 24 April 2007 (CEST)

If you can reword it better I'd appreciate it, it was the best way I could think of at the moment. For the calculations I suppose it would just be up to diligent users to make sure it is right, if it was miscalculated by accident it can be fixed, if it was changed to reflect a completely off % then it would be considered vandalism. God knows the build section had enough people crawling over recent changes for builds, I was one :)--Sefre SefresigTalk*Cont. 05:45, 24 April 2007 (CEST)
I can't think of a wording fix at the moment, but I'll try to think about it and post back later. Heh, who am I kidding? Actually, I'm just feeling lazy, and I'm hoping someone else will work on it before I get back to this. ;-) --- Barek (talkcontribs) - 06:08, 24 April 2007 (CEST)

About strike-outs: Definitely needs changing, perhaps just leave it to the admins. About revotes: Perhaps take the graying tool from PvX:NOTIFY. Armond 06:51, 24 April 2007 (CEST)

I've added that only admins may strike out votes. I tried to work it so that any bias shown by a admin could be questioned and overturned by another if necessary. I also improved a few points mentioned in above comments--Sefre SefresigTalk*Cont. 00:19, 25 April 2007 (CEST)

What do you guys think of this. How about you add in a new type of category in the Hierchary(i.e. Sysop, Beauracrat) that includes builds monitor. Im sure that at the current state with only 7(or 6) admins, there won't be enough of them to go around just to check build pages when they are more worried about other things such as Vandals and the like. If you create a Builds Monitor, they will have the power to strike out votes. Obviously it will be like RFA, just obviously not as important. Ni 01:44, 25 April 2007 (CEST)
Meh. I know that on GuildWiki, I checked every untested build every day. Furthermore, if we use a system whereby authors (or any other concerned citizens) attach Admin Review templates to the page, that should decrease the problems. This is something we could implement at some theoretical point in the future, but, for now, I think it is unnecessary. DE Sig Test 2 *Defiant Elements* +talk 01:47, 25 April 2007 (CEST)
No, I know that, but I have a feeling that this site is going to grow EXTEREMLEY rapidly as soon as we get the word out and policys set, and that is when might be a could idea to implement it. Ni 01:49, 25 April 2007 (CEST)
It is something to keep in mind obviously. Adding another layer to the hierarchy isn't a bad idea per se. But, it isn't something we need to be thinking about. Especially considering we don't even have an official build policy. DE Sig Test 2 *Defiant Elements* +talk 01:51, 25 April 2007 (CEST)
I agree, we have enough issues getting a standard policy, before we start enforcing. As for build moderators, I would volunteer to help out in that department. Back on guild wiki I basically cruised around recent changes for builds, if no one objects, but thats for later. I like the build moderator idea tho, as long as they wouldn't have any power other then resolving conflicts among users in builds, what I mean is no powers to decide build fates.--Sefre SefresigTalk*Cont. 01:57, 25 April 2007 (CEST)
Well, if I understand Ni correctly, the idea would be to make users Moderators to the extent that they could only moderate disputes regarding voting and would have the ability to strike votes. However, first of all, Admins don't yet have that ability, second, we don't have a vetting policy, etc., etc. Not a bad idea though, and I have a few suggestions as to who would make a good moderator. However, it obviously wouldn't be a volunteer thing. I would imagine that people would essentially nominate themselves and then would be voted on by all of the Admins. That also solidifies the hierarchy since Bureaucrats are at the top, and they can promote/demote Admins, and then Admins would be able to Demote/Promote Build Moderators. Still though, I think we should limit this discussion until after we have an established policy. DE Sig Test 2 *Defiant Elements* +talk 02:01, 25 April 2007 (CEST)
Yes I think this idea is interesting, but we should wait and see if it is necessary once the vetting system is designed and implemented, based on how its working. -- BrianG 03:03, 25 April 2007 (CEST)

So far it looks really good and is definitely better than the current vetting system on GW by miles. That said, I think problems will still arise and I am not sure if there is such a voting procedure that is 100% problem free. Once everything is in, we can start testing and see how it goes, and then make changes to the policy as needed. Lania Elderfire 05:07, 25 April 2007 (CEST)

I definitely agree. We all came into this knowing that no vetting system would be flawless, but I think this does about as good a job as is possible especially considering we have no ability to test it yet. Gcardinal is hoping for us to open the site to the public on May 1st, so I say that we wait for another few days or so, see what else gets suggested and then just decide on a policy. We can always update as new, unforeseen problems arise. DE Sig Test 2 *Defiant Elements* +talk 05:14, 25 April 2007 (CEST)
I take it theres no word that someone has found a way to add that auto tally extension? We can jsut do it ourselves if needed, not hard math.
Anyways should the templates and category's be created then? Or do we want to give other policies a chance first?--Sefre SefresigTalk*Cont. 05:39, 25 April 2007 (CEST)
It'd be best to wait until we decide which policy will be the official one. -Auron 05:44, 25 April 2007 (CEST)
I agree with Auron. We need to leave a couple of days so that we can get everything in place necessary for whatever policy we choose. So let's say that we need an official policy in about 4 days. But, let's not start doing anything substantive until we get a chance to use those four days to see what other ideas emerge. DE Sig Test 2 *Defiant Elements* +talk 05:46, 25 April 2007 (CEST)
If Gcardinal wants it running by the first then we will need at least a day to set it up and fix any immediate errors. As I understand that does give us 4 days to pick one, I'm not realy sure what else will pop up tho, this seems to be the grouping of most of the ideas I've seen on other pages and the two others.--Sefre SefresigTalk*Cont. 05:51, 25 April 2007 (CEST)
I happen to agree. I think this will, more likely than not end up being our official policy. I just want to make sure everyone gets their fair shot. DE Sig Test 2 *Defiant Elements* +talk 05:53, 25 April 2007 (CEST)
When and if this becoems the official policy someone will need to go through and fix some of my coding, someone more proficient then me to wikify it, as I used html in some places. And grammar corrections as well probaly, I'm only 17 :/--Sefre SefresigTalk*Cont. 05:58, 25 April 2007 (CEST)
And I am absolutely horrible at programming. Can't even do html that well. Lania Elderfire 06:04, 25 April 2007 (CEST)
When it comes to grammar corrections... Maybe we can appoint some people who will re-check every major thing admins will have to post? Like news, charge log, new policy, proposal's and so on. I'm from Russia, living in Norway so my English skills are equal zero :) gcardinal 04:13, 27 April 2007 (CEST)
I think people do that anyways. For example, I went through and reformatted/re-wrote pretty much the entire thing to clarify the English and make everything sound better. We can appoint people if necessary, but I think it would be better to just ask someone if you need help or to just let it be. Anything major will be revised regardless if I had to guess. DE Sig Test 2 *Defiant Elements* +talk 04:24, 27 April 2007 (CEST)


This policy suggestion is very similar to suggestions I've made in the past and was planning to propose something like this but haven't had time. Overall I think this is the direction we should go in. I have a few minor suggestions:

  • In addition to the minimum time period for a build to stay in untested, we should also implement a minimum number of total votes before the rating is applied. No sense applying a rating after 3 weeks if there have only been 2 or 3 votes. The minimum number of votes before a rating is applied should be higher, perhaps somewhere around 5 to 10.
  • Not sure about allowing "a mention of agreement of a previous voter". It will be too easy for people to say "what he said". Requiring an explanation of your vote in your own words will be important in helping us determine if the voter is voting fairly.
  • In regards to the conversations on what to delete and what rating will determine what category, I think we should have a section where middle ranking builds are kept, as they may be improvable or alterable, or may serve as inspiration. This should be a lower ranked category below favored. builds below a certain threshold, say 20%-30%, should be deleted.
  • Ideally if we could get some kind of search function going, we wouldn't even need categories as mentioned above. Instead, the user could filter the builds displayed by rating thresholds. For example he could request to see every Dervish build over 60% or over 80%.
  • I think this is already implied, but in case it isn't: Voting should never close. Votes can continue to be cast and the percentage should always continue to be adjusted.


This is another suggestion I made on the other wiki, to try to control the number of builds submitted. It may or may not work here so I thought I'd mention it and see what you guys think:

  • Require all builds to be submitted to the stubs section (or a specifically assigned section)
  • Builds require nominations from X (1? 2? 3?) number of users in order to be moved from stubs to untested.
  • Nominators are responsible to make sure the formatting is correct, that the build is not too similar to an already submitted build (by objective means), and follows the guidelines for build submission etc. (only objective issues, not subjective).
  • Nominators are also responsible to ensure that the submitter is familiar with the vetting policies, and should take on somewhat of a mentor role with new build submitters to make sure they understand the process and make sure they are handling the votes properly, making suggested adjustments to the build.
  • The main idea here is to reduce poorly written builds, and also make the submission of new builds more of a community process to prevent some of the build ownership issues and other issues caused by new contributors who are unfamiliar with policies etc.

Let me know what you guys think of all of these suggestions. If there is support for any of these ideas I can write them into the proposed policy. -- BrianG 03:03, 25 April 2007 (CEST)

I think you may of mis interpreted a few points.
  1. There would be no untested, just a section for new builds before they have enough votes to calculate a percentage. I'm not sure where you saw 3 weeks. Once a build has 3 votes the template showing the percentage could be added and then voting would never close.
  2. That should probaly say agree and mention specific points in above mentioned poster.
  3. I don't think anyone mentioned deletion of builds yet, the builds would be thrown into category's like 90%-100% to 0%-25%. The low end ones represent unfavored builds but there are more levels of popularity on each level.
  4. I don't understand this point, that would be a category, there would be a link on build page and t would take you to that range.
  5. Voting would not close.
I kind of like your second suggestion tho, perhaps you should draft a new policy to address submitting of new builds only.--Sefre SefresigTalk*Cont. 03:25, 25 April 2007 (CEST)
Sefre, I see what you mean, somehow instead of 3 votes I read 3 weeks, and was still thinking along the lines of the working with the old categories. You've already reached the conclusion I was on my way to, that if we have a rating system we don't need favored categories etc. I'm amending my suggestions above accordingly.
  • I do think the number of minimum votes should be a bit higher before adding the percentage rating. A percentage based on only 3 votes is not very meaningful, especially if that percentage might be used to determine if something should be deleted. I'd say we'd want at least 5 votes (or maybe more?) before adding the percentage or determining deletion.
  • In regards to the issue of agreeing with a previous voter, I think it is fair to require people to explain their vote in their own words. If it touches upon similar themes as another voter thats fine but it doesn't take much effort to speak for yourself. This is just an easier place to draw the line as far as making it reasonable to enforce.
  • The last point was just an idea, in the past some people have suggested a build search tool, where you could specify the profession and other optional filters and then you could get the builds you wanted. The ability to filter by rating would be cool too. Not sure if this is possible on the wiki but I am going to talk to someone who suggested it to see if they think a search tool is possible to code.
In regards to the nomination suggestion, I agree that it would fit well in a separate policy governing the submission process, for example PvXWiki:Submission. I'd like to get some more feedback here to see what people think. If the nomination system is used, we would need to have some isolated area for new builds to be submitted before they are nominated for voting. If you guys don't like the nomination requirement, I could rework it to create some kind of optional mentor system or something like that. -- BrianG 07:19, 25 April 2007 (CEST)
Needs a better way to browse. its a PITA to go to Farming builds, then to Warrior, then to precentage, then to the build you want. I would prefer the way it is over the way you have it set to browse. Maybe keep the current bowsing as it is, except next to the build, it displays the percentage. Ni sig Ni 03:28, 25 April 2007 (CEST)
I was kind of thinking that both ways would be used, there will be much less PvE builds then PvP and it would not take long to go through each category(farming, running, ect.). But there are many builds in the Ra section for each class, and it's not easy to go through. The PvE section browsing could be kept the same but with percentage category's added also. Such as PvE builds by percent and PvE builds by type. But PvP would have to be different for the sheer number of them. PvP Builds By Type but in each category there would be sub category's for percent ratings. Maybe even sub sub category's for classes, would make it much easier to organize.--Sefre SefresigTalk*Cont. 03:35, 25 April 2007 (CEST)
I have an idea. We create for example 3 categories:
  • > 25%
  • > 50%
  • > 75%
And then use the current build page, but instead of a grid of 2 columns of links for Untested and Tested for each type of arena, you would have 3 columns, with a link to each of the categories listed above. The categories could be set up inclusively, so that >25% would show you everything above that, or they could be exclusive meaning that category would only show you 25% to 49%. -- BrianG 07:19, 25 April 2007 (CEST)

My comments

I'm not reading through all that text up there. Sorry. I'm lazy and left this alone for all of two days. >.>

I will say, though, that I think there should be at least 5 votes before a vetting template replaces the testing one. I also don't think the build should be a part of the Favored or Unfavored categories until it's got at least 10 voters. This means we'd need two new templates (tentatively favored and tentatively unfavored).

I don't know about time periods before percentages. If we say wait three weeks and in the first week it gets a dozen votes, what do we do? And what do we do if it has one vote after those three weeks? I think we should stay away from this.

Anyway. That's my two plat. -- Armond WarbladeArmond sig image{{Bacon}} 19:28, 25 April 2007 (CEST)

If you think a improvement can be made go ahead and change it, if someone disagrees then they can talk about it here, just because I drafted doesn't mean this is my policy, I think maybe one part of it was my idea originally. The 3 votes was just a number I pulled out of the blue that was higher then 2, for the sake of wording in that section.
Why would we need category's for under 10 builds? Wouldn't that just add more work to be done per page, and I don't really see any advantage by doing it? And how would status be determined up until it gets 10 builds? --Sefre SefresigTalk*Cont. 21:44, 25 April 2007 (CEST)
Sorry, misread that a bit, There would not be any unfavored or favored category's. But there would be percentage ranges, high end percents to low end percents. --Sefre SefresigTalk*Cont. 21:48, 25 April 2007 (CEST)
How about one template that replaces favored and unfavored (ok that's probably an obvious point but bear with me) that we input the percentage on, and then we add it to a category by tens of percents approved? So, for example, we might have {{vetting|62}}[[Category:60-69% builds]]. How does that sound? -- Armond WarbladeArmond sig image{{Bacon}} 06:02, 26 April 2007 (CEST)
Yeah I think that the direction we are heading but I'm not sure if we need the breakdown so small. I suggested in 25% chunks, with the bottom threshold being deleted, but I think 20% is the most we'd want to break it down by. Anyone else have an opinion on that? -- BrianG 06:19, 26 April 2007 (CEST)
If going with this method, then I personally think that 20% grouping ranges would be best - that fits nicely into an equivalent of a five-star rating system. --- Barek (talkcontribs) - 06:24, 26 April 2007 (CEST)
I would say 20 or 25% increments, in a system like a 5 star system or a 4 star system. It just seems natural, i dunno Lania Elderfire 06:39, 26 April 2007 (CEST)
I like it when things are specific, but I can see the advantage of a 20% system. I'd rather not do 25% as that will only leave us with four categories (but then again that's one less category to patrol...) -- Armond WarbladeArmond sig image{{Bacon}} 07:33, 26 April 2007 (CEST)

Sections to Expand

I have been cleaning up the page, and I think there are a couple of things I would change about the policy. First, I think it is a smart idea to require that builds begin in the stubs section and move into untested only after some kind of pre-vetting vote. This way we can filter out the obviously bad builds, the copy-cat builds, etc. Also, I think this has been mentioned above, but, I also think we need a prerequisite amount of time spent in the "New Builds" category before they can be moved into one of the percentage categories. DE Sig Test 2 *Defiant Elements* +talk 00:41, 27 April 2007 (CEST)

I was kind of thinking something like Briang's idea for nominations would work, but as long as no one objects you can go ahead and add a req. time in untested for now.--Sefre SefresigTalk*Cont. 00:57, 27 April 2007 (CEST)
Defiant, I'm with you on the stubs section (although we can call that section something different if we want). What do you think of my nomination system proposed above? Not quite as elaborate as having a pre-vote but it should serve the purpose. -- BrianG 01:28, 27 April 2007 (CEST)
I was about to chose 2 nominators as a reasonable number and write up a section on this, and then realized you've already done exactly that, nice work! I just added a couple extra sentences to further define the nominators' responsibilities. -- BrianG 01:35, 27 April 2007 (CEST)
Question: What happens if the build doesn't get nominated? Or, what if there is significant opposition instead? One of the things I disliked about GuildWiki was that the stubs section was so cluttered. I would always want feedback on my builds before people actually voted on them, but I couldn't get feedback on stubs since the section was so cluttered. Should we have something whereby users can nominate the build for deletion? Or, alternatively, we could have a period wherein if the build doesn't get nominations in X period of time, we simply delete the build...? Thoughts.
On an unrelated note, I would say that currently, I believe this is the front-runner among the vetting proposals and that I would support it over the other candidates. DE Sig Test 2 *Defiant Elements* +talk 01:40, 27 April 2007 (CEST)
I think nominating of builds should be a new policy, this page is beginning to get cluttered. Considering we have mini policies for other aspects. Really, PvXwiki:Build vetting procedure should be the over view of all aspects of vetting process(with links to polices concerning each part) and this page should be only the vetting and categories.
I do not think there should be a time limit but the nomination for deletion is a good idea.--Sefre SefresigTalk*Cont. 01:46, 27 April 2007 (CEST)
True, it has a lot of ideas, but, first, it is not a long page, and, for now, we can leave it as is. If people have trouble understanding what is on the page, we can think of breaking it up. DE Sig Test 2 *Defiant Elements* +talk 02:03, 27 April 2007 (CEST)
Just so its clear I do support this policy, for now :) gcardinal 02:10, 27 April 2007 (CEST)
I see someone has added a note about nominating for deletion. This could work, but I'm a bit worried that people may get overzealous and have a negative effect on new build submitters who are slowly assembling a build in stubs. I think it should work a bit like the "Abandoned" system worked on guildwiki, where these types of deletion requests only come up if the build has been unchanged in stubs for a certain period of time without getting any nominations. -- BrianG 03:42, 27 April 2007 (CEST)

My point of view

If you ask me there is to many rules and they are to hard to understand for many users. That kind of policy, I think, creates very closed for public websites where only "geek"'s of the game has anything to say... but in terms of policy for the start this can work for the start.

main reason why I dont like that policy is because its not visual. You have author, 2 people who nominated, 1 watching admin and lets say 2 all time watching users. There is several problems:

1. Author must somehow promote (and under current policy he cant) his build to find 2 people who can nominate his build. Almost impossible task for a new user.

2. Lets say there 2 people who nominated build, if in any time they will find something wrong with it they can slay build and stop its development by simply doing nothing. If they go on vacation it will also stop.

3. People don't like writing stuff only the most advanced users and the ones who has something to say will go into the discussion on a build. Based on statistics from GW wiki we can see:

There have been a total of 206,279,041 page views, and 805,206 page edits since the wiki was setup. That comes to 10.21 average edits per page, and 256.18 views per edit.

So it will take 250 view's before a single edit.

4. We have also to think about why people visit site like ours. It is simply to get some help. Get some new builds, test them out and get some cash, slay someone in PvP and so on. Having so hard policy, with almost 10 steps for build getting into tested section we will also stay behind as it will take simply to long time for any change. Therefor users will not see any significant movement on our site and we will loose users.

5. There is a difference between crafting best builds GW has ever seen and providing people with what they want. I have more trust in a visual system where its easy to see what is happening without reading tones of discussion pages on topics like SoA Sliver is a bad build since it does not have an elite. Who cares if its outstanding build and slays everething on its way?...

6. I think we must have voting but it must be more simple to actually vote. It must be more survey looking thing. Becouse simply yes or no say almost nothing. There is things like Does it work? How accurate does it work? How easy to use? How hard to get skills? How hard to get gear? How much training is needed? and so on and so on. There is many aspects of a build that is all just as important. I feel like if we was buying a TV using current voting system we would go for 100" Samsung LCD and say that evrething else just dublicates that TV. And that is wrong, there is good builds that can help you to pass some hard missions but are useless for anything else and may even look stupid, but they are Simple, Easy to use and they do work.

7. Back to the mentors again, one way we could maybe make it better is by making own group of mentors and they will be automaticly assignet new builds. But it must show both in they userpage and on build page that they are mentors. 8. In the end I want to say that advanced voting systems simply never work. There is almost non websites online that are doing good with advanced rating system. But there is plenty of websites that server all kind of garbage but still by letting users sort, rate and filter servers one of the best things online.

I'm sorry if I was to hard on this policy and maybe its not much of a help. But this is just my general view on that kind of policy and I just wanted to tell about my point of view. gcardinal 02:09, 27 April 2007 (CEST)

I don't think you were so harsh, as much as you didn't understand a couple of parts. As to the nominators, all they have to do is nominate. Once they do so, the process can continue without them. Second, a user doesn't have to promote the build, a nominator can be anyone who happens to view the build. As to the policy being too complicated, well, we can always make this into several small policies if necessary, and, the nominators are expected to help ensure that the user understands the vetting procedure. Assigning mentors is I think a bad idea since it is too large a task to manage. As to point number 6, any realistic system has to account for all of those elements, since they are all elements of a good build. That just comes with understanding Guild Wars. If the process it too long, we can tweak it, if it is too advanced, we can tweak it. However, since this policy has the support of a majority of administrators from what I have garnered, I am making this official policy. DE Sig Test 2 *Defiant Elements* +talk 03:02, 27 April 2007 (CEST)
So start making templates and categories then? I can start later to night if I am needed to help, gotta vacuum right now. Also, the ore compelx a system the less chance the flare wammos out there get vetted. I don't think it will seem to complicated once it becomes common knowledge like the old policy did on guild wiki. And this is far less complicated then the weird stuff there messing with over there.--Sefre SefresigTalk*Cont. 03:28, 27 April 2007 (CEST)
gcardinal, no need to apologize for expressing your opinion. The nomination idea is relatively new so it probably has some holes that need to be discussed. I'm not especially attached to the idea, so if its not going to work I won't mind. To respond to some of your comments:
1. This is definitely a small hole that we need to address somehow. Users can request nomination through the userspace, but this may be difficult for new users. Obviously some people will be browsing the section and will nominate things, but what about the builds that don't get nominated? As discussed above, should there be a time limit on the stubs section? Or can this be addressed by adding some text to the PW:WELL policy to deal with un-nominated stubs?
2. This shouldn't be a problem. Once the nominations are received, there is no action required from the nominators for the build to begin receiving votes. Inactivity by one or both of the nominators will not stop the build in any way. I mentioned on the page some expectations from nominators, but these aren't requirements, just expectations.
6. You say voting should be more simple but a yes or no system is the easiest way to keep voting simple. I agree that right now having people manually calculate percentages is a bit of a pain, but this is a technological limitation that we can hopefully address at some point.
7. This is a great idea and something that I had considered too. Assigning people as "build mentors" might help the problems mentioned in number 1. Its hard to tell if it will be neccessary without any experience with this type of system. We may find that regular users and admins are adequate to handle the nominations and deletions of un-nominated build stubs, but depending on how it goes we may find it neccessary to appoint "build mentors" to assist with this task. I agree with Defiant Elements that it will be easy to tweak things like this once we get going and have some feedback about how things are working. -- BrianG 03:38, 27 April 2007 (CEST)
Also, one more quick note, relating to Sefre's comment, I do think this system does have an advantage of simplicity even over the old guildwiki policy, mainly because this policy is pretty intuitive. It just makes sense. There were so many fights on guildwiki about what category a build should be in based on what votes were applied when, and when it should be moved back to another category, etc. With this system it all comes down to a simple math calculation that anyone can verify. The rest of the system seems to flow naturally from that, so it will have an advantage in being easy to understand and learn. -- BrianG 03:46, 27 April 2007 (CEST)
Yes DE, Im totally for this policy. The only point I was trying to make and you didnt see was that for someone to nominate a build first they need to be familiar with our policy, with other words spend some time on reading something they will maybe never need, then search for build and then nominate it. And how do they know if its nominated by someone else or not ? How can they see status ? And then it comes to point 6 you are right but my point is that different people have different understanding of what is Good build. By having only yes and no as a base we will never know they real opinion. And of course this is a great start, but personly when I posted my builds I didnt checked any policy at all on old wiki. I just had a great build and I posted it. Only when I got into a long discussion I was force to read them. Just a view from down here, so you up there can also see stupid users like me :) gcardinal 03:50, 27 April 2007 (CEST)
And when Im talking about simple vote system I mean first of all visual, then survey looking vote and max 1-2 lines of comments. Hardcore gamers will always write pages and pages if they are interested. Point Im trying to make is that we need people who never voted before to vote. Bad or good, quantity makes quality. Simple policy, on a half a page max, easy to understand and with visual representation of the votes it will make people vote more. gcardinal 03:50, 27 April 2007 (CEST)

(resetting indent) Alright, well, regardless, let's use this for now, see how things go once people actually start posting builds and stuff and tweak as necessary. We do however have one MAJOR question we need answered. If this is our new vetting policy, what do we do with all the old builds, since tested, unfavored, etc. no longer exist. DE Sig Test 2 *Defiant Elements* +talk 04:25, 27 April 2007 (CEST)

Snap I didnt think of that. List all at 100 until unfavored votes start coming in. Ni sigNi 04:27, 27 April 2007 (CEST)
IMO of course.

Gcardinal, I see you reverted DE's addition of policy tag. Does that mean you don't think it is ready yet or that you don't want it?--Sefre SefresigTalk*Cont. 05:25, 27 April 2007 (CEST)

Please read message on top. And again Im really sorry for this ...gcardinal 05:26, 27 April 2007 (CEST)
Community content is available under CC-BY-NC-SA 2.5 unless otherwise noted.