GuildWiki:Old votes

Old votes is an articles for old votes that have been closed. Copy old votes (and add at the bottom here) before removing them from the Category:Votes.

Profession in build names
1.) Profession in title: Xeeron, Kiiron, betaman, Kidburla, Shandy
 * Vote on putting the profession in build names, from User_talk:Xeeron. Result: Yes.

2.) Titles stay as they are: Rezyk

3.) Other:

(please finish voting by Jan 20th)

New layout of Main Page
I think we're ready for a vote on the different Main Page options. From what I see, the following alternates have been linked into the above discussion.
 * Vote on new layout of main page, originally from Talk:Main_Page, now found at Talk:Main_Page/Archive_4. Result: User:Barek/Main Page wins.
 * 1) Keep the current Main Page design Main Page
 * 2) PanSola's draft: Main Page/editcopy2
 * 3) Barek's draft: User:Barek/Main Page
 * 4) Xeeron draft #1: User:Xeeron/main page
 * 5) Xeeron draft #2: User:Xeeron/main page Barek
 * 6) Nunix draft (needs fleshing out) User:Nunix/mprdx Because it's very rough, here is a recap of Nunix' description of the concept: "Each box-heading would become its own portal page. I think still having a "table of contents" page like this one is fine, but it'd be nice if it wasn't the first thing you see."

So, lets tally the votes and see how the community feels on the changes (if any)
 * 1) Current version:
 * 2) PanSola draft:
 * 3) Barek draft:  Barek, Rainith, TheSpectator, Karlos, Xeeron, William Blackstaff
 * 4) Xeeron draft #1:
 * 5) Xeeron draft #2:
 * 6) Nunix draft:
 * 7) Other (specify):
 * 8) Need more time for other concepts:

International Names in all articles

 * Vote on if we will include all the international names for every City/Item/NPC/Moster/Quest in their articles From Talk:Ascalon City (Pre-Searing). Descision - No by a vote of 5 - 2.
 * Yes - Shandy Kerish


 * No - Rainith Xeeron William Blackstaff Xasxas256 Foo

Suffix for Chapter 2

 * Vote on chapter suffix. From GuildWiki_talk:Style_and_formatting. Result: "Ch2" wins.
 * Vote Results
 * (Ch2): Tetris L, PanSola, Barek, Lunarbunny, Rainith, Karlos, TheSpectator, Xeeron
 * (Chapter 2):
 * (Chapter Two):
 * (Factions):
 * other (specify): Cn (C1, C2, C... --Nunix)

Guild pages on GuildWiki
Vote: Do we want information about guilds in the wiki? Result: Ultimately inconclusive, but the leader is No. ''This vote was brought to an end with no clear winner (no choice recieving over 50% of the vote) as there have been nothing new posted for quite a while. See Talk:Girls on Top for the entire discussion.''
 * Yes: Kidburla, Tanaric, Shandy, Durub, DragonWR12LB
 * No: TheSpectator, Rainith, Xeeron, Xasxas256, 84.175, Crusty, William Blackstaff, Foo, JoDiamonds, Imperialist

(explain other in discussion)
 * Only Guilds that meet some criteria of notability (to be determined): JoDiamonds
 * Only Following strict rules (see below): Tetris L, Karlos, MRA,, PanSola, JoDiamonds, Ravious(yes to GWWC, no to GotW)
 * On notable event entries (ie: GWWC), list relevant guild names only: Barek, JoDiamonds

Layout of Build titles (No 2)
Vote on the exact title of builds to stop renaming of build articles. From User_talk:Xeeron. Result: Option 2 wins


 * 1) "R/Mo xxx" and "Ranger xxx": Xeeron
 * 2) "R/Mo xxx" and "R/any xxx": Rainith Xeeron FireFox
 * 3) "Ranger/Monk xxx" and "Ranger xxx":
 * 4) "R/Mo xxx" and "R xxx": Shandy Rainith

2 was what I initially started with (and grace did now), 4 is what I did inbetween. Hmmm quick vote? (till 24th of feb. please) --Xeeron 03:26, 18 February 2006 (CST)

I'm good with 2, and prefer 4. Shandy 18:44, 20 February 2006 (CST)
 * I'm good with 2 or 4, no preference over either. --Rainith 18:49, 20 February 2006 (CST)

First choice 1, second 4 22:52, 25 February 2006 (CST)

Individual fansite articles or single article?
RESULTS: Winner: Have a single fansite article. Since we're linking to the official ArenaNet list at the fansite article, the other issues above don't require a vote. The only open question is if we want articles such as photics.com and guildwarsguru.com to exist with redirects to the fansite article. --Barek 06:24, 6 March 2006 (CST)
 * Each fansite receives its own article.


 * Have a single fansite article.
 * 1) Barek
 * 2) Gem
 * 3)  (just a plain list, similar to ANet's list. No advertising.)
 * 4) Karlos: the article should describe what a fan site is, then link to ANet's list.
 * 5) Shandy
 * 6) Stabber, also think it should just link to Anet's list.
 * 7) Gares Redstorm, agree with Karlos. A short description of what a fansite is, more specifically what an official/elite fansite is(all facts, no opinions), then link to ANet's List. Something like Salvage Item 1. Definition and 4. List(link).
 * 8) JoDiamonds  Add me to the pile.  Seems like a landslide vote, here.
 * 9) 130.58 General info and a link to ANet's list (better and less judgmental than maintaining our own).
 * 10) Lunarbunny
 * 11) Rainith
 * 12) LordKestrel Simple link, nothing more.
 * 13) Ishmaeel One sentence. One link.


 * No reference to fansites except when linking to information relevant to an article.
 * 1) Ishmaeel No need for a single fansite article that contains a plain list and/or link to Anet's page either. Fansites are not specific to GW and saying a GW Fansite is a site made by and for GW fans is...(fade to silence). This should suffice for everybody out there: http://en.wikipedia.org/wiki/Fansite.
 * For what it's worth, I think it's worth having at least a token page to keep people from putting up new pages. They'll at least find *something* and hopefully understand that's what there is, and not try to reinvent the missing wheel. --JoDiamonds 03:50, 4 March 2006 (CST)
 * Ya, OK. That makes sense. --Ishmaeel 08:16, 4 March 2006 (CST)
 * Other (please insert description).

Deleting category Game Updates

 * Vote on deleting. From Category:Game Updates. Result: No deletion.

This category seems to have been abandoned, and for good reason. I can't think of any purpose it serves. Would anyone object to my nuking it? &mdash; Stabber 19:36, 14 March 2006 (CST)


 * Heck, let's put this to a vote.

Vote
Get rid of this category?

Aye
 * 1) Stabber
 * 2) (your vote here)

Nay
 * 1) El Karlos
 * 2) Pan Sola
 * 3) Xeeron
 * 4) Barek
 * 5) Acadia
 * 6) skuld
 * 7) DragonWR12LB 19:11, 30 March 2006 (CST)
 * 8) (your vote here)
 * 1) DragonWR12LB 19:11, 30 March 2006 (CST)
 * 2) (your vote here)

Style of differenciation between Prophecies, Factions and Core

 * Vote on suffix, prefix and style. From GuildWiki talk:Style and formatting. Result: Suffix (name) wins.

Vote on suffix
See GuildWiki_talk:Style_and_formatting/Archive_2 for the old vote/arguements given. Discuss below.

Voting format: instant run-off (remember to specify your second/third/fourth preferences if applicable!)


 * Alphabetical suffix: Skills (Core), Skills (Factions), Skills (Prophecies)
 * 1) Xeeron
 * 2) Stabber (Like Tetris below, I'd prefer a prefix instead of a suffix)
 * 3) Evil_Greven
 * 4) JoDiamonds (I'm fairly ambivalent about prefixes vs. suffixes, and think that should maybe be a future vote/discussion)
 * 5) Karlos
 * 6) (I'd make it a prefix though, not a suffix, i.e. "Core Skills", not "Skills (Core)"
 * 7) Barek
 * 8) Pan Sola (For article names only, and when it's article name, I don't htink it shoudl be suffix unless it's for disambiguation purposes)
 * 9) Evan The Cursed (Talk) (prefer w/ suffix; second choice: Excluding core, then including core)
 * 10) (vote here)
 * Numerical suffix
 * Including core: Skills (C0), Skills (C1), Skills (C2)
 * 1) Pan Sola (second choice: excluding core), and this vote choice is only for sub-categories, not for any article names whatsoever.
 * 2) (vote here)
 * Excluding core: Skills (Core), Skills (C1), Skills (C2)
 * 1) (vote here)
 * Other (you better have a really really great idea to vote for "other")
 * 1) (vote here)

Which images to use

 * Vote on the type of images to use for skill articles and other purposes. From: GuildWiki Talk:Style and formatting/Skills. Result: new FSK (w/ edited border for elites) only wins.

All options will use screen capture for unavailable/outdated icons.


 * 1) Use original fansite kit images, but in JPG format (as opposed to the currently used PNG).
 * 2) Use original fansite kit images in JPG format, new fansite kit for outdated icons (but not elites, which will be screen caps to perserve original golden border).
 * 3) Use original fansite kit images in JPG format, new fansite kit for outdated and elite icons (edited golden border).
 * 4) Use new fansite kit JPG images (edited golden border for elites).
 * 5) Use new fansite kit JPG except for elite (which will be screen caps to perserve original golden border).
 * 6) Use screencaps for everything to ensure ultimate uniformity
 * 7) Other (please specify)

Skill Icon Votes

 * Option 1 - old FSK only (screen cap elite/outdated)
 * Option 2 - old FSK default, new FSK (w/ edited border for elites) for outdated (screen cap elite)
 * Option 3 - old FSK default, new FSK (w/ edited border for elites) for anything missing
 * Option 4 - new FSK (w/ edited border for elites) only
 * 1) PanSola (2nd choice 3, 3rd choice 5, 4th choice 2, 5th choice 1)
 * 2) Rainith
 * 3) Barek
 * 4) Evil_Greven
 * 5) JoDiamonds (4, 7, 6, meh)
 * 6) Karlos
 * 7) Dinosaur Planet
 * Option 5 - new FSK except for elites (screen cap elite).
 * Option 6 - Screen cap everything
 * 1) Shandy (Option 5 second choice)
 * Option 7 - new FSK, with images altered to include the actual ingame border (haven't found anyone to do the border yet)
 * 1) Xeeron
 * Option 8 - Other
 * 1) LordBiro I vote for PNGs. I don't think there would be any discolouration with resize if the host had ImageMagick/NetPBM and the wiki was set up to use them.
 * 2) * My post here wasn't very clear. I've explained in detail on my talk page.
 * 1) * My post here wasn't very clear. I've explained in detail on my talk page.

Protect main page talk
Vote to protect the main page talk due to repeated spam bots. From: Talk:Main Page/Archive 5. Result: Protect and move.

The ballot

 * 1) Do nothing
 * 2) Move the functionality of this page to Talk:Main Page/editcopy, leaving only links to Talk:Main Page/editcopy, GuildWiki Talk:Community Portal, and User questions  here, and protect this page against vandals and people who refuse to read instructions then post things on the wrong talk page.
 * 3) Move everything on this page to Talk:Main Page/editcopy, leaving only a redirect here, and protecting this page (most spambots seem to key in to actual pages not what is on the pages themselves).
 * 4) Other

The votes

 * Do nothing
 * Move and protect
 * 1) Pan Sola (second choice Move everything)
 * 2) Barek
 * 3) Xeeron (this only differs from 3 in leave some links here, which I prefer)
 * 4) JoDiamonds
 * Move everything
 * 1) Rainith
 * 1) Rainith

Vote: Upper Case for Nouns
While I'm busy questioning the basic rules of GuildWiki to get us ready for Factions, I might as well question this one too. IMO the lowercase rule is the single most responsible reasons for broken/wrong links on GuildWiki, and hence we should reconsider it. Because of the fact that ANet capitalized most nouns (not just proper names) in ingame "labels", and since we agreed to use the ingame spelling, the vast majority of articles on GuildWiki has all nouns in upper case. This makes the rule "use lower case" kinda pointless. We'd probably have much less confusion if we'd simply follow ANet's pattern and capitalize all nouns (not just proper names) in all article names as well as category names.

Two (fictional) example, to make clear what I mean: Please tell me, which words shall be lower case, which shall be upper case?
 * category:(E)nchantment (S)pells by (S)kill (T)rainer (L)ocation
 * category:(P)et (R)esurrection (S)pells by (Q)uest (G)iver (L)ocation

I'd rather have a simple, 100% clear rule, even if it's not 100% according to proper English grammar sometimes. We shall put it to a vote. It the majority decides to keep the current rule, fine.

The Vote

 * Option 1:Keep the current rule, because it's abundantly clear.
 * 1) Karlos
 * 2) PanSola
 * 3) Evan The Cursed (Talk)
 * 4) Barek (maybe not abundantly, but clear enough)
 * 5) JoDiamonds
 * 6) Tanaric
 * Option 2:Simplify the current rule and capitalize all nouns in all article and category names. For verbs, adjectives, and adverbs still use the sometimes-unclear current rule.
 * 1) Rainith
 * 2) Xeeron (but have redirects, see below)
 * 3) Your vote here
 * Option 3:Simplify the current rule and capitalize all nouns, verbs, adjatives, and adverbs in all article and category names. Particles and propositions are lower case.
 * 1) Your vote here
 * Option 4:Other (specify)
 * 1) Your vote here
 * 1) Your vote here

No new votes in a long time, vote closes at april 3rd.

Vote on Article Name
And thus we come to another showdown between the Republicans and the Democrats... What name should this article (talking about the different elements in the game screen) hold?

Result: Interface


 * Heads Up Display (or HUD):


 * Interface:
 * 1) Tetris L,
 * 2) Bishop
 * 3) PanSola (second choice "Game Interface"; third choice "Gameplay Interface"; forth choice "User Interface"; fifth choice "GUI")
 * 4) Sagius Truthbarron (second choice "Game Interface"; third choice "Gameplay Interface"; fourth choice "GUI"; fifth choice "User Interface")
 * 5) Barek (second choice "User Interface", third choice "Screen Layout")
 * 6) Nilles
 * 7) JoDiamonds (Presuming IRV: Interface, User Interface, GUI, Gameplay Interface, Screen, Game Screen, HUD)
 * 8) James Sumners


 * User Interface:
 * 1) Ravious,
 * 2) Havral Glommon,
 * 3) Xeeron,
 * 4) 130.58,
 * 5) Stabber,
 * 6) FireFox,
 * 7) LordBiro


 * Screen:


 * Game screen:
 * 1) Karlos
 * 2) Rainith
 * 3) Shandy


 * Graphical User Interface (or GUI):
 * 1) Ishmaeel


 * Gameplay Interface (as opposed to Login Interface, Character Selection/Creation Interface):
 * 1) Si Tacuisses
 * 2) Wesrichards -unless this article will cover all Interfaces

Please sign your name behind the choice you like. If your choice is not listed, please add it at the bottom. --Karlos 21:40, 28 February 2006 (CST)


 * Are multiple votes allowed? I don't care much if it's plain "Interface" or if a Game(play)/Graphical/User/whatever is added as prefix. -- 23:28, 28 February 2006 (CST)
 * I concur. Vanilla interface is my favorite, but most prefixes will do. Game Screen, however, is right out (in part because it means something completely different). --Bishop 00:29, 1 March 2006 (CST)

I think we are talking about two different things here. I am talking about the game screen in which players play the game, not the "entire user interface" of the program. I think you guys need to think in a more user-friendly kind of way. With the exception of a few geeks like us, few users care to know all the different ways to interact with the program. Most would love a screen cap of the game screen however and an explanation of all the different elements on it. I do not see an all encompassing article about all the different ways to interact with the program as being a good thing. This is a geek approach.. A Functional listing of all the cool things I have put in this thing. Users though need to be told things in a way that interests them not us. There for it is best to always present interface elements to the user in the context of "here is what you need to do to achieve X"

So, an article explaining the game screen makes sense to a user. An article explaining how to set the password in the properties so as to avoid having o type it each time you log in is also useful. An article combining both in addition to how to take screenshots is, in my not so humble opinion, useless. That is what a category is for. Geeks fascinated about all elements of the UI can follow the category link and browse. But a complete reference of all UI features is NOT a good article. --Karlos 10:53, 1 March 2006 (CST)

Starting The Vote Over
Because I am the dictator of 1/3 of my brain (1/6 of my brain recently obtained democratic independence, while 1/2 of my brain has been demonically possessed for quite a while now), I am once again calling off the proposed deadline for the skill box vote.

The Votes
Voters are advised to consider how the proposals look at 800x600 resolution.

Remember this is an instant-runoff vote, so specify your second, third, 4th etc choices!


 * 
 * PanSola (backup choices: Hybrd4b > Hybrid3 > Hybrid6 > Hybrid 5)
 * Nilles (second choice: Skuld's)
 * Rainith I really don't have anything to add here, but I didn't want to feel left out of the cool kids micro-text club.
 * 
 * Xeeron
 * Barek (second choice: Hybrid 4b, Third choice: Hybrid 6) (If you can read this fine-print, your eyes are better than mine.)
 * Foo (I'll just say, I choose this one for not being too dense, while still being short enough to use multiple times in the same page, and in general, pleasing to the eye.)
 * 


 * 


 * 


 * 
 * Xeeron
 * JoDiamonds (Hybrids 6; 4b; 5; 3; Skuld's; Landscape v4)
 * Stabber (2nd: Skuld's; no third and beyond as I don't like any of the rest) (The proposal needs margin and padding tweaks so that the text does not run into the skillbox; this is a minor quibble that does not detract from general agreement with the format.)
 * Markild (2nd:Hybrid 5, 3rd:Hybrid 4b)
 * Fenris (2nd:Hybrid 5, 3rd:Hybrid 4b)
 * Gem (2nd: Hybrid 3, No: Lanscape v4) I want to change the ugly light gray used in the list to a bit nicer color. Also the black backround around the lists skill icons should be changed to white.
 * Kalomeli (2nd: Hybrid:3)

Related Voters

 * Dinosaur Planet (previous vote was landscape v4)
 * Bishop (previous vote was skuld easy)
 * Evil_Greven (previous votes were: Hybrid 6 > Hybrid5)
 * LordBiro (previous vote was Hybrid 6)
 * User:Theeth
 * User:Tetris L
 * User:TheSpectator
 * User:LordKestrel
 * User:130.58
 * User:Novalith
 * User:Cloud
 * User:Evan The Cursed
 * Karlos
 * 161.88.x.x

Voting Results
The voting time has passed, Hybrid 6 got a majority even before considering secondary-votes. Last chance to dispute before massive change takes place. -PanSola 04:11, 29 April 2006 (CDT)
 * My first choice so I am happy with this. A few minor changes only, which I alrea~dy mentioned. I want to change the ugly light gray used in the list to a bit nicer color. Also the black backround around the lists skill icons should be changed to white. Nothing which would need a new vote, I think. --Gem [[Image:Gem-icon-sm.png]] 04:19, 29 April 2006 (CDT)

Choices
1. Example:

Advantages:
 * Quicker identification of skills
 * Gives skills section some color, i.e pretty

Disadvantages:
 * Not all icons are clearly visible
 * Spaces out the skill lists

2. Example: Balthazar's Aura

Advantages:
 * Simple link
 * Already in place for the majority of the pages

Disadvantages:
 * Some players cannot identify well with just the name of a skill
 * Too plain

3. Me and my sockpuppet will vote for whoever offers me (or my sockpuppet) the best bribe

Vote
Vote for #1
 * 1) Does no harm and could do some good. Using images to promote association is good interface design. Don't think it contravenes GW:CONTENT.  &lt;LordBiro&gt;/&lt;Talk&gt; 06:00, 11 June 2006 (CDT)
 * 2) All I see are positives; the only negative to me is the time to implement to make all consistent - not a reason to avoid a design improvement. --- Barek (talk &bull; contribs) - 13:41, 11 June 2006 (CDT)
 * 3) At first I thought the icons would "weigh to heavy" in the eye, but the example looks quite nice to me. Therefore an Aye to #1. --MRA 15:23, 11 June 2006 (CDT)
 * 4) As a wise cow once said: Moo. --Karlos 17:45, 11 June 2006 (CDT)
 * 5) Hmmmm, icons, yummy! --[[Image:TurningL sml.gif|Tetris L]] 03:07, 12 June 2006 (CDT)
 * 6) I've clicked countless times on text links only to see the icon and instantly recognize the skill. So, pro-icon from me. --Chi Li [[Image:Chi_Li.gif|Chi Li]] 03:23, 12 June 2006 (CDT)
 * 7) These are a HUGE help for me as I am very bad remembering names. I recognize most skills faster from icons and so do many other people. --[[Image:Gem-icon-sm.png]] 13:05, 12 June 2006 (CDT)
 * 8) Ooooo shiny! -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 16:16, 12 June 2006 (CDT)
 * 9) I vote for it --Boozer69n 18:10, 15 June 2006 (CDT)
 * 10) Yeh &mdash; Skuld  11:35, 18 June 2006 (CDT)
 * 11) I think they're pretty, and they are frequently recognizable I find. My only concern is bandwidth, but until someone can tell me the ACTUAL effect on bandwidth, I'll support the icons. -- Lord Ehzed 08:14, 19 June 2006 (CDT)
 * 12) Unless User:Gravewit himself told me this eats bandwidth, I would not believe it. Images are cached by most web browsers, and I don't see why this would be different. (After testing, I can verify images are indeed cached client-side: [HTTP/1.1 304 Not Modified] ) &mdash; Galil  20:04, 25 June 2006 (CDT)

Vote for #2 Other
 * 1) Some players can suck it. GW:CONTENT. – 70.20  ( &#x260e; ) 2006-06-11 10:50 (UTC)
 * 2) Me don't like. --84-175 (talk) 18:04, 11 June 2006 (CDT)
 * 3) Waste of bandwidth, most icons unreadable at that size. --Rainith 19:13, 11 June 2006 (CDT)
 * 4) See my comments, here and here, above for my opinion. --Gares Redstorm 22:02, 11 June 2006 (CDT)
 * 5) Creates too much clutter with the icons looking at the example. --Xasxas256 22:03, 15 June 2006 (CDT)
 * 6) I'm here for the 10k. - 17:23, 19 June 2006 (CDT)
 * 7) I do understand that some people recognise images better, but the icons are too small and takes up bandwidth and space. Alot of consistency issues too.  23:51, 22 June 2006 (CDT)
 * 8) for all the reason said above--Aratak 20:15, 25 June 2006 (CDT)
 * 1) I vote for "yes" only if the following conditions are true:
 * 2) *It doesn't take up too much more bandwidth (Gwiki is loading slower and slower these days).
 * 3) *We come to a consensus on whether we do this to EVERYTHING (i.e. collectibles, etc). I want conformity dang it!
 * 4) *I'm not relegated to be the one updating all the pages.
 * 5) **Otherwise, I'd vote no. --Ryard 11:32, 18 June 2006 (CDT)
 * 6) (Add your vote and your reason here)

Discussion
What is the close date on this vote? It has been open over a week, but with an open ended close date, nothing can really be finalized. --- Barek (talk • contribs) - 08:36, 19 June 2006 (CDT)
 * Do we even have 6 more active people who would vote on this? I think we can end this today. --[[Image:Gem-icon-sm.png]] 08:45, 19 June 2006 (CDT)
 * Shall we vote on whether to end this early? d-: - 08:49, 19 June 2006 (CDT)

Haven't we (the beauty loving Kurzicks) defeated them (the ugliness loving Luxons) in this issue yet? --Karlos 16:07, 19 June 2006 (CDT)


 * I'll concede defeat, altho I will offer PanSola 10K for each sockpuppet he creates to vote for no icons. ;)
 * So now someone just needs to change them all.... --Rainith 16:41, 19 June 2006 (CDT)


 * "Someone"? O.o *wipes sweat from brow* I say its ended, skill icons win. --Gares Redstorm 16:57, 19 June 2006 (CDT)


 * No bots? *snif* I'll help with this, as long as we decide hoo to make it organised. --[[Image:Gem-icon-sm.png]] 17:18, 19 June 2006 (CDT)


 * Just do it like we did the bestiary thing. Make sure to do a whole "sub category" when you start (i.e. don't start on Outcasts and stop half-way through). And then mark the ones you have done here. Also, if you see another working on them, then work from the opposite side (i.e. if he's going alphabetically from A to Z then you start from Z). --Karlos 18:37, 19 June 2006 (CDT)

GuildWiki talk:Sign your comments
I have transcribed a draft from Wikipedia:Sign your posts on talk pages. Because some of the recommendations on wikipedia differ from the communities ideas. So in order to better facilitate the discussion, and to prevent confusion, I have transcribed over a majority of the article. --Draygo Korvan 14:09, 12 June 2006 (CDT)
 * The article name sounds like it's only asking me to sign User talk:PanSola... - 14:50, 12 June 2006 (CDT)
 * Well ... I copied the article, including the name (ED: which I messed up in so doing 16:28, 12 June 2006 (CDT)) from wikipedia - and cut out the section that is a bit controversial (even on wikipedia). On wikipedia it is considered a guideline, not a rule. And I dont think we will be using it to ban users here either. --Draygo Korvan 14:56, 12 June 2006 (CDT)

Move

 * 1) Please sign your comments on talk pages
 * 2) Please sign your comments
 * 3) Sign your comments on talk pages
 * 4) Sign your comments
 * 5) Please sign your talk pages (as-is)

I would go for #2, I prefer shorter article names. The user can read into the start of the article to get the whole idea. --Draygo Korvan 15:52, 12 June 2006 (CDT)
 * I agree, short and to the point. --- Barek (talk &bull; contribs) - 15:54, 12 June 2006 (CDT)
 * Two looks good to me too. (Yay, I used all three versions of the word in that sentance.)  --Rainith 16:06, 12 June 2006 (CDT)

I think 1 is the clearest because it is not immediately obvious that comments are limited to talk pages. However, I have no strong opinions here except to be against #5, which is just wrong. –70.20&#x260e; 16:14, 12 June 2006 (CDT)
 * You need to jump over to wikipedia and tell them they are wrong =P. There are exceptions to the comments limited to talk pages rule. Discussion pages (for instance) can be signed. --Draygo Korvan 16:18, 12 June 2006 (CDT)


 * WP uses Wikipedia:Sign your posts on talk pages, which I think is fine. I have no idea whythe old here linked to that oddly named article –70.20&#x260e; 16:25, 12 June 2006 (CDT)


 * Yea your right, messed up =P. --Draygo Korvan 16:27, 12 June 2006 (CDT)
 * Seems like Karlos moved the page on us siting that we shouldnt use Please because Please is assumed...--Draygo Korvan 10:16, 14 June 2006 (CDT)
 * Yeah the "Please" was bugging me quite a bit too. Glad he removed it. - 10:17, 14 June 2006 (CDT)
 * Sorta bugs me that he did it under the radar, and didnt even bother updating the unsigned template. --Draygo Korvan 10:18, 14 June 2006 (CDT)


 * Karlos was unaware there was even a discussion about it. :) I would recommend people use the move tag if they wanna indicate the page's name itself is in question. Qhen I looked at the page nothing told me there was any discussion about the name. I admittedly did not check the talk page, but I think I had no reason to do that. Anyways, the please is not right. If you guys wanna move it to "Sign your talk pages postS" or "Don't forget to sign messages you leave in talk pages of articles" then by all means. But all the other policies have short, concise titles, not verbose descriptive ones. We call it "You are Valuable" and not "Your contributions are really valuable to us." don't say in 5 words what you can say in 3. :) --Karlos 10:59, 14 June 2006 (CDT)
 * We did use the move tag, check the history of the article, it was removed when I moved the page. --Draygo Korvan 11:08, 14 June 2006 (CDT)

Additional rule discussion
I'm going to put up for discussion various issues that we should address in the guideline. Ill start with the ones that will be more agreeable, and move down to the ones that have the potential to have more debate. The first two will concern external links and byte (character) limit for sigs. --Draygo Korvan 11:08, 14 June 2006 (CDT)
 * The use of transclusions in sigs has been brought up in the past, and is used by some users currently. Should we also add a vote on if transclusions should be allowed in signature pages? --- Barek (talk &bull; contribs) - 15:29, 14 June 2006 (CDT)
 * At the moment, I wouldnt. I would prefer to get somethings out of the way that are less controversial. --Draygo Korvan 15:34, 14 June 2006 (CDT)

Propose immediate termination of all votes in this section.
We are currently lacking an argument for having these votes in the first place. What justifies this instruction creep? What grievance does it address? What benefit will adding new rules add to the day to day activities of this wiki? Until these are addressed satisfactorily, no voting should happen. &mdash; Stabber &#x270d; 09:48, 15 June 2006 (CDT)
 * We should have these instructions before someone proves us that we need them by making something awfull with their sig. A length limitation would be nice for easier editing anyway and we allready have one sig a lot shorter because of this vote. --[[Image:Gem-icon-sm.png]] 09:56, 15 June 2006 (CDT)
 * Disagree. Until we have a "signature incident", we should have no guidelines about it. Fear of the future does not justify restrictions on the present. &mdash; Stabber &#x270d; 09:58, 15 June 2006 (CDT)
 * Well, this is not important to me, but I think that atleast some sort of rules are in place. --[[Image:Gem-icon-sm.png]] 10:01, 15 June 2006 (CDT)


 * 1) Grievance it addresses is possible abuse of signatures. Including sinatures that are longer in the edit page than the actual message they are typing
 * 2) Adding the rules now would be far easier in the future. If they do not exist now it will be far more difficult in the future to push a change through if users are abusing it. And when a change gets through in the future you could have alot of legacy problems further complicating the situation. Less risk for abuse in the future, avoids people abusing personal links to increase their pagerank, avoids possible url takeovers in legacy links in signatures.
 * 3) No one should be banned for any of the rules being placed here, these should be guidelines and not hard and fast rules.

If we wait till we need them, it can be too late, we will spend days if not weeks discussing this while the potenital abuse is going on. It is better to get it out of the way now then when needed. --Draygo Korvan 10:02, 15 June 2006 (CDT)


 * There has never in the history of the GuildWiki been an actual "abuse of signatures". Therefore your fear of possible abuse is unjustified. Also a fear is not a grievance. Adding new rules is easy, but rules that are not policed are worse than rules that don't exist. And I would be adamantly opposed to policing any signature rules until we have had a major incident. I find your fearmongering about signatures downright silly, if not expressly antidemocratic. &mdash; Stabber &#x270d; 10:07, 15 June 2006 (CDT)


 * As unusual at it may seem, I am 100% behind Stabber on this one. These votes serve no useful purpose, and solve no present problem. All it does is add complication to something that should be very simple. I firmly believe in only regulating what actually needs to be regulated, not trying to pre-empt any and all possible problems that may or may not arise in the future. And if anyone thinks that, for instance, my signature is too long, please just tell me instead of beating around the bush. -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 10:08, 15 June 2006 (CDT)
 * Fine by me. But you cannot call this anti-democratic. Anti-democratic would have been me transcribing everything we linked to on wikipedia over here. I decided instead of transcribing the entire article to transcribe the parts that I know we all agree on just so we can link to our own internal article. I find that very insulting that you are accusing me of fearmongering on this issue. It was my plan while transcribing to let the guildwiki community vote on the sections that I deemed would be controversial. If you feel no vote should take place fine. But please, lay off of the personal attacks. The primary reason the votes are here is because they are from the original article I transcribed from, which we WERE linking in the signature template. --Draygo Korvan 10:22, 15 June 2006 (CDT)


 * I see. Yeah, the old unsigned template was the product of my laziness and should have never linked to Wikipedia. As regards which parts of this present article are worth keeping... dunno. Can't be arsed to think about it until someone puts a goatse in their sigs, sorry. I am sure you'll edit it down to something reasonable. &mdash; Stabber &#x270d; 10:32, 15 June 2006 (CDT)
 * I'm fine with archiving this till its actually needed. You can see why I didnt copy over wikipedia's rules right off. You would have been going off the wall if I did that. --Draygo Korvan 10:36, 15 June 2006 (CDT)


 * I believe my utter lackof participation in this discussion shows where my heart is on this issue. --Karlos 17:05, 15 June 2006 (CDT)

Proposed Rule:
Permit or disallow external links in user signatures.

Votes

 * Permit
 * Sign here to allow external links in user signatures


 * Disallow
 * Draygo Korvan Signatures should not be allowed to have any external links in them.
 * &mdash; Skuld
 * --- Barek (talk • contribs) - 17:13, 14 June 2006 (CDT)
 * --Xasxas256
 * --[[Image:Gem-icon-sm.png]]

Discussion
I just want to confirm something here, so correct me if I am wrong. External links is outside of the wiki. This seems self-evident to me, but hey, I've been wrong before. --Rainith 19:24, 14 June 2006 (CDT)
 * Yes, external links are outside the wiki. For instance if I link [www.google.com] in my sig that would be an external link. --Draygo Korvan 09:35, 15 June 2006 (CDT)

Proposed Rule:
Signatures are limited to X number of characters not including the timestamp, or the actual link to the user's page ( User name  doesn't count towards the limit, but if the piped link is modified to be longer, the extended lengh would count).

Votes

 * For
 * e^(pi), rounded up character limit
 * - 15:16, 14 June 2006 (CDT)
 * 50 character limit
 * --[[Image:Gem-icon-sm.png]] (I could accept 100 if wanted)
 * 100 character limit
 * Draygo Korvan
 * 150 character limit
 * Sign here to support
 * 200 character limit
 * --- Barek (talk • contribs) - 17:13, 14 June 2006 (CDT)
 * (fill in) character limit
 * Sign here to support
 * Against
 * Sign here to oppose

Discussion
e^(pi) ~= 23.1406926. That seems a bit low Pansola. Heck my current sig would then be in violation =p. --Draygo Korvan 15:37, 14 June 2006 (CDT)
 * Is this vote regarding displayed characters, or characters of code? Mine is already 214 characters if you're counting characters in the code, but only 27 actually displayed characters.  If I had a graphic in mine (many users do have one), it would be even longer in characters of code. --- Barek (talk &bull; contribs) - 15:45, 14 June 2006 (CDT)
 * I'm against cluttering of the edit buffer. - 15:49, 14 June 2006 (CDT)
 * It would be code. As in when i click edit it shouldnt be more than X characters long. Though you can shrink yours quite a bit by attacking those &amp;nbsp; in addition it doesnt count the actual datestamp. Yours is actually only 142 characters long--Draygo Korvan 15:51, 14 June 2006 (CDT)
 * Oops, my mistake, mine is only 142 in code. I was counting all characters in my sig file, forgetting that some of it was inside a noinclude tag. --- Barek (talk &bull; contribs) - 15:53, 14 June 2006 (CDT)
 * if you cut out your &amp;nbsp; your sig looks like this, shortening it even more:

--- Barek (talk &bull; contribs) -
 * --Draygo Korvan 15:55, 14 June 2006 (CDT)

I just modified what counts and what doesn't. For example, Draygo Korvan's sig would count as 0 characters, and Barek's after removing the nbsp's would be under 100 characters. - 15:56, 14 June 2006 (CDT)
 * Ill second that change, and move my vote to 100 chars, which I think is reasonable.--Draygo Korvan 16:01, 14 June 2006 (CDT)
 * I think that change is making it even more hoops to jump through. And twisting the rules to squeeze specific existing signatures in seems downright silly. I much prefer a nice, basic guideline of "Please do not make you signature terribly long and/or complicated." -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 16:09, 14 June 2006 (CDT)
 * I don't understand. The change gaurentees everyone, regardless of the length of their user name, to start from the same place (basically, the vanilla sig count as 0).  How is that silly or twisting things? - 16:19, 14 June 2006 (CDT)
 * That part isn't twisting anything. It is merely needlessly complicated, and it encourages those who want long, silly signatures to choose long, silly usernames, which would be of no use to anyone. -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 16:25, 14 June 2006 (CDT)
 * Hmmm, I had a reason at one time for inserting the &nbsp, but it seems to work fine without them, so I've cleaned it up. Gets it down to 114.  I'll still need to modify further to get it under 100, but should be do-able.  Still, I don't think 150 or even 200 is outrageously long myself. --- Barek (talk • contribs) - 16:59, 14 June 2006 (CDT)
 * Edit: Okay, I have it under 90 now (after subtracting out the timestamp and standard piped link to the user page), thanks for the suggestions. However, I do believe that the transclusion question should be addressed at the same time as the sig length.  Users can easilly bypass the length limits by using a short transclusion link, so the two are related to some degree.  --- Barek (talk • contribs) - 18:29, 14 June 2006 (CDT)

Mine's nice and short :p &mdash; Skuld  15:57, 14 June 2006 (CDT)
 * Anyone care to tell me how short mine is? I don't have my name in it or a link to my user page, I only have the image which is a redirect to my user page? Even if every character is counted, it is very short. :) --[[Image:Gem-icon-sm.png]] 04:27, 15 June 2006 (CDT)
 * Well here's a good test to see if the average idiot on the street can work it out :) Looking at it: --[[Image:Gem-icon-sm.png]] I'm not sure! Ok it works out to 27 characters long and --Gem would obviously be your vanilla sig. However you current sig only includes the -- and none of the rest. So do we say your sig is 27 characters long or do we say it's 25 (27-2=25, the 2 comes from the two hypens) characters long? I'd say the vanilla sig includes not just the User name and timestamp, it also includes the two hyphens ie the -- as well. So I'm going with 25 characters. Perhaps the proposed rule should be modified to also include the two hyphens. So either way it is pretty short but it's still more than e^(pi) Gem!!! You might have to change the image name :) --Xasxas256 07:49, 15 June 2006 (CDT)


 * If it would matter I would feel worngly treaten here. Someone with a longer sig counts as 0 when I count for 25 because I replaced my name with an image. :D --[[Image:Gem-icon-sm.png]] 09:11, 15 June 2006 (CDT)
 * Gem you would get 18 free characters (not including timestamp at all here). So your sig by the rules would only be (27-18) 9 characters long =). I think Pamsola's addition isnt confusing though we can type it out more plainly. Basically you are limited to x characters beyond the regular sig. --Draygo Korvan 09:33, 15 June 2006 (CDT)
 * Ah, I understand. --[[Image:Gem-icon-sm.png]] 09:57, 15 June 2006 (CDT)

Vote: Restarting the build-stub debate
Re:
 * GuildWiki talk:Community Portal/Archive 2
 * User talk:Delia Rashesh

The time is ripe to rethink the purpose behind. Do we assume that build contributors will generally add good builds (and we weed out the rare bad build), or do we assume that build contributors will generally contribute junk (and we weed in the rare good build).?

The orthodox GuildWiki opinion on this has been: (b) make every build undergo a torture test.

Several people (myself included) think, rather, that: (a) best to assume good faith.

Time for a vote and discussion. Simple majority, and expires a week from fixing the ballot.

Vote
This ballot is not yet fixed

All new builds have to be (or similar) and undergo vetting
 * 1) Xeeron
 * 2) Shandy
 * 3) (your vote here)

'''New builds are put into the non-stub build categories, but undergo stealth testing. Contributed builds that are found to be rubbish are ejected.'''
 * 1) Stabber 10:33, 5 May 2006 (CDT)
 * 2) --Delia Rashesh (talk) 10:46, 5 May 2006 (CDT)
 * 3) Gem (As long as everyone has the right to stub clearly incomplete or suspicious builds)
 * 4) &mdash; 130.58 (talk) ( 11:06, 5 May 2006 (CDT) )
 * 5) Skuld  Same as Gem
 * 6) Nilles
 * 7) (your vote here)

Discussion
Copied from User talk:Delia Rashesh

If you create a new build it needs to have added to it so it can be reviewed & brought up to standard before it is put into the appropriate category, thanks & welcome! Skuld  08:59, 5 May 2006 (CDT)
 * Even though it's not a stub... and in the right category... --Delia Rashesh (talk) 09:01, 5 May 2006 (CDT)
 * On GWiki, we like to get the community to decide when a build is suitable for being a full build listed in the builds category. This ensures that junk builds do not crowd the good builds out. This is just a standard procedure and is no comment on the quality of your article of the quality or the content of your article. Shandy 09:02, 5 May 2006 (CDT)
 * Build-stub is a bit of a misnomer, build review would be better Skuld  09:06, 5 May 2006 (CDT)


 * Too much of that line of thought and you won't have a wiki anymore. Honestly, procedures do not bother me, it's when an article is assumed junk before proven good.  I'm from the AGF camp.  While I can see builds being a particular problem, as everyone submits their favorite crappy build, the "five-vote minimum" that has been imposed is short-sighted and stupid.  If people were encouraged to tag specific builds they think aren't up to par, I think the cleanup would go considerably faster and result in fewer deletions, while still keeping only the good ones.  --Delia Rashesh (talk) 09:08, 5 May 2006 (CDT)


 * Ah, you've come at a time of overhaul for the build-stub category. It was growing too big, so Xeeron has instigated a massive purge of the category to eliminate the ones who will never make it to the correct non-stub category. Usually it works on a "If two people think it works, and the article has standard formatting, then the build gets unstubbed" basis. Shandy 09:12, 5 May 2006 (CDT)
 * Incidentally I'm one of the more 'progressive' users of GWiki here, and even I see the value of the build-stub category and peer review. Shandy 09:14, 5 May 2006 (CDT)


 * Can we peer-review without making good-intending build authors feel like they're being placed under a microscope naked? --Delia Rashesh (talk) 09:18, 5 May 2006 (CDT)
 * Sorry! That certainly isn't the intention. That's one of the problems with Wikis - people are always misconstruing intentions, and it leads to people forgetting to assume good faith. Shandy 09:31, 5 May 2006 (CDT)
 * I know it's not the intention. I am assuming good faith.  But it doesn't make this process, however misguided, any more pleasant for constributors.  As I said, what is wrong with tagging crappy builds when they're seen? --Delia Rashesh (talk) 09:34, 5 May 2006 (CDT)
 * I think, in the end, having a positive or a negative method for controlling the builds category doesn't make much difference, as long as we have a standard procedure to follow. I think our current method will produce less articles but of higher quality, whereas the proposed method will make it easier for articles to get through leading to a more encyclopedic account of builds in GW. Shandy 09:47, 5 May 2006 (CDT)


 * You can always initiate a vote for changing this. I personally think that your method is better. A new contributor can't know that he is required to mark the build as a stub and the poor builds can easily be marked as stubs by others. --Gem [[Image:Gem-icon-sm.png]] 09:13, 5 May 2006 (CDT)


 * Having come from Wikipedia, I would strongly recommend many of their policies and guidelines, especially when it comes to the deletion of articles. A wide sweep of deletes will do more harm than good.  Tag things that look crappy, delete if nobody defends.  --Delia Rashesh (talk) 09:16, 5 May 2006 (CDT)


 * Then let's purge the stubs, and leave the non-stubs alone. --Delia Rashesh (talk) 09:16, 5 May 2006 (CDT)


 * By the way, I agree with you. Build-stub was and is a terrible idea. I've tried to argue against it, but to no avail. Once this wrongheaded policy was set in place (before my time), people seemed reluctant to consider any other options. &mdash; Stabber &#x270d; 09:41, 5 May 2006 (CDT)
 * If this policy is maintained, it will dramatically affect whether or not I decide to publish any other builds. If this site doesn't want them, why should I waste my time writing them up?  --Delia Rashesh (talk) 09:44, 5 May 2006 (CDT)
 * Please, don't feel obliged to post your builds. GWiki is a purely voluntary project and I don't see why anyone should do anything that they don't want to do. Shandy 09:47, 5 May 2006 (CDT)
 * No, I wanted to post my build to help others. But if this is the sort of welcome new contributors get, I think I have better places I could be exerting creative effort.  --Delia Rashesh (talk) 09:49, 5 May 2006 (CDT)
 * New contributors are the lifeblood of any wiki. I personally have nothing against you, your build or your proposal. I'm not sure what kind of welcome you perceive you have received, but please don't leave out of frustration or anger already! Try to change the system, if you sincerely think it needs changing, by making a vote and talking to Xeeron (who has taken it upon himself to try to maintain the Builds section). If you notice above I already added my thoughts about your proposed method of peer review. By the way, GWiki isn't Wikipedia, but some things obviously carry across easily between the two. Shandy 09:55, 5 May 2006 (CDT)
 * Oh, I'm not going to leave completely, just stop posting builds, and generally stop editing builds at all. --Delia Rashesh (talk) 10:01, 5 May 2006 (CDT)
 * Fair enough. I'm still not sure why, though. You object to your builds being scrutinised or do you object to the way we try to ensure build quality? Shandy 10:05, 5 May 2006 (CDT)
 * I object to the way it's being done -- it's very un-wiki-like. Particularly in regards to the build I added, if anyone has a specific point they would like addressed, I have no quarrel.  But I object to this "hey, someone needs to make sure this build isn't BS" BS. --Delia Rashesh (talk) 10:08, 5 May 2006 (CDT)

OK. I think the rationale is that the current way the process of deciding which builds are good is transparent and highly community involved. Are you going to raise this point in a vote? It's quite a major issue so I don't think anyone would disagree with a vote on this change of policy idea. Shandy 10:11, 5 May 2006 (CDT)
 * If I knew where to raise the point, I would. --Delia Rashesh (talk) 10:12, 5 May 2006 (CDT)


 * I've taken the liberty of putting out a call for votes. &mdash; Stabber &#x270d; 10:35, 5 May 2006 (CDT)
 * Thanks, I've cast my vote. --Delia Rashesh (talk) 10:47, 5 May 2006 (CDT)

END copy

The fact that the build stub category was so big clearly indicates that the old system didn't work very well. If we want to keep the spirit of it, I wouldn't mind a "featured builds" thing, like Wikipedia's "Featured Articles", to highlight particularly excellent and well-written builds (just a few). But I definitely would rather see new articles get made and then removed if they're bad than have pages sit in limbo for months until someone actually bothers to wander through the stubs. We definitely need to change the process to make it more transparent (unless you're a regular contributor, you have no idea how the build-stub thing works: this is why someone then has to go and tag newly-added content with "stub"; the current process definitely seems to have a rep as annoying and unfriendly). &mdash; 130.58 (talk) ( 11:06, 5 May 2006 (CDT) )
 * New users do not know that builds should be marked as a stub and someone else must do it. Only a few people vote for builds to be unstubbed, so many good builds lay dormant in the stub list. --Gem [[Image:Gem-icon-sm.png]] 11:41, 5 May 2006 (CDT)

Ok since I am the first to vote for the old category structure, I'll need to write a good bit explaining why I do. But first let me clarify two points: That the category is called "build 'stubs" is purely coincidal. Since I dont care at all how it is named, I never bothered to change it. If you object to the name part "stub", go ahead and change it to "build under review" or whatever you like better. Second, there is no "five votes minimum rule". That is purely a temporary drive to slim down the build stubs category.

Now, where does the old system come from and why do I feel that it is appropriate: The system evolved because at first the wiki community was very opposed to having builds at all. Why was that? They had a very good point that is still valid: Unlike almost all other wiki articles, builds can not be proven to be objectively "wrong" or "right". That means they always contain opinions, which is something that wikis in general and also guildwiki try to shun. It is much simpler to maintain a good quality of articles if the truth can be proven (or the wrong part exposed). However some (including me) thought that builds are to big a part of guildwars to completely shut out of guildwiki. Therefore we constructed the builds stub procedure to ensure that (despite it being much harder to maintain the quality of the articles there), the build articles are up to guildwiki standards as well. You might disregards all this as historical blahish that should not matter here, so I will list some reasons that have nothing to do with the historical coming to be of the category: PS: Notice that I changed the voting topic to a more acurate description, since the build stubs process does NOT imply assuming new builds are bad. --Xeeron 12:40, 5 May 2006 (CDT)
 * Guildwiki is not a place to simply communicate (builds) with other players. That is what the numberous webforums are for. It is a place where GW players should be able to find relevant information about GW.
 * "Stealth testing" will not work. Why? Because even now people are much faster at contributing (their own) new builds then they are at testing others peoples builds. There is not nearly enough testing going on.
 * The term "Assume good faith" is missleading and irrelevant for the discussion. Noone ever said we dont assume good faith in new authors contributions. However wikipedia does not ask you to "assume correctness" which is what your proposal amounts to.
 * The fact that new authors dont now about the need to put in not a bother as well. If someone puts up a new article in the normal build category without any formating, it usually takes less than 1 day before the article is tagged, formated and maybe even discussed. Authors dont need to know this, because others will know it for them.
 * And last but not least, my main argument for the review process: Doing away with it would lead to many potentially good builds being deleted! The current review process leaves even bad articles up for a long time, giving others the change to correct them and make a better build. When every article gets put into the proper build they will be deleted much faster, leading to badly implemented ideas (that might be good as an idea in itself) being deleted from the wiki.


 * I do see your point about being unable to prove correctness in builds, but I think when most people look at a build they expect it to be subjective and possibly incorrect. If that is the case we could simply add some sort of disclaimer to the top of each build.  But I think even that is stretching it.  I would not object to a similar filtering process that we seem to have now, but the wording certainly needs to be changed.  Instead of "This build-related article is undergoing peer-review," which implies that something specific on the build seems questionable, how about something that describes what is really happening, like "This build has not yet been tested."  The former makes me feel like someone is picking the build apart looking for holes, while the latter would make me feel like someone is excited to try out this new build and see if it works.  But we really need to throw out the "ten days" and "five votes" or whatever.  IMO there should not be any certain time that the votes are tallied, just check every so often and if there are a substantial number of keeps over deletes, or vice-versa, take action.  Otherwise we could lose some nice builds out of negligence.  --Delia Rashesh (talk) 14:00, 5 May 2006 (CDT)


 * Also, it would make more sense to have an "Untested builds" category. Also, why can builds not be in any other category while they are stubs/untested?  --Delia Rashesh (talk) 14:17, 5 May 2006 (CDT)


 * I want to add, that build which are contributed have often undergone testing already. It would be far more effective, to put new builds into the PvP (resp. PvE) category right from the start and just add them to a new group asking players to test this build. If no test needed, why bother? Builds who don't have a notice which tells they have been tested already, lack a serious advantages/disadvantage discussion or simply don't look like they could work could easily be added to the "untested" category afterwards by reviewers. # Nilles 14:35, 5 May 2006 (CDT)


 * Ok, seriously, where has the wiki spirit gone to? I have seen tons of people come, say that build stubs is a missname. I told every one of them: "I dont care about the name" (noone else does either) "go ahead and change it if it bothers you". And time after time what happens? Nothing. Now *I* did go ahead myself and changed it, not because I care in the least whether it is named build stubs or untested builds, but simply because I am tired of hearing all the same talk over and over again and seeing noone raise as much as a finger in actually doing something.


 * "IMO there should not be any certain time that the votes are tallied, just check every so often and if there are a substantial number of keeps over deletes, or vice-versa, take action."
 * This was exactly what was done for half a year till about 5 days ago, with the result that noone bothered voting on builds. --Xeeron 12:38, 6 May 2006 (CDT)


 * The wiki spirit was killed long ago. We are dancing on its grave to the sweetly lulling tunes of bureaucracy. Forcing, whatever you call it now, on new contributions is a poster child for this instruction creep. The only serious justification for it that you have provided is that you desire to see build articles have a certain standard of quality. However, there are other ways to achieve that, and if builds languish in eternity for of a lack of testers, then that is a good indication that no one cares about that build, and, more subtly, that build articles are just unmaintainable cruft in general. I would greatly prefer a standard banner on all build articles stating  "this is a build, i.e., a bunch of opinions someone or the other holds about how to play this game; do not take it seriously" or similar, and let the reader judge the quality for himself. &mdash; Stabber &#x270d; 13:10, 6 May 2006 (CDT)


 * ::throws hands up in the air:: Yes, there I am maliciously changing build stubs to my prefered name untested builds for no other reason than to obfuscate the burocracy, when everyone else wanted it to stay obvious. And why care about a standard of quality in a wiki, such second rate goals should definitly come somewhere way after making sure even the last contributer is free to write whatever wanted without being bothered. And while we are at it, lets not have build articles, because they are unmaintainable cruft, while we keep them all with some "dont take this article seriously" sticker on them at the same time. Of course there are much better solutions which are so obvious that they need not even be explicitly mentioned because we all know about them anyway and ignore them out of pure evilness and all bad articles are my fault, since I didnt assume that the build had enough good faith in it... --Xeeron 18:38, 6 May 2006 (CDT)


 * I just gave you the much better solution: slap on a standard disclaimer and give up. It is the only way that is scalable. Builds are opinion, and opinions are not maintainable. &mdash; Stabber &#x270d; 18:44, 6 May 2006 (CDT)

Here is what I propose doing right now while waiting for this vote to clear. To at least make the current system more obvious and user-friendly:
 * Move Template:build-stub to something like Template:untested-build. (I note the wording has already been changed, this is good.)
 * Change Template:build-stub to contain a stub message instead of the untested message.

If there are no objections I will do this. It should work well however the vote falls. Note that the "build stubs" would be in a different category after this change. --Delia Rashesh (talk) 13:39, 6 May 2006 (CDT)


 * Seems reasonable. --Xeeron 18:38, 6 May 2006 (CDT)


 * Ok, I've started. I'll be changing each build with  to  (or adding the latter if it is indeed a stub), so there will be a lot of noise on the build pages for a couple minutes.  I'll change Template:build-stub away from a redirect back to a stub message after I'm done, and will post here as well.  --Delia Rashesh (talk) 18:49, 6 May 2006 (CDT)


 * I've finished, and also removed the tag on Category:Build stubs since it does something different now. --Delia Rashesh (talk) 19:14, 6 May 2006 (CDT)


 * Fixed a few of the left over builds. Just a quick question to make sure we are on the same level, do we want ALL build to be in BOTH (untested or tested) and (PvE or PvP), making the build category a dual tree? If yes, many builds need to be put into PvE or PvP that are currently not. If no, the tested builds category is redundant (if it is not untested, it is automatically tested) and should go. --Xeeron 03:56, 7 May 2006 (CDT)


 * Imho, builds should still be in PvE and PvP categories which eases finding an appropriate build. The current approach in marking both tested and untested builds is good and should be kept as is. --Nilles 13:17, 7 May 2006 (CDT)


 * But you need a way to look for the untested builds to test them. Likewise, players may want a list of only tested builds so they don't waste their time.  Both untested and tested categories serve a purpose.  --Delia Rashesh (talk) 16:07, 7 May 2006 (CDT)