GuildWiki has been locked down: anonymous editing and account creation are disabled. Current registered users are unaffected. Leave any comments on the Community Portal.




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[]

  • Vote on putting the profession in build names, from User_talk:Xeeron. Result: Yes.

1.) Profession in title: Xeeron, Kiiron, betaman, Kidburla, Shandy

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.

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.

Suffix for Chapter 2[]

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.

  • Only Guilds that meet some criteria of notability (to be determined): JoDiamonds
  • Only Following strict rules (see below): Tetris L, Karlos, MRA, — Skuld, PanSola, JoDiamonds, Ravious(yes to GWWC, no to GotW)

(explain other in discussion)

  • 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": — Skuld 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 in between. 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 — Skuld 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 and 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. Tetris L (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:
    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? — Stabber 19:36, 14 March 2006 (CST)

Heck, let's put this to a vote.


Get rid of this category?


  1. Stabber
  2. (your vote here)


  1. El Karlos
  2. Pan Sola
  3. Tetris L
  4. User:Gem/Sig
  5. Xeeron
  6. Barek
  7. Acadia
  8. skuld
  9. DragonWR12LB 19:11, 30 March 2006 (CST)
  10. (your vote here)

Style of differenciation between Prophecies, Factions and Core[]

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. Tetris L (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[]

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)

Pro Con Summary[]

Category Original PNG Original, JPG Screencaps New Fansite Kit
Image Size 128x128 128x128 Variable 64x64
File Size 20+ kb ? Variable 3 kb
Missing: Elites, Res Signet, Sig of Capture,
some non-elites icons are outdated
Ch2 Skills
Potentially None Res Signet, Sig of Capture, Ch2 skills (for now at least)
Elite Gold Border N/A (no elite skills) Yes No, but can be compensated by template
Discolor when scaled down Sometimes (Image talk:Tiger's Fury.png) No Depends on filetype No

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
  2. Tetris L
  • 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.
    • 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 GuildWiki: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. Foo
  3. Barek
  4. Xeeron (this only differs from 3 in leave some links here, which I prefer)
  5. JoDiamonds
  • Move everything
  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:

  • 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

Please tell me, which words shall be lower case, which shall be upper case?

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. Tetris L
  2. Rainith
  3. Xeeron (but have redirects, see below)
  4. 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

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. --Tetris L 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)

Vote on Skill Box template structure/layout[]

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!

  • #Landscape v4
    1. PanSola (backup choices: Hybrd4b > Hybrid3 > Hybrid6 > Hybrid 5)
    2. Nilles (second choice: Skuld's)
    3. 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.
  • #Skuld's easy syntax
    1. Xeeron
    2. Barek (second choice: Hybrid 4b, Third choice: Hybrid 6)(If you can read this fine-print, your eyes are better than mine.)
    3. 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.)
  • #Hybrid 3
  • #Hybrid 6
    1. Xeeron
    2. JoDiamonds (Hybrids 6; 4b; 5; 3; Skuld's; Landscape v4)
    3. 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.)
    4. Markild (2nd:Hybrid 5, 3rd:Hybrid 4b)
    5. Fenris (2nd:Hybrid 5, 3rd:Hybrid 4b)
    6. 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.
    7. Kalomeli (2nd: Hybrid:3)

Related Voters[]

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 Gem-icon-sm.png 04:19, 29 April 2006 (CDT)

Vote on Skill Icons[]


1. Example: Balthazar's Aura Balthazar's Aura


  • Quicker identification of skills
  • Gives skills section some color, i.e pretty


  • Not all icons are clearly visible
  • Spaces out the skill lists

2. Example: Balthazar's Aura


  • Simple link
  • Already in place for the majority of the pages


  • 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 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. <LordBiro>/<Talk> 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 • 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! --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 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. --Gem-icon-sm.png 13:05, 12 June 2006 (CDT)
  8. Ooooo shiny! -- 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 — Skuld Monk 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]) — Galil Ranger 20:04, 25 June 2006 (CDT)

Vote for #2

  1. Some players can suck it. GW:CONTENT. –70.20 () 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. -User:PanSola (talk to the Follower of Lyssa.png) 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. A lot of consistency issues too. --Ab.Er.Rant User Aberrant80 Sig.png (msg Aberrant80) 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:
    • It doesn't take up too much more bandwidth (Gwiki is loading slower and slower these days).
    • We come to a consensus on whether we do this to EVERYTHING (i.e. collectibles, etc). I want conformity dang it!
    • I'm not relegated to be the one updating all the pages.
      • Otherwise, I'd vote no. --Ryard 11:32, 18 June 2006 (CDT)
  2. (Add your vote and your reason here)


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 (talkcontribs) - 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. --Gem-icon-sm.png 08:45, 19 June 2006 (CDT)
Shall we vote on whether to end this early? d-: -User:PanSola (talk to the Follower of Lyssa.png) 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. --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... -User:PanSola (talk to the Follower of Lyssa.png) 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)


  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 • 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 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 {{unsigned}} here linked to that oddly named article –70.20 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. -User:PanSola (talk to the Follower of Lyssa.png) 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 • 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. — Stabber  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 already have one sig a lot shorter because of this vote. --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. — Stabber  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. --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 a lot 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. — Stabber  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. -- 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. — Stabber  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)

External Links[]

Proposed Rule:[]

Permit or disallow external links in user signatures.

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

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 [] in my sig that would be an external link. --Draygo Korvan 09:35, 15 June 2006 (CDT)

Character Limit[]

Proposed Rule:[]

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

  • For
    1. e^(pi), rounded up character limit
    2. 50 character limit
      • --Gem-icon-sm.png (I could accept 100 if wanted)
    3. 100 character limit
    4. 150 character limit
      • Sign here to support
    5. 200 character limit
    6. (fill in) character limit
      • Sign here to support
  • Against
    • Sign here to oppose

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 • contribs) - 15:45, 14 June 2006 (CDT)
I'm against cluttering of the edit buffer. -User:PanSola (talk to the Follower of Lyssa.png) 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 &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 • contribs) - 15:53, 14 June 2006 (CDT)
if you cut out your &nbsp; your sig looks like this, shortening it even more:

--- Barek (talkcontribs) -

--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. -User:PanSola (talk to the Follower of Lyssa.png) 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." -- 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? -User:PanSola (talk to the Follower of Lyssa.png) 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. -- 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 (talkcontribs) - 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 (talkcontribs) - 18:29, 14 June 2006 (CDT)

Mine's nice and short :p — Skuld Monk 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. :) --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 --[[User:Gem|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:User name|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 --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. --Gem-icon-sm.png 09:57, 15 June 2006 (CDT)

Vote: Restarting the build-stub debate[]


The time is ripe to rethink the purpose behind {{build-stub}}. 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.


This ballot is not yet fixed

All new builds have to be {{build-stub}} (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. 130.58 (talk) (11:06, 5 May 2006 (CDT))
  5. Skuld Monk Same as Gem
  6. Nilles
  7. (your vote here)


Copied from User talk:Delia Rashesh

If you create a new build it needs to have {{build-stub}} added to it so it can be reviewed & brought up to standard before it is put into the appropriate category, thanks & welcome! Skuld Monk 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 Monk 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 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. — Stabber  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. — Stabber  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). — 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 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:

  • 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 {{Build stubs}} 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.

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)

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 {{build-stub}}, 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. — Stabber  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. — Stabber  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 {{build-stub}} to {{untested-build}} (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 {{delete}} 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)

Green green items wikilinks[]

Result: Unique items documented using regular wikilinks


  • Keep the green links
    1. --LordKestrel 20:11, 20 June 2006 (CDT) I guess I'm alone in liking the Green Links, it really makes them standout, which IMO is a good thing. Icons aren't so great.
  • Use the icon
    1. I'm a known icon-fan(atic). Second choice is plain text. No colored text please. --Tetris L 09:58, 19 June 2006 (CDT)
    2. Since I made the icon it seems wrong to vote for plaintext :P but I really don't mind either. <LordBiro>/<Talk> 14:15, 29 June 2006 (CDT)
    3. (your vote here)
  • Use plain text
    1. --Gem-icon-sm.png Green links as second choice. No for icon.
    2. --MRA (while I would rather like to see the icon than the technicolor-links)
    3. --Nilles 16:47, 18 June 2006 (CDT) (second choice: icon)
    4. -- 16:50, 18 June 2006 (CDT)
    5. --Honorable Sarah Honorable Icon.gif 20:42, 18 June 2006 (CDT)
    6. --Rapta 22:07, 18 June 2006 (CDT)
    7. I'd be okay with icons, too... overriding the text color is just a bad UI idea, however. — 130.58 (talk) (22:23, 18 June 2006 (CDT))
    8. --Rainith 23:55, 18 June 2006 (CDT) Green links as second choice. No for icon. (I'm not copying your user page Gem, just your vote.) (Biro, while I like your icon, I dislike the addition of said icons to that area of the bestiary pages.)
    9. --Xasxas256 07:44, 19 June 2006 (CDT) no icon, no green text, just good old wikification.
    10. --Lord Ehzed 07:54, 19 June 2006 (CDT) (but would also be happy with the icon)
    11. --Draygo Korvan 10:50, 19 June 2006 (CDT) (Plain text is fine and dandy. Perhaps under a subheading (like: Unique Items) under items dropped)
    12. --Gares Redstorm 11:53, 19 June 2006 (CDT) (Anything, but the icon. No offense to Biro, but I'm not much for icons.)
    13. --- Barek (talkcontribs) - 20:36, 20 June 2006 (CDT)

In case green links wins:

  • Bold
    1. (your vote here)
  • Normal
    1. --Gem-icon-sm.png
    2. --Nilles 16:47, 18 June 2006 (CDT)
    3. --Honorable Sarah Honorable Icon.gif 20:42, 18 June 2006 (CDT)
    4. --Rapta 22:07, 18 June 2006 (CDT)
    5. --Rainith 23:55, 18 June 2006 (CDT)
    6. --Lord Ehzed 07:54, 19 June 2006 (CDT)
    7. --Tetris L 09:58, 19 June 2006 (CDT)
    8. --Karlos 16:16, 19 June 2006 (CDT): Making things pretty in a simple way is something we should always do.
    9. --Galil Ranger 16:22, 20 June 2006 (CDT)
    10. --LordKestrel 20:11, 20 June 2006 (CDT)
    11. --- Barek (talkcontribs) - 20:36, 20 June 2006 (CDT)


I'm not sure if or where this has been discussed before, but I recently encountered several wikilinks leading to unique items in boldface typeset and green characters, see Rotscale or Gargash Thornbeard for instance.

From a design persepective, I am not very happy about this idea, since (beside the fact that boldface rarely is a good design decision) it weighs to heavy in the eye, distracts the reader from the text and makes the page too colorful by a color that does not belong to GuildWikis usual color palette. Moreover, since the color of wikilinks used to be connected to some functionality aspects of the site (like 'red' impliyng the article doesn't exist) I find this somewhat confusing. I really believe mere being an unique item doesn't qualify for an own link color. What comes next? Each boss getting a link in the color of their profession, like #FFF or #FFF?

If there has already been a community decision/vote upon this matter please give me a hint where to find the discussion and please excuse for bringing up the matter again. --MRA 08:44, 17 June 2006 (CDT)

I agree. I hate the green links. <LordBiro>/<Talk> 09:12, 17 June 2006 (CDT)
I like them and have nothing against them. --Gem-icon-sm.png 11:50, 17 June 2006 (CDT)
Use your own CSS to override them. See User:Deldda Kcarc/monobook.css for how I do it, because I hate technicolor links also. Deldda Kcarc 12:17, 17 June 2006 (CDT)
Thanks for the hint, but my comment was less about how I can avoid these links and rather about how this wiki presents itself to the casual reader per se. --MRA 12:33, 17 June 2006 (CDT)
Yeah, I'm fully aware I could remove them. That's besides the point really. I think it makes sense from a usability perspective to have links blue and underlined, and to have links to blank pages red, and no other colours. <LordBiro>/<Talk> 13:28, 17 June 2006 (CDT)
While I am not arguing in favor of the green links, I would like to point out that they do have blue underlines for created articles, and red underlines for missing articles. --Rainith 13:41, 17 June 2006 (CDT)
No harm, some benefit, echoes ANet's growing obsession with green items. I am fine with them. If the template is straight forward, and the effect is desirable, then why not? --Karlos 15:55, 17 June 2006 (CDT)
Like Rainith pointed out they do show red or blue underlines, and how many green item templates are to red links anyway? I'm sure users find it helpful to have uniques picked out different from regular items — Skuld Monk 16:13, 17 June 2006 (CDT)
I understood your point perfectly, MRA and LordBiro. My suggestion was a short circuit to the only workable solution because I expected the strong showing of support for the green links, as seen above. If this were to be put to a vote, our side would lose soundly. Deldda Kcarc 17:37, 17 June 2006 (CDT)
I don't agree that it does no harm. Personally I believe that valid links should be blue, underlined, not bold. It's what people expect to see. If links don't look like this as standard then it's confusing. We could change all links to a different style, but having some links using one style and some links using another style is a bad design choice.
Because the green colour is unusual within the GuildWiki itself you have to move your mouse over the text to clarify if it's a link or not. That is really poor interface design.
I don't think this is a case of "no harm, some benefit". There are plenty of items ArenaNet colour purple or light blue, we don't change our links to reflect that. Equally Henchmen are coloured green and friendly NPCs are coloured yellow-green and we don't use those colours for links. Enemies are coloured red, and we don't use red for links. It just seems like a bad idea to me.
I wouldn't even mind if an icon was used next to links to unique items, at least then the link itself would still be blue! <LordBiro>/<Talk> 18:29, 17 June 2006 (CDT)
P.S. Sorry if it feels like I'm picking on you today Karlos, I love you really :P
I would say get rid of the boldface but go ahead and leave it green. --Draygo Korvan 18:49, 17 June 2006 (CDT)
I think removing the boldface might be a good idea, but I still want the green to stay. --Gem-icon-sm.png 19:03, 17 June 2006 (CDT)
I am fine with removing it, fine with removing the bold and fine even with switching the template to an icon of a green weapon next to a regular blue link. I just think distinguishing the drops is cool and does no harm. --Karlos 19:11, 17 June 2006 (CDT)
The boldface is kinda blatant, but distinguishing green drops from normals is not a bad thing, don't you think? I think LordBiro has made a very good suggestion there. An icon to point them out would be less confusing than the formatting. --Nilles 19:42, 17 June 2006 (CDT)

Oh god no! Not more icons, keep the green text, unbold it if you want. --Rainith 20:13, 17 June 2006 (CDT)

Hope you like it Rainith ;) Green item.pngVicto's Battle Axe <LordBiro>/<Talk> 07:31, 18 June 2006 (CDT)
I see the green template as straight to the point what the items are. In Guild Wars their text is always green and I would think users associate that color to those items. As for icons, I am in agreement with Rainith on this one, for the love of Pete, no. You have skill icons, what more do you need? :P --Gares Redstorm 07:42, 18 June 2006 (CDT)

Most of all, I don't understand why unique items should be so special to Guild Wars that they deserve a special representation on the technical layer of this wiki (the color of the hyperlinks). Of course, unique items are special compared to common items, but no more special than Boss mobs are special to common mobs, Elite Skills are special to common Skills or Elite Missions are special to usual storyline Missions, etc. Are we going to give all these special topics some special representation on the technical layer, or why are unique items so special special? (Ok, I'll stop using the word special now.)

BTW, LordBiro, the icon looks really nice, but I don't understand what is wrong with a simple listing like:

Items dropped

as we have:

Skills used

--MRA 15:02, 18 June 2006 (CDT)

I have to say MRA you are right, I hadn't thought of it like that. I just tend to like icons :P but you make a valid point. If a lot of people would rather have icons then fair enough, at the moment I'm somewhere in between icons and plain text. But still 100% against bold and/or green links. <LordBiro>/<Talk> 15:10, 18 June 2006 (CDT)
I also have to admit that I would prefer some lean icon like the one you proposed over the green text links. Taking server load into account, I just think some plain text comments like given in the example above would be wiser.
So what is going to happen about this issue? I also notice some strong support for the green links within the community. Is there going to be some vote or is it still too early for such a thing? --MRA 15:31, 18 June 2006 (CDT)
Vote sounds like the way to go, since strong support was voiced for each option. I'll add one at the top. --Xeeron 15:41, 18 June 2006 (CDT)

as super pretty as that icon is, i think it's not required. --Honorable Sarah Honorable Icon.gif 20:44, 18 June 2006 (CDT)

End of Vote?[]

So, it has been about a week with no new vote having been cast. When do we call this vote closed? And can I assume we decided against the green links, so I can start removing the templates? Yet, I'm kind of confused since far more people argued pro-green-links in the discussion than voted for it. --MRA 12:23, 27 June 2006 (CDT)

(Hmm ... seems like talking to myself? ;) So, I'll start removing the green tags within the next days. Please stop me in time if you disagree. --MRA 13:30, 29 June 2006 (CDT)
For now just change the green template to make the links normal, dont go editing the actual pages and removing the template =). --Draygo Korvan (Yap) 13:36, 29 June 2006 (CDT)

Redirect usage[]

  • Increase redirect usage (allow below types of redirects)
    1. Alekti 17:23, 25 July 2006 (CDT)
    2. --Vindexus 06:57, 24 July 2006 (CDT)
    3. (your vote here)
  • No change to redirect usage (disallow below types of redirects)
    1. Skuld Monk
    2. --Rainith 15:24, 19 June 2006 (CDT)
    3. Greven 15:35, 19 June 2006 (CDT)
    4. Xasxas256 22:15, 10 July 2006 (CDT)
    5. - Barek (talkcontribs) - 22:37, 10 July 2006 (CDT)
    6. User:ST47(talk) 17:26, 25 July 2006 (CDT)
    7. (your vote here)
  • Abstain
    1. (your vote here)


I would like to (re?)open discussion on where redirects should be used on the site. In particular, I am for significantly increasing the usage of redirects to cover the following:

  • Synonyms (Hall of heroes -> The Hall of Heroes)
  • Plurals (Weapons -> Weapon)
  • Mixed-capitalization workaround (Amulet of the mists -> Amulet of the Mists)
Note: The MediaWiki behavior for case-sensitivty makes it so titles with mixed caps are case-sensitive when using the "Go" box. Having one (1) of the above type of redirect, from the all-lowercase version, works around that limitation. It is not necessary to construct every possible capitalization variant. Nor do titles without mixed caps need a redirect of this type.

My arguments for this change are:

  • Redirects help users get to their destinations faster
  • Redirects reduce server load by lowering the number of search queries
  • Redirects themselves take essentially zero server resources, in space or time
  • Redirects are "self-justifying" -- the only time a user will see a redirect is if they type that form of the term. Thus, a redirect is only seen by those users for which it is useful, and harmless to everyone else.

For reference; Wikipedia uses a very wide variety of redirects, for mainly the above reasons.

-- 15:18, 19 June 2006 (CDT)

In our case, I believe our policy is:
  • Acronyms: GvG --> Guild versus Guild
  • Synonyms: leaver --> quitter
  • Very common misnomers: Silver Armor --> Sliver Armor (this might even be disputed)
  • Common name to official name: Amnoon Oasis --> The Amnoon Oasis
  • Different capitalizations of Acronyms: gvg --> Guild Versus Guild
We do not by policy redirect plurals to singluars. That's unnecessary as you can link with the "s" outisde most of the time and searching for the plural is uncommon and will lead you to the single article most likely. On the flip side, maintaining a plural redirect for every single noun in this wiki is ridiculous.
Did I get everything? --Karlos 16:42, 19 June 2006 (CDT)
Maybe I was unclear; I was not suggesting that anyone go through and add all possible instances of these redirects; only that if someone wanted to add a particular instance of one of them, they should be allowed. At the moment, they seem to be deleted without discussion. I have added notes to the vote categories to clarify.
Also, note that plural/singular redirects are already used for a number of articles, including among others: Weapon to Weapons; Henchman to Henchmen; Runes to Rune; Command to Commands; Weapon upgrades to Weapon upgrade. These redirects seem to be useful, so I don't see the point of having a policy against them.
Lastly; it seems odd to allow acronym caps correction (gvg) but not other caps correction (amulet of the mists).
-- 20:13, 19 June 2006 (CDT)
Heh, most (if not all) if these plural->singular redirects are actually moved pages. --Karlos 02:51, 20 June 2006 (CDT)
I would vote here, but I think what I really want to say is this:
I don't think it should be GuildWiki policy to add redirects for plurals or obvious mistakes, but equally I don't think it should be our policy to remove them unless they are incorrect.<LordBiro>/<Talk> 01:39, 27 June 2006 (CDT)
I agree that more redirects would be good for the listed reasons. --Vindexus 06:57, 24 July 2006 (CDT)
If a relevent/sensible search comes up with the article then I don't see why a redirect is useful. --Xasxas256 07:01, 24 July 2006 (CDT)
I'm ambivalent about the kind of redirects mentioned above (plurals, mixed cases, synonyms), but for "PvP shorthand" names like "boon prot" or "SB/infuse" I'd rather see a page with a short explanation and links to builds that would qualify as such a build than a redirect to one build. -- 07:27, 24 July 2006 (CDT)

Vote Status[]

This vote has been open for over a month. I believe that's more than long enough, it's time to close the vote. --- Barek (talkcontribs) - 17:31, 25 July 2006 (CDT)

It's a real problem when a vote is called but no closing date is specified. The latest round of discussion and voting seems to have finished, 1 month is long enough, I agree should be closed. Unless someone objects I'll try to remember to come back and close this within the next hour or two. --Xasxas256 19:17, 25 July 2006 (CDT)

Usage of term "bound spirits"[]

  • Vote on Usage of term "bound spirits", from Category talk:Bound spirits.

I think all relevant ingame evidence for the discussion above has been presented and reviewed. Unless anybody finds some new evidence, we're stuck and will be turning incircles forever, as usual in such discussions. Given the well known stubbornness of the people involved in the discussion above (including myself) I have little hope that we will be able to resolve this matter through discussion. Hell will freeze over before some of us change their minds. ;) Hence, I see no other way but to call a vote to finish this. --Tetris L 04:34, 17 July 2006 (CDT)

There's some more relevant ingame evidence.
"Shiro's purpose was to bind these heroic spirits into magical constructs and bend them to his will. If he had been successful, he would undoubtedly have become much more powerful. Once again, young hero, the empire finds itself in your debt."
"With the Spear of Archimorus, the Urn of Saint Viktor, and the blessings of Dwayna in your arsenal, Shiro is sure to be defeated! If he has created any of his constructs, you must destroy the spirit rifts that are summoning them. Do not forget this advice!"
-- Gordon Ecker 04:08, 20 July 2006 (CDT)
And more.
"2. When you destroy a construct, the spirit will be released, allowing you to continue. It will lend Vizu some of its strength."
-- Gordon Ecker 01:48, 21 July 2006 (CDT)

Please vote on the following questions:

Should the term "bound spirit" be reserved for spirits bound by Shiro?
  • Yes, this is clearly a fixed term.
    1. Your vote here.
  • No, there are other kinds of spirits bound in other ways.
    1. --Tetris L 04:34, 17 July 2006 (CDT)
    2. -Gares 12:11, 17 July 2006 (CDT)
    3. -- Gordon Ecker 04:08, 20 July 2006 (CDT)
    4. Your vote here.
  • Other (specifiy)
    • Let's avoid using this term in the first place.
    1. User:PanSola (talk to the Follower of Lyssa.png)
    1. Your vote here.
What is your understanding of "Shiro'ken"?
  • Only those creatures that have "Shiro'ken" in their name are Shiro'ken.
    1. Your vote here.
  • All creatures belonging to Shiro's army of bound spirits (i.e. all creatures dropping Soul Stones) are Shiro'ken.
    1. --Tetris L 04:34, 17 July 2006 (CDT)
    2. -Gares 12:11, 17 July 2006 (CDT)
    3. Your vote here.
  • Other (specifiy)
    1. I'd consider Spirits of Portals to be part of Shiro's army of bound spirits, they're clearly not Shiro'ken / Constructs and (as far as I know) don't drop Soul Stones (or any thing else). But I'd consider everything else in Shiro's army of bound spirits to be Shiro'ken. -- Gordon Ecker 04:08, 20 July 2006 (CDT)
    2. Your vote here.

This vote will be closed after Friday, the 23rd of July.

Fractional time[]


Please place your name by your main preferences, and specify alternate backup choices after your name for the purpose of instant-runoff.

This vote is open until 7 July 2006

Variant 1 (plain text)

  1. Latecomer vote for a totally unpopular option. Really, though, this option has the lowest barrier to entry. I would even propose a decimal notation (i.e., 0.25, 0.5, 0.75) because it is the most flexible; for instance, Fast Casting already uses this format. Seventy.twenty.x.x 05:13, 10 June 2006 (CDT)
  2. --Ab.Er.Rant User Aberrant80 Sig.png (msg Aberrant80) 03:33, 24 June 2006 (CDT) Plain and simple is the best. Alt: 2,5

Variant 2 (htmlchar)

  1. --Bishop (rap|con) 04:36, 8 June 2006 (CDT) Standards, standards, standards!
  2. --Theeth Assassin (talk) 06:08, 8 June 2006 (CDT) Except with the html entities instead of the unicode code points.
  3. --Draygo Korvan 11:14, 8 June 2006 (CDT) Standards!, i think templating it is a separate issue. The template should use the HTML standard. using <sup> is too messy!

Variant 3 (htmlcode)

Variant 4 (latex)

Variant 5 (template)

  1. User:PanSola (talk to the Follower of Lyssa.png). Alt choices in order: 1 > 3 > 2
  2. Chi Li Chi Li. Alternatives in order of preference: 3 > 1 > 2
  3. User:Xis10al Alternative choices: 1 > 2 > 3
  4. Xasxas256 Easy to use, easy to read
  5. Skuld Monk Easiest to read, easiest to use 3:2
  6. Chrono traveller I like it since it is (currently) basically 2 but larger font, for those who may have problems reading it, alternate choices: 2 > 1 > 3 (alas my poor latex fractions aren't an option till the math plugin is implemented)
  7. Rainith Oh god, another fsking skill vote. :(
  8. --- Barek (talk • contribs) - 11:10, 8 June 2006 (CDT)
  9. Thank you for not making the template link to an image. I'm voting for it. — 130.58 (talk) (11:15, 8 June 2006 (CDT))
  10. HopefulNebula 02:01, 9 June 2006 (CDT) alts in order: 1, 3
  11. User:LordBiro This is a very old discussion on the GuildWiki, and I'm sure it was settled, but I can't find it anywhere. Maybe it wasn't! Anyway, I think template is the best choice. LordBiro 04:58, 10 June 2006 (CDT)
  12. Lord Ehzed 08:19, 19 June 2006 (CDT) (then 1 > 3 > 2 > 4)
  13. Galil Ranger 15:56, 20 June 2006 (CDT) Preferrably templates written to agree with the xhtml standard, so I'm for both variant 2 and 5 put together.

Spirit binder[]

Vote on what people think Spirit Binder means[]

Who or what is the "spirit binder" referred to for example in the Tahnnakai Temple mission discription?

  • It is the tool (the physical shell) used by Shiro to encage a bound soul.
    1. -Gares 12:11, 17 July 2006 (CDT)
    2. -- Gordon Ecker 04:08, 20 July 2006 (CDT)
    3. --Karlos 13:56, 23 July 2006 (CDT)
    4. --- (ha i have more dashes than you) --User:ST47(talk) 14:51, 23 July 2006 (CDT) I think this is obvious from the last mission - you get bound and there are the binders - binders bind, shiro is different
    5. --Tetris L 04:14, 24 July 2006 (CDT)
    6. Your vote here.
  • It is simply a different name for Shiro himself.
    1. --Tetris L 04:34, 17 July 2006 (CDT) (withdrawn)
    2. Your vote here.
  • Other (specifiy)
    • Moot. Explain the various interpretations in the spirit binder article. There are enough ppl who care enough to ensure overall it will be NPOV after numerous edits. -User:PanSola (talk to the Follower of Lyssa.png) 04:53, 20 July 2006 (CDT)
    • Abstain. Don't really care, tend to agree w/PanSola, but not even interested enough for that. :P --Rainith 14:06, 23 July 2006 (CDT)
    1. Your vote here.

Nightfall builds[]

The Vote[]

Vote ended at 11:59 PM August 26th 2006 PST

Democracy ftw! — Rapta Rapta Icon1.gif (talk|contribs) 14:32, 23 August 2006 (CDT)

Vote to End 11:59 PM August 26th 2006 PST (01:59 AM 27th CDT) . --Honorable Sarah Honorable Icon.gif 15:06, 23 August 2006 (CDT)
Ok the votes was quite short and it was a narrow result, but now several days passed without anything happening here. --Xeeron 10:05, 31 August 2006 (CDT)
Fine, totally ignore my point below and in Category talk:Votes. I see Skuld has already deleted them. - Greven 16:54, 3 September 2006 (CDT)

Delete all Nightfall builds:

  1. Rapta Rapta Icon1.gif (talk|contribs) 14:32, 23 August 2006 (CDT)
  2. --Honorable Sarah Honorable Icon.gif 14:35, 23 August 2006 (CDT)
  3. --Theeth Assassin (talk) 16:38, 23 August 2006 (CDT) or move to user pages. Builds that can't be tested are pure fabrications. At least wait until the next public beta, when the dervish will be nerfed skills will be more balanced.
  4. --Azroth 20:23, 23 August 2006 (CDT)--they just cant be tested and will probably end up needing serious tweaking after Anet mods the skills.
  5. --Karlos 23:08, 23 August 2006 (CDT): The axe. Should never have been allowed to begin with. One day I will assassinate Xeeron and then rewrite the builds policies so that they only contain skills from my user page! >:)
  6. --Xasxas256 05:24, 24 August 2006 (CDT) I pity the people that look after the build articles, what a horrible thankless job they have. We don't need speculative builds IMO and this should mean a bit less work for our build patrollers.
  7. I started adding delete tags because the current notice was impossible: "this build is currently being tested" — Skuld 06:06, 24 August 2006 (CDT)
  8. Changed my mind after reading the response of Xasxas256 on his talk page. No one is going to read through the build anyway. Keep the wiki clean. --Gem-icon-sm.png (talk) 09:00, 24 August 2006 (CDT)
  9. --Midnight08 Assassin 15:21, 23 August 2006 (CDT) lol my edits keep getting messed up. see below, Xasxas's arguments hold more water than any ive seen so far and have swayed my vote for the good of the wiki.
  10. --Amokk 11:34, 24 August 2006 (CDT)we should have a vote to delete every build on Guildwiki but the Premades...
  11. keep the wiki clean of untestable builds Tharna 11:38, 2 September 2006 (CDT)

Move to [:Category:Archived builds]:

  1. (your vote)

Move to their own category:

  1. Ditto. Also, best compromise. --Spot 15:41, 23 August 2006 (CDT)
  2. I don't see the point of keeping them, but several people seem to want to - best compromise is to move them out of the way. --NieA7 15:32, 23 August 2006 (CDT)
  3. This seems like a good compromise. Builds shouldn't be moved out until retested on release. --Thervold 16:45, 23 August 2006 (CDT)
  4. What they said - completely deleting all of them is overreacting, but they don't belong in any of the existing categories. —Dr Ishmael Diablo the chicken.gif (talk|contribs) 23:04, 23 August 2006 (CDT)
  5. No harm done in keeping the builds in a separate category. dodges Karlos --Xeeron 02:26, 24 August 2006 (CDT)
  6. Retest them when Nightfall is released --Kitty1.jpg (Talk) (Cont) (Cool) Soft2.jpg 05:33, 24 August 2006 (CDT)
  7. Peoples creative work will be lost otherwise. Sir On The Edge
  8. We're not wasting anything. If we're having builds at all, having these seems fine. I'd argue that we should get rid of all unofficial builds or keep them all (or come up with a much more formal process for each build). --JoDiamonds 08:40, 29 August 2006 (CDT)

Leave as is:

  1. (Your Vote)

Amount of votes needed for moving builds[]

  • Vote on the amount of votes needed for moving a build to unfavored or tested categories, from Talk:Builds. Result: 3/3 wins.


Since proposals seem to repeat themself on the above discussion, let me call a quick vote. How many votes (always excluding the authors vote) should be needed for moving builds out of untested?

  • 3 for moving into tested/2 for moving into unfavored:
  1. Makes it easier to get rid of really useless builds. — Luobailong Luobailong sig.gif (talk|contribs) 08:35, 29 August 2006 (CDT)
  2. Keeps our categories under control, without being flooded by useless builds. — Rapta Rapta Icon1.gif (talk|contribs) 11:33, 29 August 2006 (CDT)
  3. Change to 5/2 when there is a bigger testing community --Kitty1.jpg (Talk) (Cont) (Cool) Soft2.jpg 11:38, 29 August 2006 (CDT)
  4. Rapta's and KittySoft points, we need rubbish control --Nemren 12:09, 29 August 2006 (CDT)
  5. Too many new builds....Vazze 08:23, 1 September 2006 (CDT)
  • 3 for moving into tested/3 for moving into unfavored:
  1. -Onlyashadow 08:38, 29 August 2006 (CDT)
  2. Two people an unfavoured build does not make. --NieA7 08:42, 30 August 2006 (CDT)
  3. 3 or 3. Also, if someone posts an unfavored vote, there should be at least some sort of entry in the discussion as to why it is unfavored. Simply posting that a build is unfavored without any reason or suggestion does nothing to improve on the build or the site.--Token Cleric 15:03, 31 August 2006 (CDT)
  4. Despite the growing untested category, the number of people needed for favored and unfavored should be equal. --Xeeron 16:37, 31 August 2006 (CDT)
  5. Why should it be easier to make a build unfavored than favoured. I think 3/3 is fair. --Betaman 04:52, 1 September 2006 (CDT)
  6. --— xis10al Xis10al sig icon.jpg 12:11, 4 September 2006 (CDT)
  7. Moved votes after considering the fact that we dont have enought active tester. -- Ritualist-icon-small.png Cwingnam2000 19:18, 5 September 2006 (CDT)
  8. Makes no sense to have different weights on the scale. If three people make a build good, why should only 2 make it bad? --Karlos 07:32, 7 September 2006 (CDT)
  9. I agree with those above me. Also, since I care enough to vote on this issue I will be allocating time to testing builds. Putting my money where my mouth is, so to speak. Kai 11:39, 7 September 2006 (CDT)
  • 5 for moving into tested/3 for moving into unfavored:
  1. (your vote)
  • 5 for moving into tested/5 for moving into unfavored:
  1. (your vote)
  • Other (specify):
  1. I don't like votes in general and I'm utterly opposed to anything without a minimum time limit. --Fyren 04:48, 30 August 2006 (CDT)
  2. I'm not a big fan of votes either, but this is one of those cases where I believe they're absolutely necessary. I'm not going to get involved in a big discussion, but perhaps this edgy suggestion could be used in the discussion:
    • +3 votes for tested / -3 votes (or failing to reach +3 votes in, say, 1 month) for unfavored / -6 votes to destroy.
(Yes, I originated the unfavored category long ago because I was against deleting builds. I still am, but some kind of balance must be reached or all the categories will eventually overflow.) --Bishop 10:45, 1 September 2006 (CDT)
Eventually? They're well into the second 200 :P — Skuld 11:56, 1 September 2006 (CDT)
The thing is, there's nothing wrong with builds being left in Unfavored and Tested categories. The goal for the Untested category should always be 0 instead of nearly expanding onto a second page, like Skuld said. =P — Rapta Rapta Icon1.gif (talk|contribs) 12:24, 2 September 2006 (CDT)
  1. I suggest continously voting builds on all three sections and to think about a minimum of votes and a percentage of difference of favorable versus unfavorable votes both for moving a build to favored, tested or to unfavored. --mariano 04:21, 4 September 2006 (CDT)
  2. I think a time limite is a good idea. With builds, if nobody want to try it, then the build dont have anything special and shouldn't stay here. I also think that most build just "work" and have nothing special but people flood the build category with those build. We should keep only build that are well known in GW and if people want feed back on build then they should post it on theire userpage.—├ Aratak 11:07, 7 September 2006 (CDT)

When votes are made in both directions, read the above as X more (then for the other category). Vote ends on september 7th. --Xeeron 08:24, 29 August 2006 (CDT)

Vote on builds policy[]

  • Vote on the implementation of a new builds policy, from Talk:Builds. Result: No supermajority for any proposal, no policy implemented.

We currently do not have a builds policy, therefore this vote is to establish a builds policy. The discussion leading to this vote can be viewed on this talk page.

Proposal 1: Dual Screening, nomination[]

(this is the policy reflected in the current state of the article)

  • New builds are placed in builds stubs.
  • Any non-author can move the builds from stubs to untested by nominating them. The nominator is responsible for checking formal correctness.
  • Builds in untested are discussed and voted on, voters are strongly encouraged to test the build before voting. 3 more votes for either tested or unfavored means moving the build into that category.

Proposal 2: Dual screening, double vote[]

(This is the procedure refered to as "Unrefined double stage screening" above)

  • New builds are placed in build stubs
  • A (first) vote is held. If a super-majority (i.e. all but a very small minority) disfavores the build, it is placed into unfavored. If not, it is placed into untested.
  • For all builds in untested, a second vote his held, this time voters are strongly encouraged to test the build before voting. 3 more votes for either tested or unfavored means moving the build into that category.

Note that this process differs in the way builds are selected in the first stage


"I agree with proposal 1, but would also agree with proposal 2"[]

  1. Xeeron 11:42, 19 September 2006 (CDT)
  2. BrianG 19:46, 19 September 2006 (CDT)
  3. Token Cleric 16:48, 22 September 2006 (CDT)
  4. (Your vote here)

"I agree with proposal 1 and I do not agree with proposal 2"[]

  1. Ifer 12:04, 19 September 2006 (CDT) -- Changed my vote.. I stongly prefer this option, but I do believe the other would work as well.
  2. --Kitty1.jpg (Talk) (Cont) (Cool) Soft2.jpg 11:55, 21 September 2006 (CDT)

"I disagree with proposal 1, but would agree with proposal 2"[]

  1. (Not a fifty five 11:53, 19 September 2006 (CDT))
  2. (Onlyashadow 12:33, 19 September 2006 (CDT))
  3. Also agree to add a time limit. -- Ritualist-icon-small.png Cwingnam2000 17:30, 19 September 2006 (CDT)

Neither of the above[]

  1. I don't like either of the above a great deal... I'm curious why these are the only two proposals in the vote, when more were made above? - Greven 12:57, 19 September 2006 (CDT)
  2. Having a build-stub and untested-build category is redundant. Use only one and require a majority of votes (at least 3) before a build can be moved from stub/untested to favored. Chuiu Me Icon.png(T/C) 20:00, 19 September 2006 (CDT)
  3. I strongly disagree with any policy based around a static number of votes. I further disagree with the method of filtering these proposals out, which appears to be "argue until everyone who disagrees gives up." —Tanaric 21:27, 21 September 2006 (CDT)
  4. I prefer Greven's idea. — Skuld 04:50, 26 September 2006 (CDT)
  5. Me too, what he says at the bottom of this page seems to make more sense than this.— builds Azroth talk 12:47, 26 September 2006 (CDT)
  6. I've thought about this for a while now, and I really can't support a system based on voting. I prefer the idea of a nomination process. I think a builds council would be somewhat elitist. I don't agree with Greven's idea, since it still seems to revolve around voting and not debate. <LordBiro>/<Talk> 06:39, 26 September 2006 (CDT)

If there is a substantial share of people voting for "Neither of the above", no builds policy will be implemented. End of vote is the 27th of september. --Xeeron 11:15, 19 September 2006 (CDT)

GuildWiki Skin poll[]

transcluded from GuildWiki:Skin poll

GuildWiki:Skin poll